Planète auto-hébergement

Si vous ne voulez pas stocker vos dépôts de code sur Github et que n’avez besoin des fonctionnalités, de la complexité de Gitlab, que Gitweb et viewgit ne vous plaisent pas, alors vous trouverez peut être votre bonheur avec Gitlist.

GitList est un simple visualisateur de dépôt git écrit en PHP avec le framework Silex que l’on héberge sur son serveur, dont la version 0.4.0 a été releasé au début de ce mois de juin. A l’inverse de Gitlab qui essaye de proposer les fonctionnalités de Github, GitList propose le strict minimum des fonctionnalités que l’on attend d’un visualiseur de dépôt git :

• Visualisation de dépôts

• Coloration syntaxique du code,

• Historique des commits,

• Des statistiques sur le dépôt.

Le design de GitList est très simple, on est pas trop dépaysé par rapport à Github. De plus, comme il est développé en PHP, la stack serveur à mettre en place est vraiment simple (une fois encore) comparé à Gitlab.

Néanmoins, tout n’est pas parfait, je trouve GitList un peu léger pour que je puisse l’utiliser en lieu et place de Gitlab, voici une petite liste de fonctionnalités que je trouve manquantes :

• Un système d’authentification pour garder ses dépôts privés,

• Pouvoir créer un dépot,

• Pouvoir cloner un dépôt.

Je suis conscient que mes souhaits sortent du domaine initial de GitList mais j’apprécie vraiment ces fonctionnalités dans Gitlab.

En conclusion, j’ai beaucoup utilisé le terme “simple” mais cela correspond bien à GitList. Même si pour moi il n’est pas encore assez complet, je ne risque pas de l’adapter de si tôt, mais pour des gens qui n’ont pas besoin de Gitlab alors c’est peut être un choix très intéressant.

Et vous, quel est votre solution préférée !

A la faveur d’un article de l’ami Korben, Bitmessage a débarqué sur le devant de la scène people en France la semaine dernière.

De quoi s’agit-il exactement ? D’un réseau peer to peer de messagerie chiffré. Les principes de base sont les mêmes que le bitcoin (voir ma série sur le sujet) :

• Aucune autorité centrale d’aucune sorte (pas même l’infrastructure DNS)
• Chiffrement de bout en bout
• Diffusion par inondation totale de l’ensemble du réseau (ou presque)

Les mécanismes mis en jeu sont toute fois plus simple que le bitcoin, l’historique n’ayant pas besoin d’être conservé à long terme pour assurer la traçabilité d’une monnaie.

Lorsque vous lancez le client bitmessage pour la première fois, vous allez créer une adresse, par exemple BM-2DACG68CuqSrLHxyXdWug3nZZxhBn6cQTt. Celle-ci contient un hash (si vous avez décroché, allez lire la série sur le bitcoin) de votre clé publique. Lorsque vous allez envoyer un message, à une autre adresse de la même forme, donc, votre client bitmessage va générer une demande pour obtenir la clé publique correspondant au hash de l’adresse de votre destinataire pour pouvoir chiffrer le message.

Cette demande va parcourir l’ensemble du réseau jusqu’à tomber sur le destinataire en question qui va répondre avec sa clé publique. Puisque vous disposez du hash de cette clé, le logiciel pourra vérifier rapidement que la clé qu’on vous a fourni est la bonne, puis chiffrer votre message avec, le signer avec votre propre clé, et renvoyer le tout sur le réseau. Pour être valable, ce paquet doit, comme dans le cas du bitcoin, faire l’objet d’un travail sur son hash en SHA256 pour tomber sur un certain nombre de zero dans le hash. Le protocole est prévu pour qu’un ordinateur lambda mette 4 minutes à accomplir ce travail.

Une fois envoyé, chaque membre du réseau tente de déchiffrer chaque message. S’ils n’ont pas la bonne clé privée, c’est peine perdue, sinon, le message est déchiffré, et la signature vérifiée à partir de votre clé publique contenue dans le message, elle même vérifiable par le hash qui est inclus dans votre adresse bitmessage.

C’est, comme bitcoin, brillant de simplicité et d’efficacité. Car non content de permettre le chiffrement de bout en bout sans recourir à aucun artifice de type échange et vérification préalable de clé ou autorité centrale, bitmessage permet efficacement de lutter contre le spam, puisqu’il faut, quoi qu’il arrive, 4 minutes pour fabriquer un seul et unique message, rendant le spam trop cher pour être efficace. Il est même possible pour chacun de définir un facteur de difficulté plus élevé pour obliger les correspondants à travailler plus pour vous envoyer un message.

Les performances du système, en cas d’utilisation massive, ont même été pensées : le réseau pourra se hiérarchiser de lui même pour éviter que chaque participant doive tester l’ensemble des messages transmis. Ce petit artifice est réalisé par la constitution d’un arbre de flux de messages. Pour faire simple, on peut comparer ce fonctionnement à celui du courrier classique : lorsque vous envoyez une lettre dont la destination est dans la même ville que vous, elle ne va pas sortir de la ville. Par contre, quand vous écrivez à quelqu’un à l’autre bout du monde, votre courrier va parcourir un certain nombre de points de collecte.

Même si la version actuelle de bitmessage est un peu rébarbative, je vous invite à jouer avec et à suivre ses évolutions ! Vous pouvez me causer à la maison sur BM-2D7AjVjnrV2fFbZ9SYHfxfkjfbPntpEEJQ et au bureau sur BM-2DACG68CuqSrLHxyXdWug3nZZxhBn6cQTt :)

(Et puis si vous ne faites rien jeudi vers 14h, je parlerais bitcoin & bitmessage avec qui voudra venir dans le cadre de Pas Sage en Seine. Rendez-vous aussi vendredi à 17h au même endroit pour une conf sur @maisonquitweet !)

Alors que le lecteur de flux RSS de Framasoft est encore en phase de test, un commentaire de Pyg nous éclaire sur ce qui est en train de se passer. Merci à lui d'avoir réagi à mon précédent billet.

Ci-dessous, je vous propose de reprendre son commentaire et de lui donner une meilleurs visibilité.

Framanews, c'est :

• 300 utilisateurs
• 22 000 flux
• 16 000 flux uniques
• 1 seul serveur (i7 4x2,66GHz, 24Go de RAM)
• 1 BDD Mysql
• 1 bénévole
• 1 semaine d’existence, à peine

Pour cerner un peu mieux ces chiffres, en voici d'autres :

• En moyenne, un utilisateur a 60 flux dans son instance.
• Le service met à jours les flux toutes les 30 minutes,
• ce qui implique 12 flux traités par seconde.
• Framasoft, c'est 14 serveurs

Maintenant que vous savez ça, je peux lâcher la phrase qui fâche : Framanews ne va pas vraiment bien.

D'après Pyg, les solutions mises en place sont, pour le moment, insuffisantes pour maintenir une bonne qualité d'utilisation et les gars de Framasoft se refusent à proposer un service qui serait source de frustrations.

Ils essayent de redresser la barre, d'optimiser :

• Le passage d'une base de données MySQL à une base de données PostgreSQL est en cours. Nul ne garanti que ça suffise. Il est tout de même de notoriété publique que PostgreSQL est bien plus apte à gérer des BDD énormes et très sollicitées. Gageons que ça soulagera le serveur.

• Une autre solution envisagée est de limiter à 50 le nombre de flux par utilisateur. C'est une limite haute pour certains, mais quid des gars qui comme moi se rapprochent doucement du double ? Framanews se passerait de notre gourmandise et nous du plaisir de s'en servir. Ce n'est pas un mal, loin de là : pas la peine d'écraser la bête. Est-ce aussi une solution viable, à le long terme, s'ils accueillent de nouveaux utilisateurs ? Je ne pense malheureusement pas.

Ils sont en train de tester tout ça et espère ne pas devoir renoncer à Framanews si la situation n'évolue pas favorablement.

Après avoir lu le CV de Luc, le bénévole qui gère Framanews, j'ose croire que ça devrait quand même bien se passer. Courage gros, comme on dit ici

Pour terminer sur une belle note, quand même, Pyg parle d'un projet de promotion de l'auto-hébergement. C'est de très bon goût en cette période de gros doutes sur le respect de notre vie privée sur Internet. A voir venir d'ici la fin de l'année, peut-être.

Merci à lui pour ces éclairages.

Une dernière chose : n'oubliez pas que Framasoft est une association, qu'elle fonctionne sur la base de dons. N’hésitez à donner si vous le pouvez. Je ne peux pas le faire pour le moment, j'ai récemment décidé de soutenir l'action de PCINpact.

C'est du 20 au 23 juin que ce déroula la cinquième édition de #PSES.

Pas Sage en Seine, c'est pour moi l'un des événements les plus intéressants, en contenu et qualité, que je peux suivre sur la toile, à défaut de pouvoir m'y déplacer.

On y retrouve toujours des sujets passionnants accompagnés de pointures pour en parler : Benjamin BAYART, Benjamin SONNTAG, Jean-Marc MANACH et j'en passe. Je ne vous parle pas ceux qui étaient là-bas les années précédentes... Du bien beau monde.

Petite liste des sujets qui, selon moi, s'imposent dans le programme :

• Anticiper #PRISM et anticiper la suite de l'histoire - Un retour sur PRISM par Bruno Paul.
• # mv internet* /CSA - Charles Simon reviendra sur l'arrivée du CSA dans la vie d'Internet.
• La team Videolan nous parlera de Bittorrent dans VLC et de la HADOPI
• Le lancement des Big Brother Awards France, les BBA reviennent en France.
• Un débat sur le fameux : Je n'ai rien à cacher !.
• Un débat autour du doc "La contre-histoire de l'Internet".

Il y aura encore beaucoup plus à voir pendant cette édition 2013. Consultez le programme complet ici.

Si vous ne comprenez pas tout, fouillez sur la toile pour être prêt à suivre les débats. Faut parfois s'accrocher. Si vous avez le temps et que vous voulez voir à quoi ça ressemble, c'est par ici. Vous avez accès aux vidéos des précédentes éditions. C'est à voir, je vous le recommande franchement.

Je suppose que, comme pour les éditions précédentes, il y aura le duo La Cantine/Ubicast pour nous retransmettre toutes les interventions bien comme il faut.

Si vous le pouvez, allez-y sans hésiter ! C'est vivement conseillé pour les neurones de votre cerveau.

Amis utilisateurs de la belle création de Sebsauvage, soyez content : Shaarli est disponible en tant qu'application pour Android.

Ce n'est pas vraiment une nouveauté puisque si j'en crois les commentaires sur Google Play, l'application serait disponible depuis au moins novembre 2012.

Et cette application n'en est pas vraiment une. En l'installant, elle glisse simplement une nouvelle entrée dans vos options de partage.

Cette capture d’écran montre tout ce que fait l'application : en choisissant de partager sur Shaarli, vous êtes redirigé vers votre navigateur, directement sur la page de connexion de Shaarli : vous renseignez votre mot de passe/ nom d'utilisateur et vous pouvez préparer le partage.

Certains diront que c'est peu, mais je dirais que c'est exactement ce que fait le bouton "Shaare link" que les utilisateurs du goinfre à lien ont dans leur navigateur. Largement suffisant.

Sachant que je teste en ce moment Tiny Tiny RSS avec son application mobile (qui est franchement bien), je trouve du coup que ce raccourci direct est très appréciable.

Notez aussi l'application ne demande absolument aucune autorisation. Pas mal, non ?

Les liens utiles :

• Télécharger l'application
• Mon Shaarli

Sans le vouloir, notre dernier article rejoint l’actualité dans laquelle le chiffrement revient très souvent à nos oreilles avec l’affaire PRISM. Cette fois c’est Anthony qui nous propose un article expliquant comment configurer OpenVPN en tant que client aux service de vyrpvpn.

Comme d’hab, c’est sur le wiki: Configurer vyprvpn avec Openvpn

J'ai un HP NL40 comme NAS, c'est une bonne petite machine, mais elle n'a qu'un seul port réseau, ce qui limite un peu les possibilités pour faire du bonding avec deux cartes réseau !

Dans mon cas je voulais faire de l'EtherChanel (nom de la technologie chez Cisco), ou plus exactement ça version libre: le protocole 802.3ad.
Selon la belle définition de Wikipedia, "Elle permet d'assembler plusieurs liens physiques Ethernet en un lien logique. Le but est d'augmenter la vitesse et la tolérance aux pannes entre les commutateurs, les routeurs et les serveurs."

En gros ça permet d'augumenter les débits, tout en garantissant un minimum de haute dispo si l'un des liens rencontraient un soucis (failover) et en faisant de la répartition de charges (load balancing).

C'est pour moi le meilleur des modes de port trunking entre :

• Balance-rr (un paquet par interface de façon intermittente)
• Active Backup (seule une liaison est activée, l'autre est en secour)
• Balance XOR (transmission basée sur le hashage ip)
• Broadcast (transmet tous les paquets sur toutes les interfaces)
• IEEE 802.3ad (failover, load balancing et augumentation des débits)
• Balance-tlb (prise de relai entre les interfaces sur le trafic sortant, via changement d'adresse MAC)
• Balance-alb (prise de relai entre les interfaces sur le trafic entrant, via changement d'adresse MAC)

/!\ attention le 802.3ad nécessite un switch manageable compatible /!\

Pour commencer je vais donc rajouter une carte dual port gigabit en pci ex et au format mini pci (fallait la trouver celle là !!),
On commence donc par ouvrir la bête (oooh la poussière ) :

Puis il faut débrancher les prises suivante : USB, mini SAS, ventilo, panneau de contrôle, pour enfin dévisser et sortir la carte mère, à ce moment là, on pourra enlever le gros câble d'alimentation.

Une fois la carte mère sortie, on peut rajouter la carte réseau :

Et on recommence les étapes dans le sens inverse pour le remonter

Y a plus qu'à rebooter (fait chi** cette modif m'a fait perdre mon uptime de 142 jours !!)

le résultat d'un "lshw", nous montre que les interfaces sont bien détectées

            *-network:0 DISABLED
                description: Ethernet interface
                product: 82571EB Gigabit Ethernet Controller
                vendor: Intel Corporation
                physical id: 0
                bus info: pci@0000:02:00.0
                logical name: eth1
                version: 06
                serial: 00:15:17:91:8b:e8
                capacity: 1GB/s
                width: 32 bits
                clock: 33MHz
                capabilities: pm msi pciexpress bus_master cap_list rom ethernet physical tp 10bt 10bt-fd 100bt 100bt-fd 1000bt-fd autonegotiation
                configuration: autonegotiation=on broadcast=yes driver=e1000e driverversion=1.2.20-k2 firmware=5.11-2 latency=0 link=no multicast=yes port=twisted pair
                resources: irq:26 memory:fe8e0000-fe8fffff memory:fe8c0000-fe8dffff ioport:e800(size=32) memory:fe8a0000-fe8bffff(prefetchable)
           *-network:1 DISABLED
                description: Ethernet interface
                product: 82571EB Gigabit Ethernet Controller
                vendor: Intel Corporation
                physical id: 0.1
                bus info: pci@0000:02:00.1
                logical name: eth2
                version: 06
                serial: 00:15:17:91:8b:e9
                capacity: 1GB/s
                width: 32 bits
                clock: 33MHz
                capabilities: pm msi pciexpress bus_master cap_list rom ethernet physical tp 10bt 10bt-fd 100bt 100bt-fd 1000bt-fd autonegotiation
                configuration: autonegotiation=on broadcast=yes driver=e1000e driverversion=1.2.20-k2 firmware=5.11-2 latency=0 link=no multicast=yes port=twisted pair
                resources: irq:28 memory:fe880000-fe89ffff memory:fe860000-fe87ffff ioport:e400(size=32) memory:fe840000-fe85ffff(prefetchable)

Maintenant, la partie logicielle :

Mon Nas @home étant sous OpenMediaVault (basé sur Debian), je me rends sur l'interface, puis sur l'onget "Réseau" :

Une fois dans la gestion des interfaces, on voit que les nouvelles "pattes" sont bien détectées, je clique simplement sur "Ajouter" :

La fenêtre qui s'ouvre, m'invite à renseigner mes interfaces esclaves, si l'ip est en statique ou en DHCP, le mode de trunking, dans mon cas le 802.3ad (mais tous les autres sont aussi dispo) :

On vérifie avec un petit ifconfig, qui nous retourne la bonne configuration, donc tout va bien

root@Sheldon:~# ifconfig
bond0     Link encap:Ethernet  HWaddr 00:15:17:91:8b:e8  
          inet adr:192.168.0.251  Bcast:192.168.0.255  Masque:255.255.255.0
          UP BROADCAST RUNNING MASTER MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 lg file transmission:0 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

eth0      Link encap:Ethernet  HWaddr a0:b3:cc:df:1f:d3  
          inet adr:192.168.0.250  Bcast:192.168.0.255  Masque:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:2973407 errors:0 dropped:2 overruns:0 frame:0
          TX packets:4732882 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 lg file transmission:1000 
          RX bytes:240154529 (229.0 MiB)  TX bytes:6623199482 (6.1 GiB)
          Interruption:18 

eth1      Link encap:Ethernet  HWaddr 00:15:17:91:8b:e8  
          UP BROADCAST SLAVE MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 lg file transmission:1000 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
          Interruption:18 Mémoire:fe8e0000-fe900000 

eth2      Link encap:Ethernet  HWaddr 00:15:17:91:8b:e8  
          UP BROADCAST SLAVE MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 lg file transmission:1000 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
          Interruption:19 Mémoire:fe880000-fe8a0000 

lo        Link encap:Boucle locale  
          inet adr:127.0.0.1  Masque:255.0.0.0
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:227 errors:0 dropped:0 overruns:0 frame:0
          TX packets:227 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 lg file transmission:0 
          RX bytes:41140 (40.1 KiB)  TX bytes:41140 (40.1 KiB)

Et pour les intégristes, il reste la conf à la main dans le fichier /etc/network/interfaces :

# bond0 network interface
auto bond0
iface bond0 inet static
    address 192.168.0.251
    gateway 192.168.0.1
    netmask 255.255.255.0
    mtu 1500
    dns-nameservers 8.8.8.8 8.8.4.4
    bond-slaves eth1 eth2
    bond-primary eth1
    bond-mode 4
    bond-miimon 100
    bond-downdelay 200
    bond-updelay 200

Pour que le tout fonctionne, il reste à configuré le switch, afin qu'il prenne en compte l'utilisation du 802.3ad
mais je n'ai pas encore reçu le miens (snif), je mettrais ce post à jour quand ce sera le cas !
 

Chez les bidouilleurs de l'auto-hébergement, il y a des choses qu'on apprend à faire sur le tas : monter un serveur Apache, une base de données, des VirtualHosts et lier des applications à tout ceci, et des choses qu'on apprend sur le tard.

Sur mon installation actuelle, dont je suis assez fier puisque montée en presque autodidacte, je ne me suis pas tout de suite penché sur la sécurité des données qui transitées sur le réseau depuis mon serveur principal.

C'est maintenant chose faite : une partie de mon installation est désormais chiffrée part OpenSSL.

Mon instance ownCloud et la partie administration de ce blog propulsé sous Dotclear sont maintenant systématiquement redirigés vers leurs version HTTPS et non plus HTTP. En fait, à chaque fois qu'un mot de passe est demandé, je veux que ce soit fait de façon sure, en sécurisant le transite des données entre le navigateur et le serveur.

Je vous propose donc de partager ici les manipulations à faire pour un serveur sous Debian (encore Squeeze) et Apache2.

Installer et activer OpenSSL

Pour installer, c'est simple :

aptitude install openssl

Pour activer OpenSSL dans apache :

a2enmod ssl

S'occuper des certifications

On commence part créer le répertoire qui contiendra les fichiers de certification :

mkdir -p /etc/ssl/localcerts

On génère ensuite les certifications :

openssl req -new -x509 -days 365 -nodes -out /etc/ssl/localcerts/apache.pem -keyout /etc/ssl/localcerts/apache.key

Et on termine par la mise en place des bons droits :

chmod 600 /etc/ssl/localcerts/apache*

On se retrouve maintenant avec la gestion de la certification qui va bien et avec Apache prêt à s'en servir.

Configuration d'Apache

Dans un souci de simplicité, je vais vous montrer comment reprendre le fichier d'exemple de configuration présent dans /etc/apache2/sites-available/ : default-ssl.

Vous n'aurez pas grand chose à modifier. 

Déclarer le nom et le port du VirtualHost

Ajoutez NameVirtualHost *:443 et modifiez la balise ouvrante de déclaration du VirtualHost <VirtualHost *:443>.

Vous devriez donc passer d'un fichier de base :

<IfModule mod_ssl.c>
<VirtualHost _default_:443>

[...]

</VirtualHost>
</IfModule>

À quelque chose comme ça :

<IfModule mod_ssl.c>
NameVirtualHost *:443
<VirtualHost *:443>

[...]

</VirtualHost>
</IfModule>

Activez SSLEngine

La ligne suivante est parfois commentée. Faîtes sauter le # qui traîne devant.

SSLEngine On

Renseignez correctement les chemins vers le certificat et la clé

Ces deux lignes suivantes sont déjà présentes mais ne pointent pas vers ce que nous avons généré un peu plus haut dans le répertoire /etc/ssl/localcerts/, modifiez-les comme ceci :

SSLCertificateFile /etc/ssl/localcerts/apache.pem
SSLCertificateKeyFile /etc/ssl/localcerts/apache.key

Le fichier default-ssl est maintenant configuré. Passons aux dernières petites choses à faire.

Activer le VHost

Votre VHost est configuré par le fichier default-ssl. Activez-le donc :

a2ensite default-ssl

Vérifiez qu'Apache écoute bien le port 443

... dans son fichier de configuration /etc/apache2/ports.conf. A priori, il l'écoute de base.

Vous pouvez maintenant redémarrer le serveur Apache et profiter d'un accès en HTTPS !

/etc/init.d/apache2 restart

Utilisez la connexion en HTTPS automatiquement

C'est bien malin d'avoir mis en place le HTTPS mais il est encore plus malin de forcer son utilisation, histoire de ne pas s'être plongé dans des fichiers de configuration pour rien.

Pour obligatoirement utiliser une connexion sécurisée lorsque vous vous connectez à une partie de votre site, utilisez la redirection permanente vers l'accès en HTTPS.

On va prendre pour exemple l'accès à son instance ownCloud qui se ferait via : http://www.dadall.info/owncloud

Dans /etc/apache2/sites-available/default, on va ajouter une ligne pour s'occuper de sa redirection : 

 Redirect permanent /owncloud https://www.dadall.info/owncloud

Maintenant, quand vous vous connecterez sur www.dadall.info/owncloud, vous serez automatiquement redirigé vers du HTTPS.

Vous pouvez ajouter autant de redirections que vous voulez, faites-vous plaisir.

Comme je le dis toujours : chez moi ça marche. Mais bon, si ça ne marche pas chez  vous, utilisez les commentaires et je ferais ce que je peux.

Vous n'avez sûrement pas pu y échapper, le gouvernement des USA et la NSA ont affirmé espionner les communications électroniques sur leur territoire. Cela inclut Gmail, Facebook, Skype, etc... et donc aussi les communications des étrangers qui utilisent ces services.

On pourrait penser que les personnes qui s'auto-hébergent sont à l'abri mais de fait il suffit qu'il seul des correspondants d'une communication utilise un service aux USA et c'est l'ensemble de la communication qui peut être espionnée. Malheureusement, bon nombre de mes contacts ont une adresse mail @gmail.com ou @hotmail.com :-/ Autant dire que lorsque l'on leur envoie un mail, le fait d'être auto-hébergé ne change rien.

Se prémunir de cet espionnage requiert donc une solution plus globale. Une sécurisation de bout en bout où les intermédiaires de communication n'aient pas connaissance du contenu et où le déchiffrement du message se fait par un logiciel libre sur une plateforme en laquelle l'utilisateur a confiance (êtes vous sûr qu'il n'y a pas de backdoor dans votre OS de smartphone?)

Si les gens qui utilisent Gmail & consort aujourd'hui ne sont pas auto-hébergés, je ne pense pas qu'ils vont le devenir par miracle. Ces gros services apportent beaucoup de facilité (stockage en ligne gratuit, accès depuis n'importe quel terminal sans configuration, aucune maintenance) que l'auto-hébergement d'aujourd'hui peine à concurrencer.

Des initiatives comment BitMessage ou Retroshare émergent mais le futur est encore à créer.

J’ai présenté une conférence la semaine dernière, dimanche 2 juin, à la Ubuntu Party de Paris, autour du réseau social décentralisé Movim qui se base sur XMPP. L’ambiance était fun, même si l’évènement était un peu plus modeste que d’habitude, ça n’empêche pas de faire de bonnes rencontres.

Je vous conseille de regarder la vidéo avec les slides à côté, ils sont juste en dessous.

• Télécharger la vidéo en webm
• Télécharger la vidéo en ogv
• Télécharger la vidéo en mp4
• Télécharger la présentation en odp
• Télécharger la présentation en pdf

Il se trouve qu’on a aussi été invité au PSES2013 (Pas Sage en Seine 2013, à Paris) et que je me retrouve donc présenter Movim à nouveau dans deux semaines.

Vous pourrez me rencontrer samedi 22 juin de 18h30 à 19h30 (plus d’info).

Sympa ! Je ne savais pas que Facebook avait une ban list :p

Encore une bonne raison de préférer les réseaux non contrôlés.

Je profite de la sortie de la nouvelle version d'Ajaxplorer 5.0 (mise en ligne le 02/06/13), pour en faire une présentation.

De quoi s'agit il ?

C'est une interface web pour gérer vos fichiers sur votre serveur (@home évidemment !!)
Il permet l'édition de fichiers, la lecture de photos, vidéos, écouter de la musique, upload des fichiers, en partager avec ses amis …

Il dispose d'une gestion de plugins, de différents points de montage (samba, S3, Webav …), ainsi que d'une gestion avancée des utilisateurs/groupes et des droits qui vont avec.

Bref ça fait pleins de choses, et tout cela dans une jolie interface en Ajax

et pour ne rien gacher, c'est Opensource sous licence AGPL.

Le site de l'éditeur : http://ajaxplorer.info/

L'installation :

Maintenant que je vous ai fait baver, pourquoi ne pas l'installer ?

Deux méthodes, la feignante, via gestionnaire de paquet, grâce au dépot de l'éditeur :

• Pour RPM (pas encore en 5.0 au moment où j'écris ces lignes)

   

   

  sudo rpm -Uvh http://dl.ajaxplorer.info/repos/el6/ajaxplorer-stable/ajaxplorer-release-4-1.noarch.rpm
  

  sudo yum update
  sudo yum install ajaxplorer

• Pour DEB

   

   

  nano /etc/apt/sources.list

  deb http://dl.ajaxplorer.info/repos/apt stable main
  deb-src http://dl.ajaxplorer.info/repos/apt stable main

  la clé (la commande n'a pas fonctionné avec moi, j'ai dû l'importer manuellement) :

  wget -O - http://dl.ajaxplorer.info/repos/charles@ajaxplorer.info.gpg.key | sudo apt-key add -
  sudo apt-get update
  sudo apt-get install ajaxplorer

Et la méthode pour les grands
à la mano !

à partir du paquet disponible sur Sourceforge : http://sourceforge.net/projects/ajaxplorer/files/ajaxplorer/stable-channel/5.0.0/ajaxplorer-core-5.0.0.tar.gz/download

Nottez, qu'il vous faudra un serveur Web (Apache2, Nginx), Php5, et quelques extensions, php5-gd, php5-mysql (si vous l'utilisez), imagemagick …

L'utilisation :

Une fois installé, rendez vous à l'adresse : http://monip/ajaxplorer

Là l'installateur, va vous demander quelques infos, la langue, votre nom d'utilisateur et votre mot de passe … (bon j'ai pas fait de capture d'écran, désolé …)

Maintenant, vous n'avez plus qu'à vous authentifier

Et vous devriez arriver sur votre interface principale :

En haut à droite, vous avez un menu déroulant avec votre nom, comprenant plusieurs racourcis, dont les "paramètres" :

Ce qui vous donne accès à un panneau de préférences, très complet :

C'est bien beau tout ça, mais qu'est ce que l'on peut faire avec ?

Et bien télécharger ou uploader via un simple glisser/déposer :

Vous pouvez faire de la synchro avec un client mobile :

Client Android : https://play.google.com/store/apps/details?id=info.ajaxplorer.android	Client IOS : https://itunes.apple.com/app/ajaxplorer/id441105410
Prix : 0.79€	Prix : 0.99€

Ou encore aller plus loin, en l'intégrant à un LDAP, un AD pour l'authentification, en montant un système de réplicat master/slave en y ajoutant de nouveaux plugins …

Voici le change log, depuis la dernière monture 4.x.x :

• GUI Entirely reskined : the main zones are now much more intuitive, also only the most important are immediately accessible. Responsiveness at heart, and still the template mechanism.
• Notifications & Events
• New sharing features : share folder as a public minisite on an alternate URL
• Groups managements, AD/LDAP enhanced
• Users accounts & profiles, expandable through plugins, mappable to external directories
• Ultra-flexible admin configuration : disable an action or update a plugin parameter value at group, user or role level.
• API documentation available in the interface
• WebDAV server component totally replaced by SabreDAV
• And many more…

je vous invite à le tester, c'est un bon compromis à Owncloud par exemple

Avis à toute la population : la société Linkeo vient de menacer et de tenter d'extorquer un dédommagement à LinuxFr pour un commentaire envoyé par un visiteur suite à une annonce d'offre d'emploi.

Linkeo, au cas où vous passeriez par ici :

• Les menaces, c'est mal. Le chantage, c'est mal. L'extorsion, c'est mal.
• Entre gens civilisés, on peut envisager de régler ses comptes directement et avec courtoisie.
• LinuxFr est un site Web, pas un « site Internet », nom d'un yak !
• man Streisand
• Changez d'avocat. Le votre n'est pas capable de chercher les mentions légales sur un site Web et ne respecte visiblement pas les règles de déontologies de sa profession.

Comme annoncé dans cet article, Proxmox est sortie en version finale 3.0,

Et comme convenu je fais un petit retour de mon upgrade 2.3 -> 3.0.

Tout c'est bien passé, j'ai utilisé ce script : http://download.proxmox.com/debian/dists/wheezy/pve-upgrade-2.3-to-3.0

wget http://download.proxmox.com/debian/dists/wheezy/pve-upgrade-2.3-to-3.0

chmod +x pve-upgrade-2.3-to-3.0

./pve-upgrade-2.3-to-3.0

reboot

J'ai eu 665 paquets à installer (la machine était à jour avant l'upgrade), ça à pris environ 10 min.

Le seul soucis a été que j'ai rebooté en kernel 3.2 alors que malheureusement pour faire fonctionner OpenVZ il faut rester en 2.6.32.20 …

Aucun problème pour le PCI Passtrouh, là aussi ça fonctionne toujours au poil !

root@Willbure:~# pveversion -v
pve-manager: 3.0-20 (pve-manager/3.0/0428106c)
running kernel: 2.6.32-20-pve
proxmox-ve-2.6.32: 3.0-100
pve-kernel-2.6.32-20-pve: 2.6.32-100
pve-kernel-2.6.32-16-pve: 2.6.32-82
pve-kernel-2.6.32-19-pve: 2.6.32-96
lvm2: 2.02.95-pve3
clvm: 2.02.95-pve3
corosync-pve: 1.4.5-1
openais-pve: 1.1.4-3
libqb0: 0.11.1-2
redhat-cluster-pve: 3.2.0-2
resource-agents-pve: 3.9.2-4
fence-agents-pve: 4.0.0-1
pve-cluster: 3.0-4
qemu-server: 3.0-15
pve-firmware: 1.0-22
libpve-common-perl: 3.0-4
libpve-access-control: 3.0-4
libpve-storage-perl: 3.0-6
vncterm: 1.1-3
vzctl: 4.0-1pve3
vzprocps: 2.0.11-2
vzquota: 3.1-2
pve-qemu-kvm: 1.4-12
ksm-control-daemon: 1.1-1

Me reste à faire le tour des nouvelles fonctionnalités

Le cahier de l’admin est un bouquin que je considère comme une manne pour les admin système Linux (Debian). Aussi, je me sens plus que poussé à relayer l’appel à la libération de l’ouvrage que lancent Raphael Hertzog et Eyrolle.

Le plus simple pour relayer cet appel étant de le citer, je vous invite à prendre connaissance du mail envoyé par Raphael (via la mailing-list à laquelle vous êtes sans doute déjà tous inscrits) :

Aujourd’hui s’ouvre le salon Solutions Libres au CNIT (à La Défense, Paris), j’y serai pour représenter Debian France et en faire sa promotion. Mais si je vous écris, c’est pour vous informer d’une nouvelle bien plus importante qui concerne mon livre, le Cahier de l’Admin Debian.

J’ai convaincu Eyrolles de l’intérêt de publier le livre sous licence libre et nous avons donc travaillé ensemble à mettre en place un projet qui permette de libérer le livre, de le mettre à jour, tout en maintenant sa présence en librairie. Mais pour mener ce projet à terme, nous avons besoin de votre soutien.

Nous avons mis en place un projet sur Ulule.com pour que vous puissiez contribuer à cette opération à la hauteur de vos moyens (et de vos envies). Tout soutien donne droit à des récompenses (qui varient selon le montant choisi). N’attendez-plus, rendez-vous sur http://fr.ulule.com/liberation-cahier-admin-debian/

Parmi les récompenses, il y a le livre (en version papier et en version électronique) mais également un magnifique autocollant Debian détouré (j’en ai un au dos de mon Thinkpad, il est du plus bel effet !). Dépêchez vous d’enregistrer votre soutien, la campagne n’est ouverte que jusqu’au 24 juin 2013. Si nous n’avons pas atteint l’objectif d’ici là, tous ces efforts auront été vains. Je compte sur vous !

Voila, je sais pas vous mais moi, je pense bien participer à ce financement!

Une petite news de mon hyperviseur favoris (enfin pour le moment )

(au passage, Proxmox VE à 5 ans )

Il vient de passer en RC2 en version finale pour la version 3.0, et vu le peu de temps qu'il y a eu avec la sortie de la RC1, on peut espérer la version définitive rapidement !

Il s'agit d'une mise à jour majeure (avec un changement de version pour Debian, qui sera enfin maintenant en Wheezy).

Vous pouvez télécharger l'iso à l'adresse suivante : http://www.proxmox.com/downloads/item/proxmox-ve-3-0-iso-installer

Liste des modifications, corrections … http://pve.proxmox.com/wiki/Roadmap#Proxmox_VE_3.0

Released 24.05.2013:
pve-kernel-2.6.32 2.6.32-100
fix CVE-2013-2094
update ceph packages to 0.61.2
libpve-common-perl 3.0-4:
fix bug #381: use persistent reservation file for ports
new function PVE::Tools::next_migrate_port()
libpve-storage-perl 3.0-6
rbd : clone volume to same pool that base volume
extend storage list API with useful parameters for clone
fix iscsi session scan bug
pve-cluster 3.0-4
depend on fuse (seems most utilities moved from fuse-utils to fuse)
remove depencency on fuse-utils (this package is no longer required)
fix warning about uninitialize value
fix bug 383: restart pveproxy instead of apache2
pve-manager 3.0-20
fix login problem when http_proxy is set
updated Chinese, German and French translation
allow to upload files with spaces in filename (replace with '_')
allow to delete pools with non-existent VMs/Storage
use correct icons for templates
sort templates after regular VMs
StorageSelector: allow to use new target option, used by Clone
fix bug #385: correctly handle Accept-Encoding
fix bug #374: correctly remove destroyed container from pool
pve-qemu-kvm 1.4-12
vma create: only store basename of config file.
qemu-server 3.0-15
clone disk : keep source volume params
clone: check is we can clone to target storage
fix bug #381: use PVE::Tools::next_migrate_port()
restore: do not restore template flag
vncterm 1.1-3
re-enable javascript-events.patch (needed by migrate)
based on Debian 7.0 (Wheezy)
new VM clone feature
new event driven API server (pveproxy)
completely replace apache2
efficient support for HTTP keep-alive
support bootlogd (boot log can be viewed on the GUI)
update pve-qemu-kvm to 1.4.1
update kernel to vzkernel-2.6.32-042stab076.7.src.rpm
changed default IO Scheduler to 'deadline'
updated Intel network drivers for e1000e, igb and ixgbe
Countless bug fixes

Et le plus important, le tuto de mise à jour de 2.3 à 3.0

http://pve.proxmox.com/wiki/Upgrade_from_2.3_to_3.0

Evidemment à faire avec des pincettes, c'est encore une RC !

Je referais un petit post, dès que j'aurais sauté le pas ! (dans pas longtemps, j'aime jouer avec le feu :p )

Ou si vous préférez faire une installe fraiche directement depuis une Debian 7 : http://pve.proxmox.com/wiki/Install_Proxmox_VE_on_Debian_Wheezy

(perso je conseil cette méthode plutot que d'utiliser directement l'iso de l'installateur).

Il y a un peu plus de deux ans, j’avais fait un article listant les avantages et les inconvénients de l’auto-hébergement que je pensais assez complet. Mais hier suite à une mésaventure avec un serveur VKS avec OVH, j’ai pris conscience d’un avantage énorme de l’auto-hébergement par rapport à un hébergement classique : “Pouvoir accéder physiquement au serveur”.

La mésaventure

J’ai un serveur VKS chez OVH dont je suis très content. Pour une raison X, le serveur a été redémarré dans la nuit et depuis ce redémarrage je pouvais le pinguer mais impossible d’accéder au site et de se connecter en SSH : Operation timed out.
Entre temps, je vois dans la liste des incidents OVH une tâche qui concerne justement de la maintenance sur les serveurs VKS. Je prend mon mal en patience.

Au bout d’un jour et demi d’indisponibilité du serveur, j’écris un tweet en mentionnant Octave à propos de mon problème qui sera ensuite réglé en moins d’une heure.

En fait, je n’avais pas correctement testé mes règles iptables et il se trouvait qu’il y avait une règle invalide qui empêchait de se connecter au serveur… Un peu la honte quand même pour quelqu’un qui auto-héberge chez lui un site…

Pouvoir accéder au serveur

Du coup, cette mésaventure m’a fait prendre conscience que pouvoir accéder physiquement au serveur pour faire un login “classique” est un énorme avantage. Si cela m’était arrivé avec la Sheevaboite, j’aurai tout de suite pu comprendre le problème puisque j’aurai pu me connecter et en régler moi même le problème.

Bref, si Octave n’avait pas répondu à mon tweet, j’aurai probablement du me battre avec le support et dans un cas extrême été obligé de réinstaller entièrement la machine.

Cela fait désormais un sacré moment que j’ai publié ma revue des solutions de synchronisation. Comme souligné par un commentaire récent, un petit retour est nécessaire.

J’utilise git pour coder. J’utilise aussi git pour synchroniser mes fichiers grâce à mon serveur auto-hébergé. Git, c’est bon, il faut en manger matin, midi et soir.
L’idée de dvcs-autosync était bonne, mais il y avait quelques bugs génants et je ne suis pas allé voir les forks. Alors, je pousse mes commits à la main. Ce n’est pas si fastidieux. A part ce point, j’ai cependant un problème. L’un de mes dépôts est dédié à synchroniser des pdf, beaucoup de pdf, environ 500, ce qui représente plusieurs Go. Ajouter/synchroniser de nouveaux fichiers ne pose pas de problèmes, mais si je devais synchroniser à un nouvel endroit, ce serait… interminable.

Il existe un projet kickstarter que je trouve génial. Je ne comprend pas pourquoi peu de gens en parle d’ailleurs. Un joli contre-exemple à ce qui est dit dans cet article de linuxfr. Grâce à l’argent des donateur, l’auteur travaille sur le projet depuis plus de 200 jours et pour les petits tests que j’ai mené, je trouve que le travail est excellent. Si vous vous demandez pourquoi sparkleshare, dvcs-autosync ou sharebox ne conviennent pas, je vous laisse lire son argumentation. Ca fait plusieurs mois que je surveille ce projet, et j’ai décidé de m’y mettre sérieusement. D’où le présent billet.

Quel est le principe de git annex pour gérer les gros fichiers ? Très simple. Plutôt que de synchroniser le fichier lui-même, on synchroniser un lien symbolique pointant vers le fichier. Ainsi, lorsqu’on "pull" le dépôt, on récupère l’arborescence des fichiers qui sont ces liens. Ceci permet de les réorganiser par exemple, sans avoir à télécharger les fichiers. C’est un gain impressionnant. Si on veut lire le fichier, il suffit de télécharger ce fichier spécifiquement. Il peut d’ailleurs être retiré par la suite une fois que les modifications ont été poussée. Ainsi, on gagne de l’espace disque.

Voici en quelque ligne, un usage de base :
git init # crée le dépôt
git annex init "my laptop" # crée une instance annex
git annex add big_file.dat # ajoute un fichier à annex
git ci -a # commit

Maintenant, on clone le dépôt que nous venons de créer :
git clone …
# là, les fichiers ne sont pas lisibles
cat big_file.dat
# mais on peut les télécharger
git annex get big_file.dat
# et les lire !
cat big_file.dat
# et on peut supprimer le contenu en gardant le lien symbolique
git annex drop big_file.dat

Git annex est donc conçu pour des gros fichiers, de type photos, musiques, vidéos, données… et il peut être utilisé pour

• Synchroniser deux machines.
• Partager avec des amis. (jabber inside)
• ou archiver.

Le développeur est Joey Heiss, j’ai déjà parlé ici de ces logiciels (github-backup et ikiwiki).

Un nouvel article sur le wiki qui aborde un nouveau sujet: les sauvegardes. C’est aussi le premier article complet de Kori qui participe déjà au wiki par petites touches depuis quelques temps.

Rsync est bien connu des administrateurs linux comme un outils de sauvegarde très puissant. Mais il peut paraître difficile à maîtriser pour un débutant. Il existe pourtant un module webmin permettant de faire facilement des sauvegardes complètes ou incrémentielles de vos fichiers. Ceci permettra de mettre en place les vôtres très facilement et sans ligne de commande ou presque pour ceux qui ne seraient pas très à l’aise avec.

Ca se passe par là: Administrer ses sauvegardes Rsync avec Webmin.

Bonnes sauvegardes à tous !

Le site de la Sheevaboite a fêté ses 2 ans avec ma totale indifférence, en fait j’ai tout simplement oublié la date de création… Ce n’était pas possible de laisser cet oubli, du coup j’ai pris mon petit éditeur de texte favori et j’ai quelque peu modifié le thème, dont vous voyez le résultat… Si la mode est au “flat design”, pour moi ce sera du “white design”.

Ainsi, pas de grosses folies juste une énième simplification du site :

• Exit la page d’archive très peu consultée,
• Ouste la page des articles trop complexe à maintenir (selon mes critères),
• Au revoir barre de navigation

Et en ce qui concerne les ajouts/retours :

• Le bouton Twitter va faire son retour grâce à ce lien,
• Amélioration de la zone de lecture qui était trop large

Pour l’instant Google Analytics est encore la solution utilisée parce que je n’ai pas encore osé installer Piwik, mais clairement c’est un de mes objectifs à un peu plus long terme.

Voilà, j’espère que vous serez encore plus nombreux à venir lire les articles de la Sheevaboite.

[Le présent article a été griffonné en live sous vos yeux ébahis sur un etherpad... Expérience rigolote que je reproduirai probablement]

Nous avons vu, dans les épisodes précédents, comment fabriquer un bout d’internet local et comment se relier aux autres opérateurs du réseau. Nous avons laissé de côté toute la partie transmission entre les deux blocs, restant appuyés sur ce qui se fait de plus courant et bon marché : l’ADSL.

C’est aussi le seul morceau de notre réseau qui n’est pas sous notre entier contrôle. Sur de très longues distances (comprendre plus de 50/100km) , il est d’ailleurs probable qu’il ne le soit jamais, mais ce n’est pas gravissime.

Le gros problème de l’ADSL, c’est son A comme asymétrique. Retour sur le pourquoi du comment, même si j’ai déjà abordé le sujet. Lorsque les technologies DSL ont débarqué, il a fallu choisir où positionner le curseur séparant le download de l’upload. Si on oublie le (récent) VDSL et qu’on souhaite obtenir un débit symétrique, on est limité à 2Mbps par ligne. C’est le SDSL. Mais en rognant sur l’upload et en allouant une bande de fréquence plus grande au download, on peut obtenir du 1/20. Curieuses lois de la physique.

Une simple constatation a suffi à l’époque : les gens tirent plus sur le réseau qu’ils n’y envoient d’informations. Le choix a donc été fait de privilégier l’ADSL au SDSL, cantonant ce dernier aux usages professionnels, assortis de garanties diverses et variées donnant un tarif final pour le client beaucoup plus élevé (dans l’absolu, un lien SDSL ne coûte pas plus cher à produire qu’un lien ADSL).

Voici le pourquoi du comment on se retrouve aujourd’hui avec un pauvre megabit par seconde en upload chez nous. Si cet état de fait n’est absolument pas bloquant pour un usage personnel voire familial, lorsqu’on se retrouve à 5, 10 ou 50 utilisateurs distincts derrière une liaison qui n’a qu’un seul megabit par seconde de débit montant, on souffre. Beaucoup.

Notre petit FAI local desservant Tatie Martine sera parfait tant qu’on se cantonnera à quelques utilisateurs, mais passé une dizaine, ça va devenir pénible aux heures de pointe, et encore pire si on a expliqué aux gens qu’ils pouvaient héberger leur blog sur leur machine dans leur salon ou se faire une soirée petits chats en HD sur youtube. Alors comment faire pour résoudre à la fois le problème de débit montant, et pourquoi pas, par la même occasion, le problème de « qui gère ma collecte de données entre mon réseau local et mes connexions vers le reste d’internet ? », ou au moins une partie.

Si vous avez l’âme d’un hacker, vous vous êtes probablement déjà posé la question suivante : « si on sait faire un ADSL 1Mbps <> 20Mbps, il suffit d’emmener mon modem au NRA et de prendre celui du NRA chez moi pour avoir 20Mbps <> 1Mbps. En mettant deux lignes ensemble, j’aurai donc 21Mbps <> 21Mbps ». Techniquement, c’est tout à fait réalisable et ça a d’ailleurs déjà été fait. Dans la pratique, « retourner » une connexion ADSL crée des perturbations sur les lignes voisines. C’est d’ailleurs le principal frein à l’adoption du VDSL : proposer plus de débit aux gens proches du NRA, c’est bien, mais si c’est au détriment de ceux, plus éloignés, qui galèrent déjà, c’est moins rigolo.

Revenons donc aux choses faisables, puisque le coup de retourner de l’ADSL n’est pas autorisé par l’ARCEP.

Dans un premier temps, il est possible d’envisager d’associer plusieurs liens ADSL. Pour comprendre le principe, il faut débarrasser votre esprit de l’abonnement ADSL que vous connaissez et l’envisager comme un simple câble reliant deux switchs. Dans un réseau local, si vos switchs sont un minimum évolués, lorsqu’un câble ne suffit plus pour transporter tous les flux, vous pouvez en rajouter un second et expliquer aux switchs que ces deux liens physiques ne forment qu’un seul lien virtuel. C’est le principe du trunk.

Ce principe n’est évidemment pas proposé par les opérateurs grand public sur l’ADSL. On le trouve par contre sur le SDSL, ce qui permet d’agréger plusieurs liens de 2Mbps symétriques, mais toujours à un coût inabordable. Et comme les choses sont bien faites et que nous maîtrisons déjà la machine qui sert à recevoir les liens (le LNS), nous pouvons donc considérer l’ADSL presque comme un vulgaire câble. Le trunk de plusieurs liens ADSL est tout à fait réalisable, même si les logiciels pour le faire, coté LNS, ne sont pas encore tout à fait prêts, les membres de la fédération FDN, dont un particulièrement actif du côté de Sames, travaillent le sujet.

Mais ça reste un palliatif  le problème se posera à nouveau avec le double d’utilisateurs, et continuer à empiler des modems ADSL n’est pas une solution valable à long terme. La question est donc de savoir où trouver un endroit qui nous permettra de relier nos utilisateurs à notre cœur de réseau et quel type de transport utiliser.

On pense d’emblée à la fibre, et d’emblée on se dit « c’est trop cher », on imagine des pelleteuses, de gros engins de chantier, des centaines d’ouvriers et un chèque avec un nombre de zéros inavouable.

Oui, mais non. Enfin, si, évidemment, si vous prenez votre pelle pour creuser depuis Paris jusqu’en Corrèze, ça va coûter très cher ou bien prendre beaucoup de temps, et même probablement les deux. Et en plus, c’est idiot. De la fibre, il y en a déjà partout.

Nous allons prendre un exemple pas trop loin de chez moi, au cœur de la Bourgogne à Dijon. Il n’y a pas de fibre, dans le sens où personne ne peut s’abonner à la fibre par l’agrume. Mais sinon, il y a un tas de fibres, dont une partie arrive 41 quai Gauthey. Comment je le sais ? C’est marqué sur le site de l’exploitant des lieux : la societé Cogent. Il s’agit d’un opérateur réseau qui fait aussi de l’hébergement d’infrastructure. Ils ont accessoirement un réseau national qui relie toutes leurs salles. Et quand on téléphone à ces gens là, on obtient assez facilement un devis. Pour faire Dijon – Paris, à 100Mbps symétriques, ça va vous coûter autour de 400 euros par mois.

Ce n’est évidemment pas donné comme les 30 euros par mois de la fibre de monsieur SFR, mais on est loin des 2 euros le mètre de fibre le long de l’autoroute, et 100Mbps symétriques, ça peut permettre d’alimenter au moins une centaine d’abonnés, sinon plus. 100 abonnés, payant chacun 30 euros par mois, ça fait 3000 euros par mois. 400 euros de transport représente donc un poil plus de 10%, reste pas mal de blé pour faire des choses sympathiques à côté (transit, hébergement d’infrastructure, amortissement rapide du réseau wireless, baisse du prix pour les abonnés les moins fortunés…).

Et en prime, cette liaison, ce n’est plus de l’ADSL avec des modems, des trucs à configurer, des LNS à avoir. Non, c’est un vrai point à point, comme un câble ethernet entre deux switchs. D’un coup, votre infrastructure se simplifie drastiquement. Et le jour où 100Mbps sont insuffisants, un petit coup de fil à l’opérateur, et votre débit passe à 200, 500 ou 1Gbps, et les coûts au Mbps baissent avec le volume qui augmente.

Vous me direz : « oui, mais moi, j’habite pas à Dijon, et dans mon coin, il n’y a pas de datacenter qui propose des liaisons vers Paris ou Lyon ou Tataouine-Les-Bains, donc je suis marron ».

Non, vous n’êtes pas marron, ça va juste vous coûter un peu plus cher.

Parce qu’aujourd’hui, Orange fait la fine bouche en disant « ouiii mais ça coûte cheeeer de fibrer tout le mooooonde ». Évidemment, quand on va vendre 30 € / mois / client, et qu’on n’a aucune idée du nombre de clients qui vont signer, il faut réfléchir à comment on dépense son pognon. Mais dans notre cas, nous ne sommes pas à la recherche d’une connexion fibre à 30 € / mois pour y coller tous nos utilisateurs, nous savons déjà combien ils sont, ce qu’ils paient et on cherche juste un lien point à point vers notre cœur de réseau.

Alors, on peut parfaitement téléphoner à monsieur Orange et demander la division opérateur pour obtenir une fibre. Oui : PRESQUE-OÙ-ON-VEUT.

Ça va juste avoir un coût : dans les 5000 € pour son installation et un peu plus de 1200 € / mois par la suite (offres CE-LAN ou CE2O). Notez que si on reprend les 3000 € de chiffre d’affaire dont on parlait plus haut, ça n’a rien d’inabordable, surtout si on compare ça au coût d’une ligne ADSL par utilisateur ou même pour deux ou trois utilisateurs (de 800 à 2500 €, sur une base de 100 utilisateurs).

Et même mieux, si on parvient à embarquer avec soi quelques entreprises, par exemple dans une zone industrielle délaissée, isolée au milieu d’un joli plateau campagnard, les entreprises de la zone peuvent prendre en charge ce coût, quasi marginal à l’échelle d’une entreprise, même petite) et en faire bénéficier les habitants autour.

Et une fois que vous avez votre fibre, chez Orange ou n’importe quel autre, livrée à un point A, il vous suffit de lui mettre une antenne aux fesses pour y relier tous vos utilisateurs de la même façon qu’ils étaient reliés via l’ADSL avant.

Ces deux solutions existent parmi une quasi infinité d’autres. Il faut juste garder à l’esprit qu’elles sont presque toutes spécifiques et souvent dépendantes du lieu et des opportunités. Les grands plans nationaux de montée en débit sont donc à ranger définitivement au placard pour s’intéresser à ce qui peut et doit être fait localement. Par exemple, une ville comme Dijon qui dispose déjà d’un réseau optique desservant toutes les installations de la collectivité devrait ouvrir ce réseaux aux initiatives locales pour éviter d’avoir à déployer des installations wireless et passer directement à la fibre là où c’est possible.

Malheureusement, le do-it-yourself n’a pas encore assez creusé son trou pour que nos personnalités politiques jugent ce genre d’initiative pertinent, alors qu’elles sont probablement les seules à être valables, à court comme à long terme.

Vous me direz, si vous avez bien tout suivi, que les solutions en question ne vous rendent pas indépendant pour autant. Dans un sens, c’est vrai : le support qui transporte les données des utilisateurs entre votre réseau wireless local et votre cœur de réseau connecté à internet est toujours la propriété d’un autre, mais à la grande différence de l’ADSL, vous bénéficiez ici d’un support réservé au monde des opérateurs avec des garanties fortes en terme de délais de rétablissement, un vrai support en cas d’incident et une souplesse d’utilisation incomparable vous permettant d’imaginer des infrastructures avec des VLAN ou même du MPLS et une flexibilité d’upgrade rapide et sans modification de l’existant.

Dans le prochain épisode, on fera un peu de promenade campagnarde et d’étude des topologies wireless pour bien penser dès le début son réseau, histoire de ne pas se retrouver coincé par la suite.

Aujourd'hui petite exception, ce n'est pas moi qui vais rédiger cet article. Je laisse la parole à des passionnés d'auto-hébergement qui nous présente leur projet de Cloud personnel libre : Cozy !

Bonjour à tous, chez Cozy Cloud, une jeune startup, nous sommes de fervents défenseurs du logiciel libre et de sa culture. Et comme en plus, nous ne sommes pas satisfaits du modèle actuel des services web, nous cherchons à redonner le contrôle de ses données et services à l'utilisateur. Pour cela nous vous proposons un projet libre auto-hébergeable nommé Cozy.

Cozy renverse le modèle existant en donnant un serveur à chaque utilisateur sur lequel il centralise ses données. Un Cozy n'est pas une distribution Linux mais une collection d'applications webs. Les applications partagent les données et des fonctionnalités entre elles permettant une intégration forte et de nouveaux usages. En effet, nous pensons que cette architecture est propice à l'émergence d'applications innovantes tirant parti des données personnelles en toute transparence (restitutions de données, quantified-self, objets connectés, ...). Des services plus classiques comme le partage de fichiers/photos, la prise de notes/todos et les emails sont bien évidement de la partie.

Pour rentrer dans les détails techniques et concrets, on peut dire que c'est une suite d'application écrite en Node.js accolées à une base de donnée Couchdb et à un serveur d'indexation écrit en Python. Un des modules permet de télécharger, démarrer et arrêter facilement des applications écrites en Node.js. Ce qui veut dire que vous pouvez très facilement ajouter votre propre application (plus de détails sur l'architecture ici).

Installation (pour Debian/Ubuntu)

Pour faciliter l'installation, nous mettons à votre disposition un script d'installation Fabric. Fabric est une technologie permettant d'exécuter des commandes sur un serveur distant depuis votre machine locale. Il vous faudra donc d'abord installer python, Fabric et son extension Fabtools, sur votre machine locale pour pouvoir ensuite déployer la « stack » Cozy sur votre serveur distant.

Téléchargez ensuite le script Fabric qui lancera les commandes sur votre serveur distant :

wget https://raw.github.com/mycozycloud/cozy-setup/master/fabfile.py

Pour finir, démarrez le script en indiquant le sudoer ou l'utilisateur root de votre serveur ainsi que l'adresse IP de votre serveur (celui ci doit autoriser un accès SSH).

fab -H user@ip install

Le script vous demandera une série d'informations pour générer le certificat HTTPS. Vous pouvez entrer ce que vous voulez. Il vous réclamera aussi un nom de domaine qui correspond au domaine où vous hébergez votre Cozy. Cela est utile pour générer des urls dans le mail d'oubli de mot de passe.

NB: En raison du nombre de technologies installées, nous vous recommandons l'installation dans une machine virtuelle ou dans un conteneur si votre serveur le permet.

Démarrage

Lorsque l'installation est terminée, vous n'avez plus qu'à vous enregistrer sur : https://IP. 

Attention : Si vous voyez seulement la page d'accueil de NGINX c'est qu'il vous faut utiliser le protocole HTTPS.

Ensuite vous accédez à vos apps en un clic.

Un clic sur le bouton Apps en haut à droite vous donne accès au repository d'applications. Écran dans lequel vous pouvez aussi indiquer l'url du dépôt git d'une application que vous avez créée.

Pour mettre à jour ou supprimer une application, il faut simplement revenir sur la page d'accueil, cliquer sur le bouton manage et cliquer sur le bouton update/remove de l'application concernée :

Voilà vous savez déjà comment administrer votre cloud perso avec Cozy ! Si vous avez besoin d'aide vous pouvez nous retrouver sur #cozycloud sur freenode.net ou tout simplement nous envoyer un mail à contact@cozycloud.cc . Vous trouverez également dans la suite quelques liens qui pourront vous être utile.

Site du projet

Guide de création d'applications

Détail de l'installation de Cozy

Site de la société (solution d'hébergements)

Travaillant en ce moment sous la solution de TOIP Elastix, j’ai voulu voir si Raspberry Pi serait capable de l’encaisser. Il s’avère qu’il existe une version (officielle!) de Elastix pour les micro PC sous ARM : micro-Elastix. Voyons comment elle tourne sur le Raspberry Pi.

Matériel :

• RaspBerry Pi Model B + carte SDHC 4Go (acheté grâce à Idealo sur Amazon)
• Switch TP-Link TL-SF1008P + Téléphones IP Aastra

URL de téléchargement de  l’image micro-elastix (700Mo environ) : http://elx.ec/armimg

Site officiel micro-elastix : http://uelastix.org

 J’ai procédé à la préparation et à l’installation de micro-elastix depuis mon portable sous Linux Mint (donc les manip seront les même sous Ubuntu).

Préparation de la carte SD

Avec gparteg, on crée 2 partitions sur la carte SD, une première de 512Mo en FAT16, étiquetée « BOOT », et une seconde en EXT3, étiquetée « rootfs », du reste de la taille de la carte (3500Mo). Les partitions ainsi créées se sont montées sur mon système dans les dossiers /media/timcruz/BOOT et /media/timcruz/rootfs. Reste maintenant à copier Elastix sur la SD.

Copie de micro-elastix sur la carte SD

L’image de micro-elastix optimisée pour Raspberry Pi est disponible ici. Il s’agit d’une archive tar contenat deux autres archives : BOOT.tar.gz et rootfs.tar.gz (jusque là tout est très logique). On décompresse donc ce tar pour avoir les 2 archives dans un dossier.

Maintenant on va extraire le contenu des archives dans la partition du même nom :

tar -C /media/timcruz/BOOT/ -xzf BOOT.tar.gz
tar -C /media/timcruz/rootfs/ -xzf rootfs.tar.gz

La carte SD est maintenant prête et il ne reste plus qu’à démarrer son Raspberry Pi avec sa carte SD branchée.

Micro-Elastix sur le Raspberry-Pi

Par défaut, le Raspberry démarre avec l’ip 192.168.1.251 et avec le service DHCP désactivé, Elastix sera donc simplement accessible à l’URL http://192.168.1.251. Presque tous les services de Elastix sont opérationnels (ne fonctionnent pas : la messagerie instantanée, le service Fax et le Call Center). La version d’Elastix embarquée lors de mon test est la 2.4.0.

Le compte par défaut pour accéder à Elastix est admin, son mot de passe étant palosanto. Le compte sera le même pour l’accès en SSH (ouvert par défaut).

Par contre, le processeur du Raspberry Pi prend très cher et le dashboard annonce une charge CPU de 100%. Pour mes tests, j’ai utilisé (avec succès) mon Raspberry Pi sous MicroElastix avec un switch TP-LINK TL-SF1008P (qui a le double avantage d’être abordable et PoE) et des téléphones Aastra.

Concrètement, on a ici une plateforme de test opérationnelle sur laquelle on connectera 1-2 téléphones à condition d’avoir overclocké un minimum le processeur de votre Pi (procédure simple et qui maintient la garantie du Raspberry Pi). Pour 80€ le serveur, qui dit mieux?

La version alpha de l’image du serveur helios.im est disponible ici : http://wiki.helios.im/index.php/Img avec des instructions détaillées pour l’installer et la configurer. En anglais seulement pour l’instant. Ce n’est pas plus difficile que d’installer l’image Raspbian ‘Wheezy’.

L’installation sur carte SD n’est pas recommandée, sauf pour tester pendant quelques jours. La corruption des données avec plantage probable du serveur est garantie, même sur une carte haut de gamme, dans un délai imprévisible variant entre quelques jours et quelques mois.

Préférez un disque dur externe usb (qui nécessitera alors un hub pour l’alimentation électrique) ou une clef usb haut de gamme.

Du coup, la boutique doit être réorganisée pour tenir compte de ce changement technologique et n’ouvrira donc pas immédiatement.

Si vous n’avez pas la chance d’être hébergé par un fournisseur d’accès qui propose une ip fixe, nous pouvons vous offrir l’accès au DNS dynamique helios.im, contactez-nous!

Que feriez-vous ?

Le titre est provocateur. Pour ceux qui n’utilisent pas github, je me doute que vous ne ferez rien. Quoique…

Comme vous le savez, github est un service de gestion de projet utilisant git. Comme tout service administré par un tiers (qu’il soit libre ou non, ça ne change rien), sa pérennité n’est pas assurée.

Contrairement à beaucoup de services du "cloud", l’utilisation de github n’est pas le mal absolu, car étant basé sur un gestionnaire de version décentralisé, chaque contributeur possède une copie locale avec l’historique du code.
Théoriquement, si github fermait, nous devrions pouvoir tout reconstituer avec ce que nous avons sur nos disques.

Dans la pratique, s’assurer d’avoir des copies à jour de ce qui nous intéresse, ce n’est pas du luxe. Joey Hess, l’un des développeurs dont j’apprécie le travail, a développé github-backup.
Le logiciel est codé en Haskell et publié en GPL. L’utilisation est triviale, il suffit de lire le README.

Le principale avantage de ce logiciel est de récupérer les tickets ainsi que les forks (aspect de récursivité). C’est donc une sauvegarde complète. La limite provient de l’API de github, qui limite les requêtes. Il faut donc lancer parfois plusieurs fois le script, surtout lors de la première copie. Ensuite, naturellement, ça fonctionne en "diff".

Pour ma part, j’ai mis ce code python en trois minutes et lancé en tâche cron sur mon serveur. a, b et c sont bien entendu des dépôts fictifs.

#!/usr/bin/env python3
# -*- coding: utf-8 -*-
# Author: Francois Boulogne
# License: GPLv2+

import os
from subprocess import call
import random

repos = ['a',
        'b',
        'c',
        ]
random.shuffle(repos)

backup_dir = os.path.expanduser('~/github_backup')

soft = 'github-backup'

for repo in repos:
    backup_path = os.path.join(backup_dir, repo)
    os.makedirs(backup_path, exist_ok=True)
    os.chdir(backup_path)
    call([soft, repo])

En quelques mots, le fonctionnement. Je mélange ma liste de dépôts. De cette manière, je ne commence jamais par le même dépôt, et j’évite qu’un dépôt sature le compteur de l’API de github et empêche ainsi la sauvegarde d’autres dépôts. Pour le reste, je crée des répertoires et je me place dedans pour synchroniser. Il faudrait que je maintienne un log pour être propre, avec le sortie de la commande.

On pourrait ensuite mettre en place une interface web là-dessus comme gitweb pour avoir un miroir visible par d’autres.

A titre personnel, je synchronise mon espace, mais aussi les projets que j’apprécie et qui sont hébergés sur github. Ce sont parfois de petits codes qui ne font pas la une de linuxfr, mais j’y accorde beaucoup d’importance.

Pour ce qui est de la question original, j’essaie de me poser systématiquement la question sur ce qui m’environne. Et si ça disparaissait ? Comment serait-je affecté ? Comment puis-je l’anticiper pour que ça se passe au mieux ?

La distribution SME Server vous connaissez, c’est ce Linux si particulier qui vous permet d’outrepasser les services de Google et d’avoir à domicile votre Cloud et vos données, à une époque ou il est des plus importants de pouvoir contrôler ce qui peut circuler ou ce qui doit rester privé.

Ce projet communautaire à connu de grand chambardement en cette fin d’année 2012, avec un électrochoc que nous devons à un « fork » philosophique Nethserver qui a permis de redonner un souffle et une envie d’aller de l’avant. En effet la SME Server 9.0 est sur les rails (en version alpha3), le passage des contribs compatibles vers leur dépôt est en passe de se terminer, la documentation à vu un sérieux coup de lifting, et moi…j’aime bien sentir cet air frais remplir mes poumons :-/

Mais ce n’est pas tout, La SME Server souffrait d’un manque de cap, d’un manque de décisions qui faisait que cette distribution à vocation de serveur de Cloud personnel et d’entreprise s’était endormi sur ses lauriers.

Nous avons voulu avec un groupe de toutes nationalités (Anglais, Américains, Néo-zélandais, Allemand, Français, Italien), de tous niveaux de compétences, offrir pendant 18 mois notre expérience et notre envie de propulser au plus loin que la communauté nous le permettra, notre distribution préférée.

Pour cela nous avons crée une Fondation en Oregon (US) à but non lucratif dont le bureau est nommé pour les 18 mois prochains afin de se consacrer plus sur les efforts et les actions à mener que sur les débats si nous mettions des élections immédiates.

Bon là comme a si bien dis John, il est temps de ressortir le « guide du voyageur galactique » et de reprendre sa phrase favorite « don’t panic« 

Tout de suite pour ceux qui viendront avec le « Non » avant de venir proposer quelques chose de constructif…je tiens à les rassurer, SME restera Libre et Open Source. (ARTICLE V)

• Membres du bureau

President : John Crisp (GB)
Secretaire : Tony Keane (NZ)
Tresorier : Greg Zartman (US)

• membres du conseil d’administration :

Daniel Berteaud (FR)
Stéphane de Labrusse (FR)
Shad Lords (US)
Hsing Foo Wang (D)
Stefano Zamboni (IT)
Ian Wells (GB)

La première tache à laquelle nous nous sommes attelés est d’ancrer et de protéger la « marque » communautaire et open-source de la SME Server. En effet de nombreux cybersquatteurs se sont emparés du nom, empêchant toutes utilisations  associatives ou commerciales.

Un exemple, il suffit de voir que smeserver.com est une entreprise crée dans l’utah et que smeserver.us redirige vers…Microsoft himself…..BOUH!

L’idée est de redonner un souffle, une envie, un électrochoc à notre rêve éveillé, pour cela nous avons trouvé le nom qui caractérise le mieux ce renouveau pour nous que sera la version 9

Koozali SME Server

Nous avons commencé à travailler sur les logos et vous pouvez voter pour celui qui vous plaira le plus…le travail est soigné…à vous de juger maintenant !

Koozali Nouveau Logo

La SME Server est une Distribution qui provient de la nuit des temps et qui a manqué depuis longtemps d’une gouvernance et d’un cap à tenir…car vous pouvez avoir la carte (ou le code) sans direction à suivre vous tournez en rond.

Nous espérons pouvoir regrouper autour de Koozali tous les niveaux nécessaires du débutant au développeur, car une distribution Linux c’est avant tout une formidable aventure humaine qui voit des hommes et des femmes de tout bord travailler vers un but Commun.

Notre seconde tache sera d’assurer un avenir financier, sans parler de rentabilité, puisque notre distribution a très peu de contributeurs financiers. François Elie a une phrase géniale que je vais utiliser  :

« Un logiciel libre est gratuit une fois qu’il a été payé »

Voila C’est tout pour l’instant…Pensez à choisir le Logo

cd/tmp
wget http://download.gna.org/jyraphe/jyraphe-0.5.tar.gz
tar zxvf jyraphe-0.5.tar.gz
mv jyraphe/pub/.* /var/www/jyraphe
mv jyraphe/pub/* /var/www/jyraphe
chown -R www-data:www-data  /var/www/jyraphe

cd /vos/fichiers/     # se place dans le répertoire où seront vos fichiers en dehors de la racine du site
mkdir var             # crée le répertoire var/
mkdir var/files       # crée le répertoire var/files
mkdir var/links       # crée le répertoire var/links
mkdir var/trash       # crée le répertoire var/trash
chgrp -R www-data var # change le groupe pour celui du serveur web
chown -R g+w var      # donne les droits d'écriture au serveur web

Order deny,allow
Deny from all

rm /var/www/jyraphe/install.php
 chmod u-w /var/www/jyraphe/lib/config.local.php

EDIT: J’avais besoin d’avoir genre une page de téléchargement directement car je suis en local et que je n’ai pas de risque majeur de piratage, bon sur le net ne le faites pas.

du coup j’ai rajouté cette ligne à la fin du fichier

/lib/template/header.php

<div id="content">
<h1><a href="<?php echo $cfg['web_root']; ?>"><?php echo _('Pirate-Box, Votre dépôt de fichiers'); ?></a></h1>
<a href="http://pirate/var-data/files">Liste des fichiers Téléchargeables</a>

ou  /var-data doit être adapté aux dossier de donnée que vous avez déclaré lors de l’installation.

Après cela vous aurez un beau lien directement en haut de la page qui vous amènera dans le dossier contenant tous vos téléchargements.

EDIT : jyraphe s’appuie sur php pour déterminer la taille des fichiers que vous pouvez uploader, du coup pour lever cette limite, vous pouvez soit fixer cette limite dans le .htaccess soit directement dans le fichier /etc/php5/apache2/php.ini

; Maximum allowed size for uploaded files.
; http://php.net/upload-max-filesize
upload_max_filesize = 50M

et

; Maximum size of POST data that PHP will accept.
; http://php.net/post-max-size
post_max_size = 50M

ou dans le .htaccess

# Allow large file uploads
php_value post_max_size 50M
php_value upload_max_filesize 50M

Crédit photo : Pascal Charest

Après une petite incartade au pays du chiffrement et des e-monnaies, retour aux fondamentaux. Dans les épisodes précédents, on a à peu près fait le tour des choses minimales à traiter pour monter un petit fournisseur d’accès. Place maintenant à un peu d’envers du décor. Abordons ce qu’il convient de faire pour assurer ses arrières quand on bosse sur un réseau qui n’est plus local. Attention, chacun a ses méthodes préférées, je n’ai pas la prétention de les lister toutes, juste de vous présenter ce avec quoi j’ai, moi, l’habitude de travailler.

Le maître mot est l’accès aux équipements. Quand on construit un réseau, si l’équipement d’un client est en panne, c’est pas la mer à boire. Par contre, si c’est un bout ou la totalité du coeur de réseau qui part en sucette, c’est plus enquiquinant, vu que tout ou partie des utilisateurs se retrouvent dans le noir.

Il existe pour moi deux grandes familles de solutions qui se complètent très bien :

Le réseau d’administration

L’idée est de séparer, si possible physiquement, sinon logiquement, le morceau de réseau qui sert à administrer les équipements de celui qui sert à transporter les données des utilisateurs. Plusieurs avantages :

• les flux de données sont totalement séparés, ce qui rend donc beaucoup plus difficile pour un attaquant de s’en prendre à vos équipements puisqu’ils ne sont pas publiquement accessibles
• Corollaire, puisqu’ils ne sont pas publiquement accessibles, vous gagnez de précieuses adresses IP en les numérotant avec des IP privées (sauf si, bien entendu, vos équipements sont assez récents pour supporter l’adressage d’administration en IPv6)
• La topologie de votre réseau administratif peut être différente de celle du réseau client

On va surtout s’intéresser à ce dernier avantage. Lorsqu’on parle d’un réseau de fourniture d’accès, surtout dans le cas où celui-ci met en jeu des liens ADSL en cours de route, il peut être pratique de segmenter le réseau. Exemple concret, sur un réseau wireless, vous avez un point haut qui est capable de desservir deux villes, l’une va être sur un VLAN dédié, l’autre sur un second, ce qui permettra facilement de les relier à deux ADSL distincts et de basculer des utilisateurs de l’un à l’autre, le tout sur un même réseau physique.

Mais pour l’administration, on préférera souvent limiter au maximum les dispositifs de routage qui peuvent être plus capricieux que le reste. On aura donc un seul et unique VLAN d’administration qui sera global à toute l’infrastructure.

Là où ça se corse, c’est si votre réseau devient très étendu et dispose de chemins multiples. La boucle ethernet vous guette du coin de l’oeil et vous tombera sur le dos un jour ou l’autre. Pour adresser ce problème, on se tournera vers une autre solution :

Les accès « out of band »

L’idée est de se ménager des accès au réseau d’administration depuis d’autres réseaux. Idéalement, un par site physique distinct, pour pouvoir reprendre la main sur les équipements en cas de problème.

Concrètement, ça passe par exemple par la souscription d’une ligne ADSL chez Orange livrée au pied d’un pylône important de l’infrastructure si on sait que le gros de celle-ci repose sur des liaisons ADSL SFR. Ainsi, en cas de chute globale ou localisée de SFR, il est toujours possible de prendre la main sur le pylône via l’ADSL Orange et, si on se débrouille bien, de rétablir l’accès en trafiquant les configuration.

Dans le prochain épisode, on reparlera transport de données et montée en débit, parce que l’ADSL ça va bien 5 minutes.

Gestion automatique des paquets.

Il existe chez Debian plusieurs méthodes permettant la gestion automatique des paquets, entres autres en ce qui concerne les mises à jour.

Dans un environnement de bureau comme Gnome, des utilitaires tels que update-manager permettent d'être informé en cas de présence de mises à jour et même d'en appliquer automatiquement, typiquement celles relatives à la sécurité.

Qu'en est-il pour une machine tel qu'un serveur où vous n'avez aucune envie d'installer ces utilitaires haut niveau ? C'est l'objet de cet article dans lequel est présenté la solution cron-apt.

Notez qu'il existe des alternatives à cron-apt. unattended-upgrade propose une autre approche basée sur APT::Periodic, elle est peut être plus simple à mettre en place, elle n'autorise cependant que des mises à jour sur une fréquence quotidienne.

cron-apt

L'installation par défaut de cron-apt place une cron dans /etc/cron.d/cron-apt exécutée quotidiennement à 4 heure du matin. Il est cependant possible de modifier /etc/cron.d/cron-apt à volonté pour excuter cron-apt plus fréquemment ou même avec des configurations alternatives. Les fichiers de /etc/cron.d/ permettent une planification plus précise et fréquente que la cron /etc/cron.daily/ utilisé par APT::Periodic.

cron-apt appellera chaque jour les actions déclarées dans les fichiers de /etc/cron-apt/action.d/. L'ordre numérique des noms de fichier est respecté pour l'appel des actions.

Le format des actions déclarées dans les fichiers de /etc/cron-apt/action.d/ est simple, il s'agit des arguments et options passés à apt-get. Il est possible de définir une autre commande via la variable APTCOMMAND (cf. fichier /etc/cron-apt/config), cependant le reste de cet article est basé sur la configuration par défaut, à savoir apt-get. Un fichier de /etc/cron-apt/action.d/ peut contenir plusieurs actions à raison de une par ligne.

Un rapide coup d'oeil dans /etc/cron-apt/action.d/ montre la présence de deux actions installées par défaut :

• 0-update:

  update -o quiet=2

• 3-download:

  autoclean -y
  dist-upgrade -d -y -o APT::Get::Show-Upgraded=true

L'installation par défaut va donc synchroniser l'index répertoriant les paquets disponibles (0-update) et télécharger les mises à jour disponibles sans les installer (3-download). Cette action réalise aussi un nettoyage des paquets téléchargés dans le cache mais dont la version est obsolète.

Cas pratique des mises à jour de sécurité

Une utilisation particulièrement intéressante de cron-apt est l'installation automatique des mises à jour de sécurité. Ci dessous est détaillée la configuration nécessaire pour y parvenir.

Les mises à jour de sécurité automatiques sont envisageables car elles sont dans l'écrasante majorité des cas faisables sans intervention de l'utilisateur (fichiers de configuration des paquets identiques, pas d'écran debconf).

Avant de commencer la configuration, veiller à déposer un fichier vide, nommé refrain dans /etc/cron-apt, cela annulera toute tentative d'exécution de cron-apt qui pourrait être malheureuse en cas de configuration incomplète.

Commençons maintenant par créer une nouvelle action : 6-upgrade. Le fichier du même nom contiendra l'appel à apt-get permettant la mise à jour des paquets dans leur version supérieure, soit "upgrade". De plus il faut indiquer à apt-get de n'utiliser que les paquets en provenance du dépôt security.debian.org. Voici à quoi doit ressembler le fichier /etc/cron-apt/action.d/6-upgrade :

upgrade --config-file /etc/cron-apt/cron-apt.conf

Afin que apt-get ne pioche que parmi les paquets de security.debian.org il faut écrire une configuration alternative de apt qui est indiqué --config-file . Créer le fichier /etc/cron-apt/cron-apt.conf et ajouter la configuration suivant :

APT::Default-Release "wheezy";
APT::Get::Assume-Yes "true";
Dir::Etc::SourceList "/etc/cron-apt/security.list";
Dir::Etc::SourceParts "/dev/null";
// Ligne à supprimer pour effectivement réaliser les mises à jour.
APT::Get::Simulate "true";
//

Quelques explications

Dir::Etc::SourceList : Cette configuration alternative de APT repose donc sur un fichier de sources spécifiques pour le dépôt de sécurité, ici "/etc/cron-apt/security.list". Veillez à bien créer ce fichier et à le remplir convenablement avec le dépôt de sécurité.

Dir::Etc::SourceParts : Par défaut apt ajoutera toutes les sources déclarées dans /etc/apt/sources.list.d/. Avec cette option configurée à "/dev/null" seul le fichier déclaré précédemment dans Dir::Etc::SourceList sera lu.

APT::Get::Assume-Yes : Cette option permet l'exécution non interactive.

APT::Get::Simulate "true"; : Un garde fou permettant de tester la configuration en toute sécurité. Avec cette options les actions de apt-get seront uniquement simulées, aucun paquet ne sera installé. Par défaut cron-apt va écrire dans les log système. Vous pouvez par exemple surveiller /var/log/syslog pour vérifier qu'il se comporte correctement.

Test et mise en production

Une fois que la configuration est en place vous pouvez tester l'ensemble. Retirer le ficher /etc/cron-apt/refrain et exécuter cron-apt avec les droit de root. Placer DEBUG="verbose" dans /etc/cron-apt/config et contrôler le résultat dans /var/log/cron-apt/. Quand vous êtes satisfait, commenter la ligne "APT::Get::Simulate" et modifiez /etc/cron.d/cron-apt en fonction de vos besoins.

Pour être informé par mail des mises à jour appliquées par cron-apt, utilisez la configuration "MAILON=upgrade" dans /etc/cron-apt/config.

Je vous l'avait dit, je voulais mettre en place un système de sauvegarde distante de mon serveur perso. Ces sauvegardes devaient être automatiques, sécurisées et peu coûteuses en énergie. J'ai trouvé mon bonheur avec la mise en place d'un Raspberry Pi, loin de chez moi, sur lequel j'ai branché un disque dur externe chiffré et où mes sauvegardes sont exportées (synchronisées) toutes les nuits. Voici comment j'ai fait :

Rappel des besoins

Voici ma "politique de sauvegarde" actuelle : j'ai mon serveur personnel chez moi dans lequel se trouve deux disques durs : un principal, sur lequel se trouve mon OS et mes données et un autre disque, sur lequel je synchronise les données à sauvegarder présentes sur mon premier (j'avais expliqué comment je faisais tout ça dans cet article).

Je voulais mettre en place une sauvegarde distante automatique, sécurisée et pas chère. L'objectif est de dupliquer mon deuxième disque dur sur un disque externe distant chiffré. J'ai trouvé mon bonheur avec ce matériel :

• Un Raspberry Pi
• Un Hub alimenté
• Un disque dur externe chiffré

Coût total du projet : Raspberry Pi + Boitier + Carte SD + Clé WiFi + Disque dur externe d'occasion = environ 70€

Cette mise en place se déroule en 3 grandes étapes que je vais expliquer :

1. Installation du Raspberry Pi
2. Déchiffrage du disque dur
3. Synchronisation des données

Installation du Raspberry Pi

Matériel

J'ai donc décidé de mettre en place le Raspberry Pi chez mes beaux parents. Il sera placé dans le fin fond d'une pièce, dans une belle boite prévue à cet effet :

WiFi

Le premier problème à été de mettre en place le WiFi. La box de mes beaux parents étant configuré en WEP, j'ai eu du mal à y associer le Raspberry Pi. Après quelques essais infructueux, j'ai décidé de les passer en WPA, ce qui augmente la sécurité et (surtout) facilite la configuration de mon Raspberry. Je n'ai eu plus qu'à suivre ma documentation pour configurer le tout correctement.

IP dynamique

Ensuite est venu un deuxième gros problème : mes beaux parents sont chez Orange et ont donc une adresse IP dynamique. Comme mon nom de domaine est géré chez OVH, j'ai suivi leur documentation pour paramétrer un champ DynHost et associer une URL à la livebox de manière permanente. J'ai tout de même patché le petit programme qu'ils fournissent en modifiant cette ligne du fichier dynhost :

IP=`/sbin/ifconfig $IFACE | fgrep "inet ad" | cut -f2 -d":" | cut -f1 -d" "`

par celle-ci :

IP=`wget http://checkip.dyndns.org/ -O - -o /dev/null | awk '{ print  $6 }' | cut -d "<" -f 1`

Sans ce patch, l'IP renvoyée à OVH (et associée à mon URL) est l'IP privée de mon Raspberry et non pas l'IP publique de la Livebox (sic).

C'est prêt

Une fois toutes ces choses faites, j'ai bien un Raspberry Pi qui tourne dans un coin de chambre à 100 Km de chez moi et qui répond toujours à la même URL (malgré son IP dynamique).

Déchiffrage du disque dur

Le Raspberry Pi n'étant pas chez moi (je ne peux pas savoir qui rentre et sors chez mes beaux parents), je voulais chiffrer mon disque dur afin que mes données soient illisibles en cas de vol de mon disque dur externe.

Pour faire cela, j'ai déjà dû, dans un premier temps, "l'initialiser" (le chiffrer). J'ai utilisé le logiciel Truecrypt et j'ai expliqué cette manipulation dans cet article. Sur mon Raspberry Pi, il me suffit ensuite d'installer Truecrypt afin de déchiffrer et d'exploiter ce disque.

Installation de Truecrypt

L'installation de truecrypt est un peu compliquée sur le Raspberry Pi. En effet, le processeur de ce dernier est un ARM. L'installeur de truecrypt est compatible avec les architectures x84 et x64. Autrement dit, l'installation "facile" (que j'avais expliquée dans mon article) ne marche pas sur le Raspberry et il faut compiler soi même le programme.

Par manque de temps (et par fainéantise), j'ai préféré récupérer un binaire déjà compilé (en version 7.1a) plutôt que de le faire moi-même (pourquoi réinventer la roue ?). Je vous le propose à mon tour : vous pouvez le récupérer en tapant cette commande en tant que root sur votre Raspberry Pi :

wget http://www.generation-linux.fr/dl/truecrypt -O /usr/local/bin/truecrypt && chmod +x /usr/local/bin/truecrypt

Cette commande va :

1. récupérer le binaire trucrypt compatible avec le Raspberry Pi (fonctionne avec la Raspbian Wheezy) ;
2. le mettre dans le répertoire /usr/local/bin (pourquoi ce répertoire ?) ;
3. le rendre exécutable.

Désormais, vous pouvez utiliser truecrypt en l'appelant simplement dans votre ligne de commande :

truecrypt --version

Montage (déchiffrage) du disque dur externe

Une fois que truecrypt est installé, je vais pouvoir l'utiliser pour déchiffrer mon disque dur externe. Avant cela, un df me montre que mon disque n'est pas encore monté sur mon système :

root@yoshi:~# df
Sys. fich.     1K-blocks   Util. Disponible Uti% Monté sur
rootfs          15443952 2076020   12583668  15% /
/dev/root       15443952 2076020   12583668  15% /
devtmpfs          240516       0     240516   0% /dev
tmpfs              49756     260      49496   1% /run
tmpfs               5120       0       5120   0% /run/lock
tmpfs              99500       0      99500   0% /run/shm
/dev/mmcblk0p1     57288   21056      36232  37% /boot

Pour le monter, il suffit de taper la commande suivante : truecrypt /dev/sda1 /mnt/
Truecrypt me demande le mot de passe associé à mon disque dur, mon keyfile (tapez entrer directement si vous n'en avez pas) et s'il faut monter un dossier caché. Une fois ceci fait, vous verrez que le disque est bien monté dans le répertoire /mnt/ :

root@yoshi:~# truecrypt /dev/sda1 /mnt/
Enter password for /dev/sda1:
Enter keyfile [none]:
Protect hidden volume (if any)? (y=Yes/n=No) [No]:

root@yoshi:~# df
Sys. fich.             1K-blocks    Util. Disponible Uti% Monté sur
rootfs                  15443952  2076028   12583660  15% /
/dev/root               15443952  2076028   12583660  15% /
devtmpfs                  240516        0     240516   0% /dev
tmpfs                      49756      264      49492   1% /run
tmpfs                       5120        0       5120   0% /run/lock
tmpfs                      99500        0      99500   0% /run/shm
/dev/mmcblk0p1             57288    21056      36232  37% /boot
/dev/mapper/truecrypt1 153835300 67334292   78686572  47% /mnt

Un petit ls -l /mnt/ me confirme bien que mon disque est monté et lisible :

root@yoshi:~# ls -l /mnt/
total 28
drwxr-xr-x 2 root root  4096 avril  9 05:27 Papiers
drwxrwxr-x 3 root pi    4096 avril 20 15:54 Photos
-rw-r--r-- 1 root root     0 avril 25 07:49 truecryptok

Notez qu'à chaque redémarrage du Raspberry Pi, il faudra vous y connecter et remonter le volume truecrypt.

Synchronisation des données

Script de synchronisation

J'ai décider d'utiliser rsync pour synchroniser les données présentes sur le deuxième disque dur de mon serveur avec le Raspberry Pi distant. Voici le script que je vais utiliser :

#/bin/bash

AUTH="root@raspi.distant.fr"
FICHIER_LOG="./logs/backup_raspi.log"
/bin/rm $FICHIER_LOG
/usr/bin/touch $FICHIER_LOG


FileExists=`ssh -p 2345 ${AUTH} "test -e /mnt/truecryptok && echo 1 || echo 0"`

if [ ${FileExists} = 0 ]
then
        #echo "non"
echo "Le volume truecrypt n'est pas monté sur raspi" | /usr/bin/mail -s "Problème sauvegarde raspi" mon@mail.fr
else
        #Le répertoire est monté
        #/usr/bin/rsync -rlpgotD -e ssh --compress --stats --verbose --delete --force /backup/* ${AUTH}:/mnt/ >> $FICHIER_LOG
        /usr/bin/rsync -rlpgotD --rsh='ssh -p2345' --compress --stats --verbose --delete --force /backup/* ${AUTH}:/mnt/ >> $FICHIER_LOG
fi

Voici les explications des points spéciaux :

Mon script doit avant tout tester si le volume truecrypt est bien monté sur le Raspberry Pi. Pour faire cela, dans le disque dur externe (chiffré) du Raspberry, j'ai créé le fichier truecryptok. Ce fichier n'apparaît donc que lorsque le volume est monté (déchiffré). La commande passée dans la variable FileExist va contrôler à distance que ce fichier est bien présent. Si la commande renvoi 0 c'est qu'il n'est pas présent (ou que la connexion SSH ne marche pas), je m'envoie donc un mail pour m'avertir de monter le volume et de relancer la sauvegarde. Sinon, c'est que le volume est déjà monté et je lance ma commande de synchro rsync. Notez que j'ai ouvert mon serveur SSH sur le port 2345, mes commandes incluent ce port différent.

Désormais, en lançant mon script depuis mon serveur perso, il me demande le mot de passe de mon Raspberry Pi et la synchronisation se passe correctement.

Connexion automatique

Une dernière chose à régler pour automatiser le tout c'est d'empêcher la demande de mot de passe SSH quand on lance une synchro. Pour ce faire, on va établir une authentification SSH avec clés publique/privée entre mon serveur et mon Raspberry Pi. J'avais expliqué ce mécanisme dans cet article il y a un peu plus de 5 ans (déjà !).

Pour résumé, sur mon serveur perso, j'ai tapé la commande ssh-keygen -t rsa (puis entrée à chaque fois), ce qui m'a généré une clé publique et une clé privée dans mon répertoire .ssh. J'ai ensuite utilisé la commande ssh-copy-id "-p 2345 root@raspi.distant.fr" pour envoyer la clé publique ainsi générée sur mon Raspberry Pi.

Ceci étant fait, comme je n'avais mis aucune passphrase lors de la génération de mes clés, je peux désormais me connecter (avec le compte qui m'a servi à générer les clés) en tant que root sur le Raspberry Pi sans aucune demande de mot de passe.

De cette manière, j'ai pu automatiser la synchro en faisant exécuter mon script via un cron toutes les nuits (à 23h15) :

15 23 * * * /rep/de/script/backup_raspi.sh >/dev/null 2>&1

Conclusion

La mise en place est terminée. Le disque de backup de mon serveur est désormais synchronisé toutes les nuits sur un disque dur externe distant et chiffré.

Si vous avez des remarques, si vous avez des conseils pour améliorer mon système et/ou mes scripts, n'hésitez pas, je suis tout ouïe :)

Le spam des commentaires est malheureusement une chose inévitable lorsque le blog commence à être bien référencé.

• Les filtres de l'extension « Antispam » de dotclear sont assez efficaces, pour le peu qu'on enregistre suffisamment de mots clés dans le filtre : Bad Words, Liste de termes interdits.
  

C'est simple, il suffit d'entrer les termes anglais les plus usités, genre : That (80% de positif !) , quartz, hello, you, etc
Le seul inconvénient étant de chopper aussi les commentaires pertinents dont l'auteur aura voulu utiliser un anglicisme.

• Au départ les spam étaient peu nombreux, pas un problème donc.
  

Puis de temps en temps un « chinois »^[1] passait par ici et écrivait 500 fois le même commentaire toutes les 30 secondes, depuis la même IP.
Facile à bloquer avec une règle IP table du type :

iptables -I INPUT -s xxx.xxx.xxx.xxx -j DROP

Jusque là, ça reste gentillet, les filtres font leurs taf, on trie les faux-positifs, ça se gère tranquillement sans perte de temps (quelques vingtaines par semaines).
Puis ça se corse !

• Ces mêmes « chinois » reviennent mieux armés, dans le sens où cette fois, après un ban iptables, ils reviennent avec une IP différentes, mais faisant partie de la même plage.
  

Un simple commande whois sur cette IP donne la plage dédiée au spammeur, et hop, un iptables manuel sur la plage… Oui c'est pas bien, mais ça défoule ^^; D'autant plus que d'autres viennent avec des plages différentes, et avec les contenu de spam et les fausse adresses mail utilisées on se doute que ce sont les mêmes gus.

iptables -I INPUT -p tcp --dport 80 -m iprange --src-range xxx.xxx.xxx.xxx-xxx.xxx.xxx.xxx -j DROP

Au bout de quelques ban manuel on finit par avoir la paix… Sauf que !
On se rend alors compte que ces salopiots ont cochés la case mise à disposition par le plugin dotclear bien pratique pour le visiteur humain, subscribeToComments 1.4-alpha1 servant à s'abonner au commentaire pour être prévenu par e-mail d'une réponse à ce commentaire.
Et là, c'est une autre affaire, car on se retrouve avec des tonnes d'abonnements bidons dans la page de gestion du plugin, et presqu'autant de mailer-daemon témoignant de l'échec d'envoi des e-mails de notifications… vu que les spammeurs rempilent derrière leurs propres spam, alors même qu'il se sont vu filtrés par le filtre Antispam et que donc leurs spam ne sont pas publiés.

• Depuis quelques temps ces « chinois » me laissent tranquille, mais une nouvelle sorte de spammeur à débarqué… Les Zombies !
  

Vu la nature de ces spams, j'imagine qu'il s'agit de PC Windaube infectés de virus spammeur qui partagent une base de données avec mon IP publique dedans !
En effet, contrairement aux «chinois », ces spams débarquent du monde entier, avec des contenus plus ou moins du même genre, et des adresses e-mail dans un style différent et plus élaborées. Impossible ici de s'amuser à bannir les IP à la main avec dans les 60 spams par jours, ni à chopper les plages IP, car cette fois on est susceptible de réellement bloquer des visiteurs légitimes !
Ho, les filtres Antispam de dotclear font toujours bien le travail, mais il devient pénible de trier à la main les faux-positif et de nettoyer les abonnement aux commentaires… De fait et a regret, j'ai donc dû prendre la décision de désactiver subscribeToComments rendant le suivit des commentaires inexistant pour les visiteurs.
Voyous de publicitaires $#ø%@'&€…

Il est donc temps d'étudier une solution automatique pour bannir ces IP malignes.

Ça m'entrainera à écrire du script… L'idée ici est donc la suivante,

Toutes les 12 heures :

- Pour les 12 dernières heures écoulées, faire une requête sur la base de donnée de dotclear pour lister toutes les adresses IP des commentaires marqués indésirable par l'Antispam.
- Virer les doublons (car oui, ils reviennent, soit dans les minutes, soit les jours suivants)
- Bannir toutes les IP de cette liste avec iptables.
- Écrire un fichier de log horodaté.
- Envoyer le fichier de log par e-mail.

#!/bin/bash
 
###################################################
# BANNIR LES SPAMMEURS des commentaires DOTCLEAR #
# À programmer dans crontab toutes les 12h ################
###################################################
# ——————————— #
# Initilisation des variables #
# ——————————— #
 
login=utilisateur				# Le nom d'utilisateur ayant les droits sur la base de donnée.
password=motdepasse		# Le mot de passe associé.
base=blog					# Le nom de la base de donnée.
table=dc_comment			# La table des commentaires.
champ1=comment_spam_filter	# Le champ des commentaires marqués comme filtrés.
champ2=comment_ip			# Le champ de l'IP.
champ3=comment_dt			# Le champ de la date et heure.
condition=dcFilter% 			# Le filtre pour ne conserver que les lignes dont le champ1 commence par : dcFilter.
depuis=$(date -d "12 hour ago" "+%F %T") # La date moins 12 heures.
requete1="SELECT $champ1,$champ2,$champ3 FROM $base.$table WHERE $champ1 LIKE 'dcFilter%' AND $champ3 BETWEEN '$depuis' AND now()"
 
# ———— #
# Fonctions #
# ———— #
 
bannir () {					# Bannir l'adresse IP contenue dans la variable: ip2.
iptables -I INPUT -s $ip2 -j DROP
}
 
# ————————————————————— #
# Requête MYSQL pour réccupérer les IP à bannir #
# ————————————————————— #
 
# mysql -uutilisateur -pmotdepasse -e "SELECT comment_spam_filter,comment_ip,comment_dt FROM blog.dc_comment WHERE comment_spam_filter LIKE 'dcFilter%' AND comment_dt BETWEEN '2013-02-08 20:01:30' AND now()";
 
mysql -u$login -p$password -e "$requete1" | while read spamfilter ip date		# Lire la requête mysql ligne par ligne et récupérer les valeurs de chaque champs pour les affecter respectivement aux variables: spamfilter ip date.
						do
							if [ "$ip" = "comment_ip" ]; then		# Si la variable: ip, contient le mot: comment_ip, Alors.
								echo "comment_ip" > /dev/null	# L'envoyer au trou noir !
							else								# Sinon,
								echo  "$ip"					# Appeler successivement la valeur de la variable: ip.
							fi
						done | sort -u > /tmp/dc_spam.tmp		# Stocker les ip dans le fichier tmp en supprimant les doublons.
# —————————— #
# Bannir les IP récoltées #
# —————————— #
 
date '+%Y-%m-%d %X' >> /var/log/dc_BannedIP.log			# Écrit la date dans le fichier log: dc_BannedIP.log.
echo -e "\n" >> /var/log/dc_BannedIP.log						# Saute une ligne dans le fichier log: dc_BannedIP.log.
 
if [ -s /tmp/dc_spam.tmp ]; then								# Si le fichier tmp n'est pas vide.
	while read ip2										# Lire le fichier: tmp, ligne par ligne.
	do
		echo "$ip2"                  								# Appeler successivement la valeur de la variable: ip2.
		bannir   	 	                     							# Appeler la fonction: bannir.
	done < /tmp/dc_spam.tmp >> /var/log/dc_BannedIP.log		# Ajouter la liste des IP que l'on vient de bannir dans le fichier log: dc_BannedIP.log
	echo -e "———————————————————" >> /var/log/dc_BannedIP.log	# Écrit une ligne horizontale dans le fichier log: dc_BannedIP.log.
else
	echo "aucune IP à bannir" >> /var/log/dc_BannedIP.log		# Sinon, ne rien faire.
	echo -e "———————————————————" >> /var/log/dc_BannedIP.log	# Écrit une ligne horizontale dans le fichier log: dc_BannedIP.log.
fi
 
# ————————————— #
# Envoie d'un email avec le log #
# ————————————— #
 
mutt -s "IP Bannies pour Dotclear" admin@mondomaine.org -a /var/log/dc_BannedIP.log < /root/scripts/emailmessage.txt

Le Raspberry Pi est de loin une des récentes idées geek les plus sympa : un micro-pc ARM pour moins de 50€, ça fait rêver. En tous cas, moi ça faisait un bout de temps que le boitier me faisait de l’oeil, et maintenant, ça y est, Geek de France en a un pour notre plus grand plaisir!

Raspberry Pi : qu’est ce que c’est?

Pour ceux qui se demande encore ce qu’est un Raspberry Pi, il s’agit d’un micro ordinateur dont le projet initial était de proposer un carte mère ARM 700Mhz et de 128Mo de RAM pour seulement 25€ (je vous en parlais ici à l’époque). A présent Raspberri Pi a bien évolué et sa révision B embarque 512Mo de RAM pour une quarantaine d’euros.

Voici les caractéristiques de cette révision B :

• Processeur ARM 700MHz (Broadcom BCM2835 ARM1176JZFS)
• GPU Broadcom Videocore (quad-core)
• 512MB de SDRAM
• OpenGL ES 2.0 et décodage du 1080p30 H.264
• Sortie composite et HDMI
• 2ports USB 2.0
• Lecteur SD/MMC/SDIO

Pour ce tarif, la carte mère est vendue nue mais elle peut-être assortie d’un petit boîtier pour une dizaine d’euros et d’un chargeur OTA pour une autre dizaine d’euros. Le stockage se faisant sur une carte SD, en rajoutant une carte SDHC 4Go pour 5euros, on a un micro serveur pour moins de 80€.

Pour ma part, j’ai pu avoir l’ensemble grâce à Idealo via Amazon que je remercie chaleureusement!

Jouons avec notre Raspberry Pi

J’ai déjà commencé à jouer avec le bébé et prépare une série d’articles lesquels aborderont déjà les possibilités de ce PC et de sa distribution de base (Raspbian basée sur Debian). Puis, seront abordés les différents tuto suivant :

• utilisation du Raspberry Pi comme serveur Web
• installation de Leed sur un Raspberry Pi
• utilisation du Raspberry Pi comme Media Center XBMC
• utilisation du Raspberry Pi comme serveur de téléphonie Elastix

Au final, l’idée sera de répondre à la question : est-ce que le Raspberry Pi est un home-serveur viable ou n’est-il qu’un jouet pour geek?

Et sinon, en attendant, vous pouvez creuser un poil les possibilités et usage du RaspBerry Pi via ces quelques sites :

• http://www.raspberrypi.org/quick-start-guide
• http://www.tropfacile.net/doku.php/raspberry-pi
• http://pihomeserver.wordpress.com/category/raspberry-pi-home-server/
• http://blog.nicolargo.com/category/raspberry

Depuis quelques temps, je cherchais une application de galerie photo toute simple en PHP, sans base de données. Après avoir fait le tour des application KISS de la page de sebsauvage, je n'ai pas trouvé mon bonheur. Grâce aux joies de l'hypertexte, je suis tombé sur un petit projet, probablement abandonné (bien que créé récemment), mais qui me plaît fortement : PhotoLight. Je l'ai mis en place sur mon serveur et cela me convient parfaitement. Voici une petite présentation.

Introduction

Mon besoin était simple : comme je l'avais déjà expliqué, mon serveur perso est composé de deux disques durs. Le deuxième disque est dédié à mes sauvegardes. Il contient une partie des données présentes sur mon premier disque ainsi que d'autres données d'autres ordinateurs que je souhaite sauvegarder (mes photos, entre autres).

Je voulais donc une toute petite application web qui me permettrait de simplement visualiser les photos présentes sur mon disque de sauvegarde. L'accès serait limité au niveau apache via un filtre htaccess. Je ne voulais pas que cette appli utilise de base de données (j'en ai déjà assez comme ça).

J'ai trouvé mon bonheur sur le repository GIT de Thibaud Rohmer, le créateur d'une galerie photo un peu plus connue (PhotoShow), il s'agit de PhotoLight. Thibaud a justement créé PhotoLight comme une alternative très légère à PhotoShow.

Installation

L'installation est très simple, vous devez, dans un premier temps, récupérer le code source de l'application grâce à la commande git (que vous devez installer via la commande apt-get install git-core depuis une Ubuntu ou une Debian) :

git clone git://github.com/thibaud-rohmer/PhotoLight.git

Une fois le dossier récupéré modifiez le fichier de configuration resources/config.php :

$config = array(
        "path" => "/backup/Photos/",
        "thumbs_path" => "./thumbs/"
);

Dans mon cas, mon dossier contenant mes photos est présent dans /backup/Photos/ et je souhaite que les vignettes générées soient stockées directement dans le dossier de l'application (dans un dossier thumbs). Assurez-vous que le path soit accessible en lecture par apache et le thumbs_path soit accessible en lecture et écriture.

Voila, c'est tout. Vous n'avez plus qu'à vous rendre sur l'adresse de l'application pour voir vos photos.

Illustration

Voici la première page de l'application, qui est mon répertoire de photos (qui contient juste d'autres répertoires de photos) :

Ensuite, voici l'intérieur d'un répertoire avec les photos qui s'affichent :

Modifications

Par défaut, quand on clique sur une photo, une fonction javascript fait que la photo s'affiche par dessus la page. Chez moi (qui ait un écran de portable 14 pouces), la photo est tronquée en bas :

Du coup, j'ai commenté cette fonction dans le fichier public_html/js/main.js :

$(".thumb").click(function(){
                t=encodeURI($(this).children('a').attr('href'));
                $("#imgviewer").html('<img src="http://www.generation-linux.fr/index.php?post/2013/04/24/'+t+'">');
                $("#viewer").fadeIn();                 
                return false;
});

Ce cette manière, quand on clique sur une photo, ça affiche désormais la photo seule, en pleine page dans le navigateur, c'est bien plus pratique.

Voila, une belle trouvaille cette application, j'en suis bien content et vais la garder pour visualiser les sauvegardes de mes photos.

Suite au constat des différents problèmes posés par le modèle cloud (silo de données, effet lock-in, multiples inscriptions..), il y a deux ans et demi, Frank Rousseau s’est mis à l’auto-hébergement ! Cette pratique lui a tellement plu qu’il a démarré un premier projet à auto-héberger (Newebe, un réseau social distribué) qui de fil en aiguille l’a amené à faire de nouvelles rencontres et à monter un autre projet beaucoup plus conséquent nommé Cozy Cloud dont voici une rapide description :

• d’un point de vue utilisateur : une plateforme permettant facilement de gérer ses web apps personnelles comme sur un smartphone.
• d’un point de vue technique : une solution libre permettant de gérer facilement des applications Node.js fournies par Cozy Cloud ou développées par n’importe qui d’autre.
• d’un point de vue équipe : 7 personnes motivées qui veulent changer le web
• d’un point de vue juridique : une société qui a pour vocation de fournir des prestations d’hébergement

Donc en somme c’est un cloud personnel que l’on peut bidouiller, héberger ou tout simplement supprimer ! Mais c’est aussi un peu plus : une équipe qui croit vraiment que l’auto-hébergement, en plus de résoudre les problèmes de confidentialité, pourrait développer de nouveaux usages et rendre obsolète le cloud tel qu’il existe. L’équipe de Cozy Cloud a d’ailleurs développé pas mal de réflexions à ce sujet que vous pouvez retrouver sur leur blog et leur FAQ.

P.S. :

• comment installer Cosy Cloud : https://github.com/mycozycloud/cozy-setup#how-to-install-cozy-on-your-server-
• la faq : https://www.cozycloud.cc/faq/
• la démo : https://demo.cozycloud.cc/
• le code : https://github.com/mycozycloud/

Cet article Cozy Cloud : l’autre cloud personnel auto-hébergé est apparu en premier sur mumbly58.fr.

Même si le Raspberry Pi est un petit ordinateur fabuleux avec de grandes capacités hardware il n'en reste pas moins un ordinateur embarqué. Or en voyant la page de téléchargements officielle de systèmes d'exploitation force est de constater que ce qui est proposé n'est pas très "embarqué". L'image préconisée, celle de Debian Wheezy, pèse 2 Go et intègre des centaines de paquets inutiles parmi lesquels un serveur X et un environnement de bureau. Plutôt que de désinstaller ce dont on a pas besoin, pourquoi ne pas compiler soi-même un linux à son goût ?

Un système minimaliste avec Busybox

Il ne va pas s'agir de construire une distribution généraliste comme Ubuntu mais plutôt un système n'intégrant que les applications dont on a besoin. En trois mots : le strict minimum. On peut imaginer un Raspberry Pi qui autohéberge un serveur de mail ou un client torrent et qui ne fait que ça, mais qui le fait bien.

On va réduire au maximum le nombre de programmes présents en utilisant un utilitaire bien connu du monde de l'embarqué : busybox. Busybox est un programme qui suivant la manière dont il est exécuté va prendre la tâche d'autres programmes, souvent des utilitaires GNU. Ainsi busybox peut être compilé pour intégrer les programmes ls, mkdir et même vi. Des liens symboliques pour tous ces programmes seront créés dans le répertoires /bin et pointeront vers le binaire de busybox. Ainsi chaque appel à un utilitaire courant exécutera en réalité busybox. Le gain d'espace disque est d'autant plus important que les versions des utilitaires sont épurées et n'intègrent que les options de base.

Une compilation facilitée par Buildroot

Ceux d'entre vous qui compilent eux-mêmes des programmes de temps en temps savent à quel point cette tâche peut être délicate, ne parlons même pas du kernel dans lequel l'oubli d'un simple module peut empêcher l'ordinateur de démarrer. Alors comment faire pour compiler un kernel, busybox, des applications et un système de fichiers sans y passer des jours ? La réponse tient dans autre utilitaire phare de l'embarqué : buildroot.

Buildroot est un programme qui se charge de la création du système de A à Z. Il suffit de lui indiquer ce que l'on veut obtenir et il va se charger lui-même de télécharger la version du kernel linux demandée, de télécharger les sources des programmes à installer, de compiler tout ça et d'en faire un filesystem.

Utiliser ces outils avec le Raspberry Pi

Si buildroot s'occupe de tout, du kernel jusqu'au filesystem, vous vous imaginez bien que sa configuration doit être très complète. En effet il y a plusieurs dizaines de milliers de paramètres qui ont chacun une influence importante sur le résultat final. Cela en fait un outil très versatile, mais aussi compliqué à maitriser. Rassurez-vous, un certain Guillermo Amaral propose sur Github un fork de buildroot adapté au Rasperry Pi. Le projet est en constante évolution et est mergé régulièrement avec les évolutions de buildroot. Pour vous donner une idée, à l'heure actuelle vous pouvez compiler le kernel 3.8.8.

Les explications données sur la page du projet sont suffisantes pour comprendre le fonctionnement des utilitaires et fabriquer entièrement son système basé sur Linux et busybox. Un conseil cependant, ne négligez pas la machine qui va effectuer la compilation, vous aurez besoin d'1 Go de RAM minimum et sur un i5 la compilation prend une heure environ.

Si vous ne souhaitez pas vous lancer dans la compilation tout de suite l'auteur de dépôt Git propose une image prête à installer sur votre carte SD pour tester le système.

Personnalisation de votre système

Pour adapter votre système à vos besoin vous pouvez ajouter des programmes depuis l'interface de buildroot, via l'utilitaire bien connu : make menuconfig.

En entrant cette commande vous avez accès à l'interface de configuration de buildroot qui permet de modifier le système. Si le programme que vous souhaitez installer est disponible dans cette liste, c'est aussi simple que l'installation via un gestionnaire de paquet. L'image ci-dessus montre à quel point c'est facile de créer son petit serveur web sur un Rapberry Pi. Avec une telle simplicité, pourquoi donc s'évertuer à utiliser Apache ? D'autant plus que votre système sera beaucoup plus réactif que la version Debian Wheezy avec ses milliers de paquets inutiles et plus facile à maintenir. C'est une solution idéale pour l'autohébergement.

La configuration peut même aller beaucoup plus loin. Via la commande make linux-menuconfig vous avez accès à l'interface standard de configuration du kernel linux.

J'en avais parlé dans mon précédent article, j'ai un projet que je suis en train de concrétiser : externaliser les sauvegardes de mon serveur personnel. Pour cela, j'ai choisi d'utiliser un disque dur externe que je vais brancher sur un Raspberry Pi chez mes beaux-parents. Je ferai un(des) article(s) pour expliquer tout ce mécanisme. Pour l'instant (en attendant de recevoir ma commande de Raspberry Pi), j'ai commencé par chiffrer mon disque dur externe (que je brancherai ensuite sur le Raspberry Pi). Voici comment j'ai fait :

Introduction

Comme je l'avais dit dans mon article précédent, je suis un vrai débutant en matière de chiffrement de données. C'est un domaine dans lequel je souhaitais progresser depuis assez longtemps. C'est désormais chose faite. Bon, je suis loin de tout savoir mais j'ai quand même appris quelques techniques que je souhaitais partager avec vous. Si vous êtes complètement débutant dans le domaine, cet article est fait pour vous.

Un volume / un conteneur

Truecrypt est le logiciel qui va nous permettre de chiffrer nos données. Il permet de chiffrer des données de deux manières différentes :

• soit créer un conteneur, c'est à dire une sorte de répertoire chiffré. Ce répertoire a une taille fixe et est représenté sous la forme d'un seul fichier. Si je décide d'avoir un volume de 5Go, Truecrypt va créer un gros fichier de 5Go dans lequel seront stockées nos données chiffrées ;
• soit chiffrer l'intégralité d'un disque dur ou d'une clé USB. C'est ce que je vais mettre en place ici.

Cet article liste les avantages et les inconvénients de chaque méthode.

GUI / CLI

Il y a deux façons d'utiliser Truecrypt : en ligne de commandes ou via une interface graphique. Sachez que vous pouvez chiffrer votre disque dur sur une machine et l'utiliser sur une autre. L'essentiel étant de posséder le logiciel Truecrypt (qui est multi-plateforme) sur chaque machine où vous voulez chiffrer/déchiffrer vos données. Pour cette raison, j'ai "initialisé" (chiffré) mon disque dur sur mon poste de travail (sous Ubuntu), en utilisant l'interface graphique (c'est cette méthode que je vais illustrer ici). J'utiliserai la ligne de commande sur mon Raspberry Pi afin de monter mon disque dur et y copier mes données (ce qui fera l'objet d'un autre article).

Installation de Truecrypt

Pour installer Truecrypt sur une machine GNU/Linux, vous devez télécharger l'archive sur la page de téléchargement du site officiel. J'ai choisi le package Standard pour mon poste de travail (pour bénéficier du GUI). Une fois téléchargé, vous devez extraire puis exécuter l'installeur grâce à ces commandes :

tar zxf truecrypt-7.1a-linux-x86.tar.gz
./truecrypt-7.1a-setup-x86

Dans la fenêtre qui apparaît, cliquez sur Install Truecrypt et acceptez les conditions d'utilisation. Une fenêtre vous indiquera ensuite comment désinstaller Truecrypt si besoin. Validez, entrez votre mot de passe de session et c'est terminé.

Chiffrer le disque dur

Nous allons désormais chiffrer notre disque dur. Pour cela, commencez par brancher, sur votre ordinateur, le périphérique que vous souhaitez chiffrer. Lancez ensuite Truecrypt. Vous arrivez sur cette fenêtre :

Cliquez sur Create Volume puis choisissez Create a volume within a partition/drive (c'est ici que vous pourriez choisir de créer un conteneur plutôt que de chiffrer un disque entier) :

Vous devez ensuite choisir entre un chiffrage standard ou un chiffrage caché. Le chiffrage caché permet, au cas où vous soyez obligé de donner votre mot de passe, de n'afficher qu'une partie du contenu, l'agresseur ne pouvant pas savoir qu'il y a encore une autre partie. Moi je choisi le chiffrage standard, je vous conseille de faire de même, sauf cas exceptionnel :) :

La fenêtre suivante va vous servir à choisir le disque à chiffrer. Vous pouvez le sélectionner en cliquant sur Select Device. Si votre périphérique comporte une (ou des) partition(s), vous devez choisir une partition à chiffrer. Si le périphérique ne comporte aucune partition, vous pouvez choisir le périphérique entier. Dans mon cas, j'ai une partition sur mon disque dur (/dev/sdb1), je choisi donc de chiffrer celle-ci :

Cliquez ensuite sur Next et entrez votre mot de passe de session. Après un avertissement concernant la perte des données existantes sur votre disque, vous allez pouvoir choisir la méthode de chiffrement de votre périphérique. J'ai vu ici et là que le plus utilisé était le AES avec le hash SHA. C'est ce que je vais choisir :

Vient ensuite le moment de choisir le mot de passe de votre volume. Ce mot de passe sera nécessaire pour l'ouvrir et y copier vos données. Truecrypt recommande de choisir un mot de passe avec au moins 20 caractères. Il y a également la possibilité d'ajouter un keyfile. Il s'agit d'un fichier (peut importe lequel, un txt, mp3, etc.) qui servira de clé supplémentaire à votre volume. Cela signifie que si vous perdez ce fichier (et/ou votre mot de passe), vous ne pourrez plus ouvrir votre volume. Vous pouvez choisir d'utiliser un mot de passe et/ou un keyfile. Dans mon cas, je n'utiliserai qu'un mot de passe :

Ensuite, il reste à choisir le système de fichiers de votre volume (vous avez le choix entre FAT et ext[2|3|4]). Par sécurité, ne sélectionnez pas Quickformat (sinon l'intégralité de votre volume ne sera pas chiffré) :

Choisissez si vous souhaitez monter ce volume uniquement sur un système Linux ou bien également sur d'autres plateformes :

La clé de cryptage est ensuite générée, vous pouvez "aider le processus" en déplaçant votre curseur sur la fenêtre. Plus longtemps vous le faites, mieux c'est. Au bout d'un certain temps quand en avez marre, cliquez sur Format :

Votre volume est en train d'être formaté/chiffré. Vous pouvez suivre l'évolution de l'opération grâce à la barre de progression :

Une fois la barre remplie, c'est fait, votre volume est chiffré :

Conclusion

Cet article s'arrête là, un prochain sera consacré au montage de ce disque dur (en ligne de commandes) sur mon serveur. Ceci dit, pour ne pas vous laisser comme ça, je vous explique rapidement comment se servir de ce disque sur votre poste de travail (avec l'interface graphique).

Désormais, quand vous branchez votre disque chiffré, il n'est plus monté automatiquement par votre OS. Vous devez lancer Truecrypt puis choisir un point de montage dans la liste (64 slots sont disponibles). Cliquez ensuite sur Select Device et choisissez votre disque. Cliquez sur Mount puis renseignez votre mot de passe et/ou votre keyfile (puis votre mot de passe de session). Le volume sera monté dans le répertoire /media/truecryptN (N étant le numéro du slot choisi au dessus).

J'espère que cet article vous a plu. Comme d'habitude, si vous avez des questions ou des remarques, n'hésitez pas :)

Je ne sais pas pour vous, mais dans l’auto-hébergement il y a deux choses qui me manquent : une connexion fibrée avec d’excellents débits et un endroit clos et pas trop chaud pour stocker mes petits serveurs, car aujourd’hui la Sheevaboite et mon NAS trônent sur le meuble TV à côté de la dite TV. Et malheureusement, à la vue de tout le monde il peut se produire des choses qui ne se serai jamais produit si j’avais une pièce pour y stocker mes machines…

Circonstances du drame

Il n’y pas souvent de jeunes enfants en âge de marcher et de toucher à tout chez moi, mais récemment un petit monstre (je l’aime bien quand même) était déchainé et il trouvait cela amusant d’appuyer sur tous les boutons qu’il trouvait dans mon appart : lumières, télévision, volets.

C’était un peu saoulant de lui dire d’arrêter tout le temps pour ses parents, mais cela ne me posait pas de problèmes jusqu’au moment ou il s’est amusé à appuyer frénétiquement sur le seul bouton visible de la Sheevaboite pendant 2-3 secondes. Le petit père avait réussi son coup, il a éteint la Sheevaboite d’une manière non-académique.

Plus de peurs que de mal, la machine a redémarré sans aucun soucis…

Protégez-vous !

Du coup, après que les invités soient partis (très bonne soirée mis à part l’incident), j’ai décidé de supprimer le bouton de la façade et d’ajouter un interrupteur (retrouvé dans mes affaires d’électronicien) que j’ai placé à l’intérieur du boitier. On a fait plus pratique pour éteindre et allumer une machine.

Mais maintenant je suis “children-proof” au moins pour la Sheevaboite…

Suite du cinquième épisode
En guise de conclusion sur l'assemblage du serveur, voici les dernières finitions.

• Mise en place d'un nouveau potentiomètre à grosse molette pour un réglage aisé de la vitesse du ventilateur de chassis.
  

• Les vis ont été changées par de plus esthétiques.
  

• Le câblage a été amélioré et les connecteurs superflu retirés.
  

• Et enfin, des trous d'aérations supplémentaires effectués.
  
  

Ensuite je lui ai trouvé une place discrète dans le salon…
Dans cette alvéole d'étagère, j'en ai profité pour y ramener aussi le modem et le routeur et tout le câblage nécessaire.

Lorsque j'en aurais terminé avec la configuration logicielle, et qu'il sera en ligne, Je pense que les non-abonnés de Free.fr sentiront une différence de vitesse en venant sur ce blog. (Free réservant sa bande passant pour ses abonnés, l'accès aux page perso Free se révèle plus lent pour le reste de la planète… une pratique commerciale portant atteinte à la neutralité du Net)

À suivre…
À suivre 2…

Suite du sixième épisode
Ça y est !!!
Vous lisez un blog 100% libre (1 de +) !!! en direct de mon salon

Après quelques temps de tests et de mise en place, j'ai donc migré le blog depuis free.fr (le site «atelier» y passera plus tard), sur ma «No-Box»^[1] installée dans mon salon donc, contenant uniquement des logiciels libres permettant mon autonomie et ma liberté en tant que webmaster d'une machine acentrée. ^[2]

Bienvenue sur internet, le webmaster espère que vous passerez un agréable surf sur ses pages.

En attendant que je formalise et partage ici mes notes de configurations, petite synthèse de la chose, pour se rendre compte de ce qu'un tel projet implique.

Bilan Prix tout d'abord :

• Carte mère Mini-iTX GA-GC330UD
  

= 72€, le prix a un peu baissé depuis… (63€ constaté aujourd'hui)

• Barrette de mémoire DDR2 533 MHz de 512Mo
  

= 0€, trouvée par terre… sisi c'est pas une blague ^^;

• Disque dur sata 2'5 pouces de 320Go
  

= 30€, d'occasion

• Alimente via un PicoPSU 120Watts
  

= 15€, d'occasion

• Bloc secteur de 12V-5A
  

= 0€, récupération sur un autre appareil

• Petite plaque de plexis 2,5mm
  

= 3€

• Divers matériaux pour la conception du reste du boitier
  

= 0€, récupération sur d'autres vieux ordi et divers appareils (ventilateur, connecteurs, câbles, vis, boiter de K7 vidéo…)

Total = 120€

Bilan de consommation électrique :

Mesurée sur le 12Volt (Attention ! ne tient donc pas compte de la consommation/rendement de l'alimentation du 220/12V du bloc secteur)
Ordinateur démarré, sans activités notables :

• 24 Watts avec le Ventilateur de chassis au mini (1)
• 24,24 Watts avec le Ventilateur de chassis au moy (6)
• 24,72 Watts avec le Ventilateur de chassis au max (11)

Bilan humain :

Plusieurs aspect dans ce projet :

1. Du bricolage, avec le boîtier d'ordinateur 'achement design et sexy «from sratch».
2. De nouvelles découvertes et compétences informatiques pour faire fonctionner des service internet.
3. Du temps… et de la ténacité, comme d'habitude, récompensé par l'auto-satisfaction.
4. DU temps à long terme pour surveiller et maintenir tout ça.

Plus d'informations avec d'autres initiatives comparables à la mienne :

http://wiki.auto-hebergement.fr/
http://box.generation-linux.fr/
http://www.generation-linux.fr/index.php?post/2009/05/28/Creation-du-projet-Box-qui-veut-en-etre
http://haltux.homelinux.org/index.php?post/2009/03/26/Internet-libre-ou-Minitel

À suivre…

Précédemment…
Retour sur le :

Bilan de consommation électrique :

J'avais mesuré sur le 12Volt, c'est à dire entre la carte mère et le bloc secteur (12,05V 5A)
Ordinateur démarré, sans activités notables :

• 24,24 Watts

Depuis je me suis procuré un «Watt-mètre», petit truc qui se place entre la prise de courant et l'appareil à mesurer.
Avantage, il prend en compte le fameux cosinus phi dont il faut absolument tenir compte dans le calcul de la puissance, plutôt que d'appliquer bêtement la formule P = UI, comme je l'avais fait lors de mes premiers essais…

Résultat, sur 220V alternatif alimentant le bloc secteur (12,05V 5A) la mesure est de :

• 28 Watts en moyenne
  

26€50/ans, tel est le prix de la liberté !
(Moins cher que sur un minitel ovh)

Par contre, à ce prix la, je m'interroge sur la rentabilité économique et écologique du projet de panneau solaire…
Les panneaux étant très cher et lentement remboursés, sans compter que pour réduire les coûts, les importer de Chine ou même d'Angleterre a un impact sur l'environnement… tout comme la fabrication du panneau et la transformation de ses composants à partir des matières premières elles-mêmes importées de loin…
Bref, tout ce qu'on appelle l'«énergie grise»

Suite du quatrième épisode
Hé bien, finalement, il m'aura fallut une semaine complète de jours entiers, pour fabriquer le boîtier de cet ordi !!
Il mesure 19x19,5x6,3cm
En fait ce qui fut très long, c'est que j'ai dû concevoir chaque éléments.

J'ai donc effectué les découpes des plaques des côtés et du couvercle, et usiné à nouveau 4 coins en plastique...

Puis j'ai choisi un interrupteur, qu'il a fallut câbler et coller à l'araldite dans une découpe.

Ensuite j'ai conçu un système de fermeture pour le couvercle avec des aimants et des lames métallique récupérées sur un vieil ordi, vous savez, celles qu'il faut enlever pour pouvoir placer des cartes d'extensions.
Enfin, J'ai percé la plaque pour ajouter le connecteur 12V du picoPSU.

Voici tous les éléments avant et après assemblage final :

La plaque d'alu a été peinte en bleu, à la bombe de peinture auto, et les coins de métal ajustés en hauteur pour coller aux aimants.

Now le truc est rempli, manque juste le ventilo du chassis
Le disque dur est vissé à l'envers sous le couvercle...

En place pour les essais.

Avant d'ajouter le ventilateur de chassis et un petit potentiomètre, pour en régler la vitesse.
Le petit machin bleu là...

À suivre…

LG Tetaneutral

Dans les articles précédents, nous avons vu comment s’approprier petit à petit (presque) tous les maillons de la chaîne entre tatie Martine et Internet.

Je suis, volontairement, passé un peu vite sur la question de la bordure entre le réseau et Internet. Reprenons donc, vous êtes l’opérateur A et vous disposez de deux machines situées à proximité immédiate d’autres réseaux (par « proximité immédiate » j’entend « dans le même bâtiment », mais vous pouvez aussi tirer des fibres longue distance si vous avez une bonne pelle) et vous avez fait le choix de la redondance et de la qualité en souscrivant :

1. un contrat de transit avec un opérateur B
2. un contrat de transit avec un opérateur C
3. un port sur un point d’échange 1
4. un port sur un point d’échange 2

Si on résume donc, chacun de vos deux routeurs dispose de 4 connexions :

• un lien vers l’un des transitaires
• un lien vers l’un des points d’échange
• un lien vers la collecte ADSL
• un lien vers l’autre routeur

C’est bien joli, mais il faut à présent configurer  tout ça. Sur internet, tout est affaire de routes. J’en ai déjà parlé pas mal ici, ici et ici mais essayons de reprendre sous un angle encore différent, un angle un peu opérationnel.

Lorsqu’on est totalement étranger à cette couche d’internet qu’est le BGP, on connait principalement la route par défaut (celle que toute machine se doit de connaître pour parler à internet). Au niveau des interconnexions entre réseau, on peut aussi l’utiliser. Cela revient donc à dire à nos deux routeurs « si vous ne savez pas où envoyer les paquets qui vous arrivent, balancez chez le transitaire, lui, il trouvera ».

C’est pas très « state of the art », mais ça a l’avantage de marcher et de pouvoir faire tourner votre bordure de réseau avec du vieux matériel (genre cisco 3550 a 150 € pièce). On aura donc :

• le lien vers nos utilisateurs ADSL qui supportera les tunnels L2TP et qui créera une (ou plusieurs) interface(s) virtuelle(s) par utilisateur ADSL sur le routeur
• le lien vers le transitaire sur lequel il y aura une route par défaut
• le lien vers l’autre routeur sur lequel il y aura la route par défaut du transitaire de l’autre routeur (dès fois que le nôtre soit cassé)
• et le lien vers le point de peering

C’est quoi donc un point de peering ? Je la joue rapide, il y a déjà une abondante littérature ici et ailleurs sur le sujet : c’est juste un switch sur lequel se connectent plusieurs opérateurs. Etant tous branchés sur le même switch, ils peuvent s’échanger des paquets entre eux. Les us et coutumes ancestrales imposent généralement qu’on ne se serve pas d’un point d’échange pour se vendre du transit, la résultante étant donc que le trafic qui y passe est généralement local : un paquet qui va de chez moi à chez numéricable passe par un point d’échange, mais s’il s’agit d’aller chez un opérateur australien, sauf si cet opérateur est présent sur le point d’échange, ça passera par le transit.

On a donc, si on se concentre sur la bordure :

• le lien vers le transit qui supporte UNE connexion BGP avec UN opérateur sur lequel il y a UNE route par défaut
• le lien vers le point d’échange qui supporte X connexions BGP vers X opérateurs sur lesquelles il y a Y(x) routes

Vous trouverez par exemple, sur le point d’échange FranceIX, le réseau de Google qui annonce 327 routes mais aussi celui de Tetaneutral qui n’en annonce qu’une. Un petit réseau noue généralement quelque chose comme une centaine de sessions de peering, un moyen entre 200 et 500 et un gros en a plusieurs milliers.

Intéressons-nous à présent au transit. Nous avons pour l’instant une route par défaut, ce qui signifie que tout le trafic qui n’est pas à destination de nos clients ADSL ou d’un réseau avec lequel nous disposons d’un peering passe par le transit local au routeur. Il en va de même pour le routeur d’à côté. Si notre trafic ADSL est concentré sur un seul des  deux LNS, ça veut donc dire que tout le trafic sortira par un transitaire et rien par l’autre, ce qui est loin d’être optimal, surtout si ces transitaires ont des zones d’achalandage différentes.

Pour pouvoir avoir une meilleure granularité dans la destination du trafic, il va falloir oublier la route par défaut et se manger les 438828 routes d’internet (vous avez vu, ça a encore augmenté depuis mon article d’il y a une semaine (435905). Si le gonflement d’internet vous passionne, vous trouverez plein de chiffres et de jolis graphs ici.

Si les routeurs qu’on utilise sont capables de manger cette quantité de routes, on dispose alors de deux vues fidèles de l’ensemble d’internet, dans le détail. Je vais prendre un exemple concret sur un réseau que j’ai sous la main, AS29608, avec une route appartenant à Twitter (AS13414). En utilisant un outil relativement connu, traceroute, on obtient le trajet que vont faire les paquets entre AS29608 et AS13414 :

traceroute to twitter.com (199.59.150.7), 64 hops max, 40 byte packets
1 fe-0-1.core1.th2.absolight.net (79.143.241.157) 0.618 ms 1.788 ms 2.075 ms
2 ge-1-1.br1.th2.absolight.net (79.143.241.25) 0.971 ms 0.424 ms 0.403 ms
3 ge-2-10.br2.th2.par.w2my.net (79.143.241.30) 0.657 ms 0.368 ms 0.393 ms
4 ge-6-24-162.car1.Paris1.Level3.net (212.73.204.197) 3.589 ms 12.254 ms 108.039 ms
5 ae-51-51.csw1.Paris1.Level3.net (4.69.139.215) 8.317 ms 8.000 ms 12.299 ms
6 ae-56-111.ebr1.Paris1.Level3.net (4.69.161.37) 7.823 ms
ae-58-113.ebr1.Paris1.Level3.net (4.69.161.45) 7.691 ms
ae-57-112.ebr1.Paris1.Level3.net (4.69.161.41) 7.795 ms
7 ae-48-48.ebr1.London1.Level3.net (4.69.143.113) 8.779 ms
ae-46-46.ebr1.London1.Level3.net (4.69.143.105) 8.515 ms
ae-45-45.ebr1.London1.Level3.net (4.69.143.101) 8.011 ms
8 ae-57-112.csw1.London1.Level3.net (4.69.153.118) 8.576 ms 8.411 ms
ae-59-114.csw1.London1.Level3.net (4.69.153.126) 7.734 ms
9 ae-1-51.edge4.London1.Level3.net (4.69.139.74) 8.003 ms 8.121 ms 7.923 ms
10 TWITTER-INC.edge4.London1.Level3.net (212.113.14.238) 8.134 ms 8.378 ms 8.224 ms
11 xe-1-2-1.iad-cr2.twttr.com (199.16.159.125) 80.171 ms
xe-0-2-1.iad1-cr1.twttr.com (199.16.159.123) 80.487 ms
xe-1-2-1.iad-cr2.twttr.com (199.16.159.125) 80.191 ms
12 ae60.pao1-cr2.twttr.com (199.16.159.87) 148.771 ms 149.139 ms 148.553 ms
13 ae51.smf1-er1.twttr.com (199.16.159.29) 153.855 ms
ae52.smf1-er1.twttr.com (199.16.159.49) 153.518 ms
ae51.smf1-er1.twttr.com (199.16.159.29) 158.001 ms
14 r-199-59-150-7.twttr.com (199.59.150.7) 153.049 ms 153.089 ms 152.980 ms

On y apprend, en vrac :

• que notre trafic sort par notre fournisseur de transit Level3 (AS3356)
• que celui-ci dispose d’un réseau ou les paquets n’empruntent pas systématiquement le même chemin (voyez, sur les points 6 7 et 8, plusieurs routeurs différents nous répondent)
• qu’il dispose d’une interconnexion avec le réseau Twitter à Londres
• que Twitter nomme les noeuds de son réseau en fonction des codes IATA des aéroports voisins
• que Twitter dispose manifestement d’un lien en propre entre Londres et Dulles en Virginie
• que Twitter dispose aussi d’un réseau où les paquets se promènent n’importe où (voir les points 11 et 13)
• qu’après un petit tour par Palo-Alto (pao), le trajet se termine du coté de Sacramento (smf), ce qui est corroboré par la presse

Mais ceci ne nous renseigne que sur le chemin possible à l’instant T et dans un seul sens. BGP va plus loin et nous permet de connaître d’éventuels chemins alternatifs existants et pouvant prendre la relève au pied levé. Pour les connaître, on va utiliser les looking glass des opérateurs. Par exemple, celui de notre réseau cobail, et lui donner à manger l’adresse IP déjà utilisée avec un routeur situé à Paris :

BGP routing table entry for 199.59.148.0/22, version 69664663
Paths: (3 available, best #1, table Default-IP-Routing-Table)
Multipath: eBGP
  Advertised to update-groups:
     9          11        
  3356 13414, (aggregated by 13414 199.16.159.247), (received & used)
    79.143.241.12 (metric 100) from 79.143.241.12 (79.143.241.12)
      Origin IGP, metric 11, localpref 130, valid, confed-internal, best
      Community: 3356:2 (Europe) 3356:22 3356:100 3356:123 (Customer route) 3356:500 (UK) 3356:2064 (LON - London) 29608:30600
  5511 5511 5511 5511 2914 13414, (aggregated by 13414 199.16.159.247)
    193.251.251.33 from 193.251.251.33 (193.251.245.123)
      Origin IGP, metric 11, localpref 129, valid, external
      Community: 5511:666 5511:710 5511:5511 29608:30400
  5511 2914 13414, (aggregated by 13414 199.16.159.247), (received-only)
    193.251.251.33 from 193.251.251.33 (193.251.245.123)
      Origin IGP, metric 0, localpref 50, valid, external
      Community: 5511:666 5511:710 5511:5511

L’expression est un peu moins évidente à lire, mais ça se fait :

• Cette IP est contenue dans une route qui a un masque de /22
• Le routeur à qui nous avons demandé connaît à priori 3 chemins différents pour joindre cette route (en vérité il n’en a que deux)
• La première est celle qui est active actuellement
• On y retrouve l’information du traceroute ci-dessus, à savoir que pour joindre Twitter (AS13414) on passe par Level3 (AS3356)
• Suivent un tas d’informations internes au routeur sur l’origine de la route, les préférences qui lui sont appliquées
• Puis une ligne fort intéressante détaillant les communautés de la route ou l’on apprend, de Level3, que la route a pour origine une connexion en Europe, de l’un de ses client (Twitter), plus précisément au Royaume Uni, et encore plus précisément à Londres, ce qui confirme encore une fois l’info trouvée dans le traceroute (notez que ces informations ne sont pas toujours écrites au format humain, bien souvent, on n’a que des chiffres)
• Suivent les mêmes informations pour deux autres routes, passant par AS5511 (OpenTransit, le réseau longue distance d’Orange) puis par un autre opérateur (AS2914, NTT) avant d’arriver chez Twitter
• Les deux routes en question ne sont en fait qu’une seule et même route, la seconde étant celle qui a été reçue par le transit (indiquée received-only), la première étant celle réellement prise en compte par le routeur après le passage dans nos filtres locaux (qui ont manipulé le metric, la local pref et le listing de communautés).

On sait donc maintenant qu’en cas de panne de Level3, notre connectivité vers twitter est à minima assurée par OpenTransit via NTT. Mais en posant la même question à un autre routeur de l’infrastructure, on apprend également l’existence d’une route via AS6453 (TataCommunications) qui elle-même repasse par AS2914.

Essayons à présent d’obtenir des informations sur la route de retour. Manque de pot, j’aurais dû mieux choisir mon exemple, il semble que Twitter ne propose pas d’outils looking glass publics. On va donc devoir se contenter des informations collectée par des tiers. En vrac, on trouve :

• Les informations qu’ils ont bien voulu publier sur leurs points de présence dans la base peeringdb
• L’analyse de leur connectivité effectuée par Robtex où on voit clairement que Twitter compte beaucoup sur Level3 pour sa connectivité et où on retrouve AS2914 qui sert d’intermédiaire à OpenTransit et TataCommunications.

La compilation de toutes ces informations laisse à penser que le trafic remontant de Twitter vers nous doit également passer par Level3, puisqu’il semble que ce soit le fournisseur le plus utilisé par Twitter. On a également appris, via peeringdb, que Twitter était présent à Londres et à Amsterdam sur les points d’échanges AMS-IX et LINX, et qu’on pouvait donc espérer le joindre directement si on se donnait la peine d’étendre notre réseau jusqu’à l’un de ces deux points d’échange.

Malheureusement, même si certains offrent des possibilités peu onéreuses pour rejoindre ces points, une petite association aura du mal, au début, à se les offrir. Fort heureusement, un tas de petits boulangers du réseau peuvent aider, en fournissant par exemple, presque gratuitement, un bout de leur bande passante, l’important étant, alors de faire attention à la redondance en se posant la bonne question : mes deux fournisseurs partagent-ils beaucoup d’infrastructures communes ?

Par infrastructure on entend principalement les fournisseurs de transit, les salles d’hébergement et les réseaux de transports. On pourrait par exemple être tenté, lorsqu’on est une association, de prendre la combinaison Gitoyen (AS20766) et Gixe (AS31576). On va donc aller voir ce qu’on trouve comme informations. Restons sur les outils fournis par Robtex pour plus de simplicité, même s’il ne sont pas parfaits ni exhaustifs :

• Gitoyen semble utiliser principalement AS6453 (TataCommunications), AS29608 (Wan2many) et AS29075 (Ielo)
• Gixe, lui, utilise manifestement AS8928 (Interoute) et AS29075 (Ielo)

Nos deux fournisseurs partagent donc au moins un fournisseur commun (Ielo) mais ont aussi d’autres moyens  de sortie, ce qui semble suffisant pour s’assurer une redondance convenable en cas de problèmes.

Pour ce qui est des salles d’hébergement et des liens physiques, c’est plus difficile à trouver soi-même, dans la mesure où il est impossible de connaitre les propriétaires ou exploitants finaux des fibres utilisées. Il faudra donc poser la question aux fournisseurs sélectionnés avant d’arrêter un choix.

Un dernier petit mot pour vous montrer le très réussi looking glass de l’association Tetaneutral. On y apprend, en un seul dessin, que Tetaneutral dispose d’au moins 4 transits et d’une liaison directe avec l’AMS-IX. C’est l’image qui a servi d’illustration au présent article.

Dans le prochain épisode, on causera de conception du réseau et d’accès out of band pour avoir la main même quand tout est pété.

J'apprécie beaucoup le serveur web Nginx. Mais étant moins populaire et plus jeune qu'Apache, il n'est pas toujours facile de trouver les bonnes informations au bon moment. Je vous propose donc un petit aide-mémoire amélioré. Attention, il faut avoir un peu de connaissance du fonctionnement d'un serveur web et déjà installé nginx.

Tester sa configuration

Avant de redémarrer le serveur web et éventuellement de le planter le temps de trouver l'erreur (au hasard, un ";" oublié ou une accolade mal placée), il est bon de tester la configuration avec :
nginx -t

Configuration de base

Désactivation de l'affichage de la version de nginx sur les pages d'erreur

Afin d'éviter à un méchant pirate de l'Internet d'en savoir trop sur la version de notre bien aimé Nginx, mieux vaut désactiver son affichage. Dans /etc/nginx/nginx.conf :
server_tokens off;


Un premier hôte virtuel tout simple

Nous voilà avec un hôte simple, qui répondra à moi.fr en http et https. Si l'on ne précise pas de chemin après moi.fr, index.htm sera servi. Sinon, soit un chemin vers une vraie page est spécifié, et elle sera servie, soit le chemin indiqué ne mène nulle part, et une erreur 404 sera renvoyée. Les éventuels sous-dossiers seront traités de la même façon : si je tente http://moi.fr/toto/ , si une page d'index dans toto existe, elle sera servie, sinon, j'obtiendrai une erreur 404.

Activer php

Pour l'instant, notre petit serveur ne fournira que des pages statiques, php ne sera pas interprété. Voilà comment y remédier. Mais attention, il ne s'agit ici que du lien entre nginx et php-fpm, pensez à adapter /etc/php5/fpm/php.ini à vos besoins !

Installer php-fpm

Rien de bien sorcier, il suffit d'un bon vieux apt-get install php5-fpm et le tour est joué. Suivant votre usage, il sera probablement utile d'ajouter d'autres modules php.

Lier nginx et php-fpm

Ici, il faut ajouter les lignes suivantes à votre hôte virtuel :

On demande donc à nginx, pour tous les fichiers .php, de communiquer avec le port 9000 de localhost, l'index étant index.php et en autorisant https. Si l'on ne trouve pas la page php demandée, on renvoie une erreur 404 (try_files $uri =404;) . Les deux lignes suivantes permettent de gérer correctement les chemins des scripts ou donnés aux scripts. Et la dernière ligne permet d'inclure les paramètre globaux de fastcgi.

Options diverses

Autoriser l'indexation

Pour autoriser l'indexation des fichiers d'un répertoire ou dans un hôte virtuel, utiliser l'instruction :
autoindex on;

Paramétrer le serveur par défaut

Dans certains cas, si un visiteur arrive vers votre serveur sans utiliser un nom d'hôte correct, il peut être utile de l'envoyer vers un hôte virtuel spécifique. Les instructions default_server sont alors faites pour vous :
server {
listen 80 default_server;
listen 443 default_server ssl;
...

Redirection et réécriture

Redirection

Pour rediriger une adresse vers une autre, il convient de renvoyer un code http 301 :
server {
listen 80;
server_name vieilleadresse.fr;
return 301 nouvelleadresse.fr$request_uri?;
}
Ainsi, la requête vers vieilleadresse.fr/coucoulesamis.html sera redirigée vers nouvelleadresse.fr/coucoulesamis.html .

Forcer le https

Il est possible de la même façon de forcer le protocole https (ou http) en utilisant la réécriture :
server {
listen 80;
server_name moi.fr;
rewrite ^ https://$server_name$request_uri? permanent;
}
Comme vous le voyez, il suffit de demander à nginx d'ajouter https:// au schéma d'url demandé au serveur.

Gérer les accès à certains répertoires

En tant qu'administrateur avisé, il n'est pas certain que vous souhaitiez voir certains répertoires accessibles au commun des mortels depuis l'internet, en particulier certains dossiers contenant la configuration des applications web. En général, avec Apache et la plupart des serveurs http, vous utiliser un fichier .htaccess situé à la racine du dossier incriminé pour gérer cela. Las, Nginx ne gère volontairement pas le .htaccess, pour des raisons de performance. Mais ne vous en faites pas, les développeurs du projet ont tout de même pensé à vous.

Interdire l'accès à un répertoire

Pour interdire l'accès à un répertoire, il convient de procéder comme suit :
location /monrepertoiresecret/{
deny all;
}
Ainsi, on interdit l'accès au dossier mais pas à ses sous-répertoires. Pour que l'interdiction soit récursive, une légère modification s'impose :
location ~ ^/monrepertoiresecret/{
deny all;
}
Dans un hôte, il peut être souhaitable d'interdire l'accès à plusieurs dossiers. Mais comme nous sommes paresseux, et que l'on nous a appris que la duplication de code c'était mal, nous allons nous contenter d'une directive :
location ~ ^/(dossier1|dossier2|dossier3){
deny all;
}
Et l'accès à nos trois dossiers est interdit, récursivement, en une directive.

Accès protégé par mot de passe

Là aussi, il faut jouer avec les directives. Mais auparavant, il convient de préparer un fichier contenant le nom d'utilisateur et le mot de passe. Chaque ligne définit un couple identifiant/mot de passe, ainsi qu'un commentaire. Ce fichier doit être accessible par Nginx. Chaque ligne se compose comme suit :
utilisateur:mot_de_passe_chiffré:commentaire
Le commentaire est facultatif. Pour chiffrer votre mot de passe, vous pouvez utiliser la commande openssl passwd, à condition bien entendu que le paquet openssl soit installé sur votre système. La directive pour générer un accès protégé est la suivante :
location / {
auth_basic "Qui va là?"; #Ceci s'affichera en titre de l'invite de mot de passe
auth_basic_user_file /chemin/vers/votre/fichier/motdepasse;
}
Les règles pour la récursivité, etc. sont les mêmes que précédemment.

Factorisation

Il est utile de placer certaines directives dans tous les hôtes virtuels, pour des raisons de sécurité ou pour ne pas journaliser certains événements. Mais dupliquer, c'est mal, on y revient. Pour factoriser, il suffit de créer un fichier .conf, et d'y placer les instructions souhaitées. Par exemple, dans /etc/nginx/commun.conf :

Ces trois directives permettent, dans l'ordre, de ne pas journaliser les accès à favicon.ico, qu'ils soient réussis ou non; de refuser l'accès aux fichiers commençant par un .ht (.htaccess, .htpasswd, ...); et finalement de ne pas journaliser les accès à favicon.ico, qu'ils soient réussis ou non. Il suffit maintenant de les inclure dans chacun de nos hôtes virtuels :
server {
...
include /etc/nginx/commun.conf;
}

Ressources

Si vous comprenez l'anglais, ne manquez pas la lecture des "Pitfalls", les erreurs communes de configuration
Configuration Nginx : Wiki
NGinx : HTTPS en tout simplicité avec un certificat CAcert.org

Conclusion

Je pense que vous avez maintenant matière à vous rafraîchir la mémoire ou à commencer à vous amuser sérieusement. Je n'ai ici qu'effleuré les capacités de Nginx, mais je pense que beaucoup d'usages simples seront couverts. Je tiens à remercier Jean-Michel qui m'a fait découvrir Nginx.

Derrière ce titre volontairement provocateur se cache un fait qui a le don de m'énerver au plus au point : le quasi monopole d'Apache dans le milieu de l'hébergement web, qu'il soit professionnel ou non, dans les datacenters comme dans les serveurs embarqués. Ne vous méprenez pas, Apache est un très bon logiciel, c'est même un de ceux qui a permis à Linux de décoller rapidement dans le domaine des serveurs. Seulement ce n'est pas la réponse universelle en matière d'hébergement, loin de là.

Quand on voit le nombre de gens qui s'évertuent à essayer de le faire tourner avec des performances décevantes sur des systèmes comme le Raspberry Pi je me dis que certains tutoriaux grands publics devraient mettre un peu d'eau dans leur vin à propos de ce logiciel. D'autres serveurs web existent et offrent des performances incomparables et une configuration facile et sécurisée. Dans le domaine de l'embarqué par exemple un serveur comme Boa écrase bon nombre de ses concurrents pour ce qui est de servir des fichiers (le job principal d'un serveur web) pour une emprunte mémoire moindre.

L'autre fait qui m'incite à parler de ce problème est le fait que beaucoup d'applications web proposent un fonctionnement basé sur les fichiers htaccess, ces fichiers de configuration propres à Apache. Cela rend l'installation de ces applications difficiles sur d'autres logiciels. La personne voulant installer l'application devra d'abord comprendre la configuration d'Apache avant de la transposer dans la configuration de son serveur web. C'est totalement contre productif et cela instaure un fossé entre les utilisateurs d'Apache et les autres.

Le web se base sur des protocoles, pas sur des logiciels. Quelques années auparavant on avait un problème similaire avec Internet Explorer qui avait un monopole dans le web et tout le monde s'accorde pour dire que ça n'apporte rien de bon. Mon conseil ? Essayez un des serveurs alternatif comme Lighttpd, Nginx ou Cherokee, juste pour tester. Je suis certains que beaucoup oublieront bien vite leur vieux et lourd Apache.

Cela fait un peu plus de 2 ans que j'auto-héberge presque tous mes services en ligne. J'avais fais plusieurs articles pour expliquer ce que je voulais héberger, comment je voulais le faire et avec quoi je voulais le faire.

Dans cet article, je vais faire une synthèse de l'utilisation de mon serveur à la maison, les applications que j'utilise le plus, les choses que je recommande et que je déconseille, fort de ces 2 ans d'expérience. Vous pourrez peut-être y découvrir des applis et/ou piocher des idées ;)

Partie matérielle

Un retour d'abord sur mon serveur à proprement parlé (le côté matériel). Pour mémoire, j'avais choisi cette configuration. Depuis, j'ai juste acheté un disque dur 2.5" supplémentaire pour faire mes sauvegardes (mon boîtier peut accueillir 2 disques durs).

Pour faire court, je suis extrêmement satisfait de cette configuration. Mes 1Go de RAM me suffisent amplement, mon CPU n'est jamais trop chargé, mon disque dur n'explose pas, le boîtier est complètement silencieux, bref, tout est parfait. Le seul point d'engorgement que j'ai c'est ma bande passante (j'ai 100kb/s en upload, cela devient, de temps en temps, trop peu).

Un collègue à moi souhaite se mettre à l'auto-hébergement, je lui ai donc recommandé le même genre de configuration que la mienne (je dis le même genre car ma carte mère n'est plus disponible à la vente semble t-il). Il souhaite faire en plus du Tomcat, je pense que ça tiendra largement la charge (avec 1Go de RAM en plus au cas où).

Partie logicielle

Sécurité

Concernant la sécurité de mon serveur, j'ai été agréablement surpris. Les outils que j'ai mis en place (fail2ban, la sécurisation de mon PHP, le changement du port SSH et quelques autres broutilles) ont largement suffit. Ceci dit, je reste toujours très vigilent sur les applications que je mets en place et les maintiens toutes à jour (applications ou OS). D'ailleurs, la semaine dernière, j'ai du bannir une IP (via les iptables) qui s'amusait à télécharger 200 fois le même fichier sur une période plusieurs heures. Comme quoi, il faut vraiment rester vigilent :)

Sauvegardes

Pour mes sauvegardes, voici ce que j'avais mis en place : sauvegarde de mes bases de données et des répertoires importants de mon serveur (/etc, /var/www, etc.). C'est bien connu, on ne se rends compte du bienfait des sauvegardes en cas de pépin uniquement. Depuis 2 ans, je n'ai eu besoin d'avoir recours à ces sauvegardes qu'une seule fois, il y a 1 mois, quand une mise à jour Piwik s'est mal passée, tout mon système de stats était planté, j'ai donc pu revenir en arrière grâce à mes sauvegardes de la veille.

Pour résumer, je sauvegarde mon /var/www ainsi que les dumps MySQL et tout mon /home/ sur le deuxième disque dur de mon boîtier (en rsync, toutes les nuits). Je fais également une sauvegarde du /var/www et les dumps MySQL sur une clé USB branchée en permanence sur le serveur (une fois par mois).

Applications

Voici la liste des applications que j'utilise chez moi. Je vais m'attarder sur les plus importantes et lister les autres en vrac par la suite :

Lecteur RSS

Mon lecteur de flux RSS est l'application que j’utilise le plus sur mon serveur. Je l'utilise plusieurs fois par jour sans exception. À la mise en place de mon serveur, j'utilisais Tiny Tiny RSS pour lire mes flux RSS. L'application était plutôt sympa mais je lui reprochait deux choses : une certaine lourdeur à l’exécution et surtout une consommation de base de données excessive. Au bout de quelques mois, ma base de données atteignait plusieurs centaines de Mo. C'était ingérable à plus long terme, j'ai donc cherché autre chose et je suis tombé sur une perle : RSS Lounge !

Je trouve RSS Lounge parfait. Il est simple à installer, très léger, gère les raccourcis claviers et surtout ne consomme presque rien en base de données (on voit bien que les vieux flux sont purgés de la base, contrairement à TTRSS). À titre de comparaison, je l'utilise depuis plus d'un an et demi et ma BDD pèse seulement 1,50Mo !

Malheureusement, le développeur a abandonné le projet au profit de selfoss. J'ai testé ce dernier, je n'aime pas du tout. Du coup, je reste sur RSS Lounge pour le moment (et certainement pour un bon bout de temps). J'espère que le projet sera forké :)

Lecteur de musique

Le deuxième service que j'utilise le plus après RSS Lounge est mon lecteur de musique. En effet, quand je suis au boulot, j'ai quasiment toujours mon casque sur les oreilles avec de la musique. Je n'écoute pas la radio (sauf parfois Streaming Soundtracks), je n'écoute que mes musiques. Mes musiques étant stockées chez moi (sur mon serveur justement), j'ai du chercher un logiciel qui me les diffusent sur Internet. J'ai trouvé mon bonheur il y a quelques années : Subsonic. Ce logiciel est vraiment une tuerie ! Il me joue mes fichiers musicaux et vidéos en streaming (peut importe le dossier où ils se trouvent sur mon serveur), me télécharge mes poadcasts tous les jours, me génère des playlists aléatoires en piochant dans tous mes albums, etc. Et le fin du fin, j'ai une application Android qui permet de lire mes musiques partout avec mon téléphone :)

Blogs / Sites

Mon serveur héberge pas mal de sites web et de blogs. Depuis que je l'ai, j'ai récupéré quasiment l'intégralité de ces sites hébergés par-ci par-là. Il y a différents CMS :

• Dotclear pour ce blog et mon blog perso ;
• Wordpress pour le blog de ma chérie, un blog sur notre bébé que nous tenons pour notre famille et le site d'une association ;
• Moonmoon pour le planet Raspberry Pi.

Wiki

Comme j'ai une mémoire de mouche, j'ai toujours pris l'habitude de documenter tout ce que je fais (en informatique). Du coup, dès que j'ai mis en place mon serveur, j'ai installé un système de wiki dokuwiki pour pouvoir tout documenter. J'adore dokuwiki, le fait qu'il n'utilise pas de base de données, qu'il soit régulièrement mis à jour (et que je l'ai mis en place à l’université où je travaille) y sont pour quelque chose :) Je l'utilise également pour mes notes personnelles. Bref, un indispensable là encore !

Divers

• J'ai mis une webcam sur mon serveur (qui se trouve dans le salon). Ainsi, avec le logiciel motion (que j'avais utilisé sur mon Raspberry Pi), je peux regarder ma chérie et mon bébé dans le salon pendant que je suis au boulot.
• Je suis un grand lecteur de comics, je les télécharge et les lis sur mon ordinateur. Un jour, je me suis demandé si je ne pouvais pas avoir mes comics sur mon serveur avec une application de lecture de comics en ligne. J'ai trouvé mon bonheur avec php-cbviewer. Cette application va extraire et lire les fichiers cbr à la volée, c'est super pratique !

• J'ai fait un petit script qui va extraire mes logs d'erreur apache et me les transformer les dernières lignes en une page HTML toutes les 5 minutes. Ainsi, je peux accéder à mes logs depuis n'importe quel navigateur, même si je ne dispose d'aucun accès SSH. Par ailleurs, tout est agrégé dans cette même page, cela me permet donc d'avoir une vue d'ensemble rapidement.
• J'ai codé une petite page HTML qui me sert de page d'accueil sur tous mes navigateurs. J'y ai mis des liens vers les principaux sites sur lesquels je vais ainsi qu'un champ de recherche Google. Je ne peux plus me passer de cette page (merci à HacKurz pour la bonne idée) :)

• J'utilise Piwik pour afficher mes statistiques d'accès à mes différents sites web. La base de données de piwik va bientôt atteindre les 1Go, il va falloir que je regarde pour purger tout ça.

• Il me fallait une application d'upload de fichiers rapide (un exemple d'utilisation, j'upload via une interface web un PDF sur mon serveur et je donne le lien pour qu'un ami le télécharge). J'utilise pour cela une petit appli toute simple KOLoad. Cette appli liste le contenu d'un répertoire et permet d'y uploader où d'y télécharger un fichier. On peut faire en sorte que l'accès soit public ou privé. C'est simple, c'est bien :)

• Un bon serveur a toujours son système de téléchargement. J'utilise le plus connu d'entre eux : transmission. L'avantage de transmission est qu'il est simple d'utilisation et possède une interface web super sympa. Du coup, je peux mettre des trucs à télécharger depuis n'importe où.

Applications/Services abandonnés

Voici une liste des services que j'ai installé, utilisé puis abandonné :

• Owncloud : j'ai testé la version 5, je la trouve vraiment beaucoup trop lourde, pas très jolie et buggée. Bref, je n'en suis pas satisfait et ne l'utilise plus ;
• ma galerie photos : j'avais mis en place une galerie photos sur mon serveur (grâce à iGalerie). Je me rends compte au final qu'elle n'est jamais utilisée, je vais donc la supprimer. Je ne pense pas la remplacer. Il n'y a pas beaucoup de photos que je souhaite mettre en ligne finalement ;
• Tiny Tiny RSS : Pour les raisons que j'ai évoqué plus haut dans l'article ;
• SimpleID : J'avais présenté SimpleID dans cet article. Il permet d'être son propre fournisseur d'identité OpenID. Force est de constater qu'OpenID ne se repends pas sur le web, je ne l'utilise donc plus non plus (je crois que j'ai du l'utiliser une seule fois "en vrai" depuis que je l'ai mis en place (il y a 2 ans)) ;
• ejabberd : Le fameux serveur XMPP. J'utilisais ce serveur Jabber pour faire un tchat intégré à un site (avec Jappix Mini). Le site à été modifié, le tchat supprimé et je ne me sers plus de mon server Jabber (je ne communique pas en messagerie instantanée).

Projets/améliorations à venir

Voici les choses que j'aimerais faire cette année :

Chiffrage des données

C'est quelque chose que je souhaite faire depuis pas mal de temps : chiffrer les données sensibles présentes sur mon serveur. Je n'ai jamais pris le temps de regarder comment cela marchait. Après quelques recherches, mon choix s'est porté sur Truecrypt. Je vais avoir deux cas d'utilisations avec mes futurs projets (voir juste en dessous).

Politique de sauvegarde

Un point très important pour l'auto-hébergement, c'est la sauvegarde. Cela m'a toujours trotté dans la tête, j'ai toujours voulu avoir une politique de sauvegarde complète pour mon serveur et mes données.

Comme je l'ai déjà dit, mon serveur est actuellement composé d'un disque dur "principal", d'un autre disque dur sur lequel sont répliqués les répertoires les plus importants du premier (via Rsync) et une clé USB branchée en permanence qui contient les backups importants (MySQL + www). Il y a 2 problèmes à ce système :

• d'une part, si mon appartement brûle ou est cambriolé, je perds tout ;
• d'autre part, si quelqu'un vient simplement prendre la clé USB branchée au cul du serveur, il repart avec tout mon serveur MySQL sous le coude...

• je vais externaliser mes sauvegardes chez mes beaux parents (à 100km de là) grâce à un disque dur externe chiffré et branché sur un Raspberry Pi accessible depuis chez moi uniquement ;
• je vais chiffrer tous mes supports de sauvegarde.

Synchronisations de mes dossiers

Owncloud et SparkleShare ne m'ont pas convaincu (j'explique ici pourquoi), mais je n'ai pas perdu l'envie de synchroniser des répertoires avec mon serveur et mes différents PC. Je pense donc faire cela avec Unison (ou SSHFS si Unison ne me convient pas). À suivre donc.

Héberger mes mails

J'ai mon serveur depuis plus de deux ans et je n'héberge toujours pas mes mails. Peur de la disponibilité de mon serveur et surtout mauvaise maîtrise des logiciels. Je voudrais bien sauter le pas tout de même. Pour cela, il faut que je me documente et que je comprenne un peu les rouages de Postfix & Co. Je ne veux pas juste suivre un tuto pas à pas, je veux comprendre tout ça et ça prends du temps. Dès que j'en ai, je m'y attelle :)

Dématérialiser mes documents administratifs

Je n'ai jamais réussi à ranger correctement les papiers importants. J'ai juste une grosse pile de papiers dans laquelle je remets le nez quand j'ai besoin d'un papier en particulier. Ça me gonfle à chaque fois. J'ai donc pensé scanner tout ça et les ranger correctement sur mon serveur. Cela implique de chiffrer l'ensemble. Je ne pense pas utiliser de logiciel de GED pour tout gérer, un simple SSHFS sera suffisant pour déposer ou récupérer ces papiers quand j'en aurai besoin. Petit problème, je n'ai aucune idée de la volumétrie nécessaire pour stocker tout ça.

Conclusion

Voila pour un petit retour de l'utilisation de mon serveur. Comme vous le voyez, il me reste encore plein de projets en tête. Comme d'habitude, tout sera documenté et expliqué sur ce blog. J'espère que cet article vous aura fait découvrir des choses et/ou donné des idées. Si vous avez des questions ou des remarques, comme d'habitude, n'hésitez pas ;)

Lorsque vous avez un accès par login ouvert à tous sur Internet, un des risques possibles est l'attaque par bruteforce. C'est à dire, un bot qui va essayer de se loguer avec tous les mots de passe inimaginables avant de trouver le bon. C'est une course contre le temps.

Les services de login implémentent alors souvent un mécanisme qui ralentit ces attaques (le login met excessivement 3 sec à vérifier que votre login est valide ou pas). Mais on peut faire encore mieux en bannissant les IPs des attaquants pendant 10 minutes si ils n'ont pas le bon login au bout de 5 essais. Ca tue leur espoir de vous bruteforcer direct .

Fail2ban est un logiciel qui fait ça. Ca marche d'office avec votre service SSH. Ca s'installe simplement depuis le gestionnaire de paquets de votre distribution Et si vous voulez aussi que votre login WordPress soit protégé? Installez simplement le plugin WP fail2ban .

Bienvenue chez vous!  Le serveur helios.im vous permettra de reprendre le contrôle de vos données publiques et privées sur internet. Sans abonnement, ni censure. Et sans publicité! Ce très petit ordinateur (par la taille) est suffisamment costaud pour héberger votre site web (blog WordPress) , vos fichiers (photos, mp3, documents), votre agenda, votre carnet d’adresses (ownCloud) et vos mails. Il est totalement silencieux. Il ne consomme que 3,5 Watt. Son mode d’emploi est réellement simple: ouvrez la boîte, posez helios.im sur votre box, branchez l’unique câble à la box, et la prise sur le secteur. Attendez 10 secondes… Voilà! Votre site web/blog WordPress est déjà prêt. Vous pouvez poster votre 1er billet. Vous pouvez envoyer et recevoir vos 1ers mails via votre adresse personnelle. Vos mails ne sont plus la propriété de Google ou Microsoft, ils sont stockés chez vous, accessibles par vous depuis le monde entier via l’interface webmail RoundCube.

Son faible prix et sa simplicité d’utilisation en font le serveur idéal pour les particuliers, les jeunes internautes, les associations, les artisans et les très petites entreprises. Si vous savez poster un commentaire sur un blog et envoyer un mail, vous saurez gérer votre serveur helios.im! Les rares réglages s’effectuent via une page web simple.

helios.im est installé sur un ordinateur ultra-compact Raspberry Pi (45 grammes, format carte à puce 8,6 cm × 5,4 cm). Il est livré monté dans un boîtier transparent, avec un câble Ethernet, un bloc alimentation, une carte SD, et au choix un disque dur externe ou une clef usb (solution économique). Tout le matériel est garanti un an. Le système d’exploitation n’est ni Mac ni Windows mais Raspbian, une adaptation de Debian GNU/Linux pour le Raspberry Pi. helios.im n’utilise que des logiciels libres et gratuits. Raspbian est extrêmement stable: votre serveur ne plante pas!

Helios.im est un bel objet, mais pas que. Nous assurons une aide à l’installation et un support technique personnalisé, par email, forum, twitter et téléphone. Le but est de partager les connaissances et les astuces pour que vous deveniez autonome. Quand vous pourrez vous passer de nos services, notre objectif aura été atteint! Vous disposerez d’1 nom de domaine de type xyz.helios.im et d’une infinité d’adresses mails du type moi@xyz.helios.im Vous êtes libres de faire évoluer votre serveur comme vous le souhaitez. Il est possible d’ajouter un lecteur de flux RSS, un serveur de chat Jabber. Le Raspberry Pi connaît déjà des milliers d’usages différents, il rassemble une vaste communauté d’enthousiastes: près d’un million de ces petits ordinateurs ont été vendus à travers le monde en un an!

Les premiers serveurs helios.im seront prochainement disponibles à la livraison. La boutique ouvrira bientôt ses portes.

Vous pouvez nous poser toutes vos questions via notre formulaire de contact.

Le « cloud » appartient au passé. Découvrez helios.im, un bout d’internet libre, sans nuage à l’horizon!

A très bientôt!

En attendant le votre, voici quelques photos du serveur helios.im numéro 1:

Vous souhaitez avoir quelques graphiques sur l'utilisation de votre serveur ?
Mais vous avez pas envie de partir sur une usine à gaz trop complète (et parfois trop complexe à installer), alors Munin est fait pour vous !

Munin, c'est quoi ?

C'est un logiciel libre (comme d'hab', le libre c'est bon !), qui sert de grapheur.
Il est basé sur RRDtool (qui lui est un système de BDD utilisé pour les données cycliques), et fonctionne avec un principe client / serveur.
Très polyvalent : Multiplateforme (il peut surveiller, des machines sous Linux, Windows, BSD …), fonctionne avec un système de plugins (qui sont faciles à utiliser et à développer) afin de "grapher" de nombreux services différents.

Vous allez donc pouvoir surveiller plusieurs machines physiques et virtuelles, et réunir toutes les informations sur un système centraliser.
Il faut garder à l'esprit que Munin est solution de monitoring "simple", bien qu'il existe des états pour surveiller certaines fonctions / composants, vous n'aurez pas de remonté d'alertes, de comparaisons de données …

ça n'en reste pas moins un outil intéressant pour suivre le fonctionnement de son/ses serveurs
 

Son installation :

Elle est très simple, car Munin est accessible la plus part du temps par gestionnaire de paquets.
Il faut toutefois faire une distinction entre le serveur et les clients (le serveur pouvant être lui même un client !).

Mon installation est faite sur une VM sous Debian 7.0 (Wheezy) et la version présente en ce moment dans les dépôts est la : 2.0.6-3

La partie serveur (et client au passage) :

# aptitude install munin munin-plugins-extra

La partie uniquement cliente :

# aptitude install munin-node munin-plugins-extra

Vous noterez que j'installe "munin-plugins-extra", c'est optionnel, ce paquet comprend des plugins pour différents programmes qui ne sont pas installés de base.

Munin étant écrit et utilisant des plugins en perl, cela va installer tout l'environnement nécessaire, ainsi que quelques dépendances nécessaires à Munin.
Il vous faudra également un serveur pour la consultation des graphs, de base c'est Apache qui est recommandé.

Une fois l'installation terminée, il faut modifier quelques fichiers de conf :

L'accès aux graphs :

# nano /etc/apache2/conf.d/munin

et changez :

<Directory /var/cache/munin/www>
        Order allow,deny
        Allow from all
        Options None

puis :

# /etc/init.d/apache2 restart

Vous pouvez faire un premier essai en consultant : http://monip/munin

Si jamais vous avez une erreur "403", vous pouvez décommenter et vérifier les chemins suivant dans /etc/munin/munin.conf

#dbdir  /var/lib/munin
#htmldir /var/cache/munin/www
#logdir /var/log/munin
#rundir  /var/run/munin

Puis :

# /etc/init.d/munin restart

Et si cela ne fonctionne toujours pas, je vous invite à faire un tour dans les logs /var/log/munin/ (ils sont assez bien fournis)

Les graphs sont mis à jour toutes les 5 min, vous pouvez changer cette intervalles dans la crontab nano /etc/cron.d/munin (pensez à adapter vos clients en conséquence).

Rajouter un client :

Je redonne la commande d'installation d'un client :

# aptitude install munin-node munin-plugins-extra

Il faut cette fois spécifier l'ip du serveur au client :

# nano /etc/munin/munin-node.conf

#allow ^127\.0\.0\.1$
allow ^192.168.0.239$

(chez moi c'est 192.168.0.239, à vous d'adapter )

On pense à faire :

# /etc/init.d/munin-node restart

Maintenant sur le serveur, il faut rajouter une entrée pour votre client :

# nano /etc/munin/munin.conf  

exemple pour mes clients :

[RaspberryPI.phisical]
    address 192.168.0.200
    use_node_name yes

[XMPP.ovz]
    address 192.168.0.241
    use_node_name yes

Le nom est renseigner entre les "[ ]", j'y indique le nom et le type de machine, afin des les classer par catégories.

Ne pas oublier :

# /etc/init.d/munin restart

Ajouter de nouveaux graphs avec des plugins :

L'intérêt de Munin, c'est de pouvoir grapher ce que l'on veut !
 

Quelques exemples :

• Monitorer températures, voltages, et vitesses des ventilateurs :
  (Dans mon cas, j'ai déjà installé lm_sensors, et j'ai déjà détecté mes sondes)

   

  # cd /etc/munin/plugins/

  # ln -s /usr/share/munin/plugins/sensors_ sensors_fan
  # ln -s /usr/share/munin/plugins/sensors_ sensors_volt
  # ln -s /usr/share/munin/plugins/sensors_ sensors_temp

  # /etc/init.d/munin-node restart

  Et on vérifie si les plugins sont bien pris reconnus :

  #munin-node-configure
  
  [...]
  sensors_                   | yes  | volt temp fan
  [...]

  Voilà ce que donne le graphique des températures (mis à jours toutes les 5 min) :
  
   

• Grapher le nombre de requêtes MySQL :

   

  # cd /etc/munin/plugins/

  # ln -s /usr/share/munin/plugins/mysql_queries mysql_queries

  # /etc/init.d/munin-node restart

  Le résultat :
  

Voici à quoi ressemble mon Munin, lorsque je contacte le serveur : http://monchemin.fr/munin

Et voici la vue (partielle) d'un client :

Je n'ai jamais aimé phpMyAdmin, je le trouve trop lourd, trop recherché par les robots et trop vulnérable aux attaques. Du coup, je me suis toujours refusé à l'installer sur mon serveur. J'ai toujours tout fait en ligne de commandes MySQL. Enfin tout... toutes les créations de bases et d'utilisateurs, mais jamais de ménage. Du coup, il y a quelques jours, je me suis rendu compte du bordel qu'il y avait dans ma base de données. J'ai donc décidé de chercher un utilitaire plus léger que phpMyAdmin pour faire un peu de rangement facilement. J'ai trouvé mon bonheur avec cette application géniale : SQL Buddy !

Installation et configuration

J'ai mis "installation et configuration" en même temps pour la simple raison qu'il n'y a aucune configuration nécessaire. C'est ça que j'ai trouvé génial avec cette application c'est qu'il vous suffit de récupérer de zip sur le site officiel, dézippez-le sur votre serveur et accédez-y avec votre navigateur. C'est tout, vous n'avez plus qu'à vous connecter à votre base de données :)

Utilisation

Une fois connecté, vous arrivez sur la page d'accueil de SQL Buddy qui liste les bases sur lesquelles vous avez les droits. Vous pouvez directement, via cette page, créer une nouvelle base de données et vous avez quelques explications, notamment sur les raccourcis claviers utilisables dans l'application :

Nous allons explorer les différents onglets ensemble.

Onglet Utilisateurs

Cet onglet va lister les utilisateurs présents dans votre base (ici je les vois tous car je m'y suis connecté en tant que root) :

Vous pouvez ajouter un nouvel utilisateur et choisir les bases sur lesquelles il va avoir tous les droits (ou certains uniquement).

Onglet Requête

Une petite interface simple qui va vous permettre de lancer des requêtes SQL directement :

Onglet Importer

Vous pouvez importer votre fichier .sql grâce à un formulaire :

Onglet Exporter

Vous pouvez également exporter tout ou partie de vos bases de données. Quelques options sont possibles comme, par exemple, l'export des données et/ou des structures ou encore la destination de votre export (en texte dans le navigateur ou dans un fichier .sql) :

Vue et détail des bases

Quand on clique sur le nom d'une base dans le menu de gauche, cela va déplier un arbre et nous afficher la liste de ses tables. Ça va également afficher une vue plus détaillée de ces tables dans la partie centrale de la fenêtre :

Plusieurs actions sont possible dans cette fenêtre : la suppression de la base, la modification du jeu de caractères ou la création d'une nouvelle table :

Vue et détail des tables

En cliquant sur une table, on a une vue détaillée de ses champs, des infos sur cette table, la possibilité de la modifier/supprimer ou optimiser :

Conclusion

Nous avons déjà fini le tour de cette application. Comme vous avez pu le voir, elle est très simple mais les actions les plus courantes sont possibles. C'est vraiment mon coup de cœur du mois :) Cela m'a permis de faire un bon ménage de printemps dans ma base de données. Je suis tellement parano que j'ai supprimé cette application de mon serveur mais je n'hésiterai pas à la remettre en place pour mes prochaines actions sur ma base de données. J'espère que cet article vous donnera envie de l'essayer et de me donner votre avis ;)

À bientôt

Je vais tenter ici d'exposer ma démarche lors de la mise en place de mon infrastructure d'auto-hébergement. L'objet n'est pas ici de donner le détail de la configuration de chaque brique, mais de détailler les étapes et les justifications des choix effectués.

Préambule : Qu'est-ce que l'auto-hébergement ? Quand est-il pertinent ?

L'auto-hébergement consiste à fournir des services, destinés à des tiers ou à soi-même, ces services étant gérés par une infrastructure située à son domicile, par exemple : un hébergement web (site, blog, etc.), un serveur mail, un serveur ftp (pour transférer des fichiers) et bien d'autres suivant les cas.

L'Internet des origines se voulait acentré : dans bien des cas, les machines y accédant étaient à la fois client et serveur. Hélas, désormais, quelques entreprises (Google, Amazon, Facebook, ...) regroupent presque la totalité des serveurs, et les machines des internautes ne sont plus que des clients. Cela pose entre autres des problèmes de gestion des flux (d'actualité en ce moment avec le bras de fer entre Google et Orange, le dernier voulant facturer au premier les échanges de données) et de confidentialité : vos données se promènent sur des serveurs que vous ne contrôlez pas, et vous n'avez pas d'éléments sur l'utilisation que fait le fournisseur de services de vos données ni sur la politique de sécurité qu'il applique. Pour plus d'éclaircissements sur la centralisation actuelle de l'Internet, je vous conseille la conférence de Benjamain Bayart.
La solution à ces deux problèmes peut être de se fournir soi-même les services que l'on désire utiliser, moyennant deux bémols. Le premier concerne les services nécessitant une haute disponibilité : votre connexion Internet et votre installation électrique ne présentent pas le niveau de sécurité de celles disponibles dans un centre de données, ce qui peut entraîner des interruptions de service. Le second est lié à la vitesse de connexion "sortante" : en ADSL, elle est au mieux d'un Mbit/s, ce qui peut être assez faiblard pour héberger des photos de bonne définition ou si vous bénéficiez soudain d'une grande notoriété.

Définition des besoins

Services à mettre en œuvre

Avant de se lancer, il paraît donc logique de réfléchir aux services que l'on souhaite mettre en place, en gardant à l'esprit qu'ils doivent être facilement maintenables. Dans mon cas, j'avais fait la liste suivante :

• Serveur mail (pour sortir de gmail). Demande peu de ressources.
• Serveur ftp (transfert de fichiers). Abandonné par la suite au profit de transfert ssh. Demande peu de ressources.
• Serveur DNS. Demande peu de ressources.
• Routeur WiFi. Abandonné afin de séparer les réseaux (cf. plus bas).
• Serveur XMPP (messagerie instantanée). Demande peu de ressources.
• Serveur SQL (base de données). La consommation de ressources peu grandement varier.
• Supervision & administration :
  • Serveur ssh (pour accéder en mode texte à la machine).
  • Monit pour contrôler la bonne exécution des services.
  • Webmin, pour contrôler et administrer à distance (assez lourd, et abandonné car l'accès en ligne de commande me suffit).
• Serveur Web (pour proposer des pages et d'autres services). La consommation varie selon le serveur et les services :
  • Webmail (consommation moyenne).
  • Gestion de documents (consommation importante, abandonné au profit d'un simple gestionnaire d'upload).
  • Gestionnaire de flux RSS (peut consommer quelques ressources lors de la synchronisation).
  • Blog (peu gourmand à la base, mais si il devient célèbre...).
  • Galerie photo (assez lourd).
  • Gestionnaire d'envoi de fichiers (léger, à part en bande passante).
  • Partage de liens, ToDoList, calendrier (peu gourmands).

Choix du matériel

Je ne souhaitais pas investir. J'ai réutilisé une EeeBox B202 que j'avais sous le coude, largement suffisante pour la plupart des services avec 2Go de RAM et 1.8GHz pour le processeur. Et avec l'avantage d'une faible consommation (le serveur allumé en permanence ne me coûtera pas plus de 50€ d'électricité par an). Il est aussi possible de recycler une machine assez ancienne, mais attention à la consommation (et au bruit, suivant la façon dont vous allez la placer chez vous).

Choix du système d'exploitation et des logiciels fournissant les services

Certains choix paraîtront évidents, comme Debian le fut pour moi. L'alchimie avec un logiciel, c'est quelque chose de difficile à définir. En tout état de cause, il convient que les logiciels utilisés soient stables, éprouvés en terme de sécurité et d'en connaître l'origine. Certains classiques sont incontournables (je pense à Bind en tant que serveur DNS), d'autres sont parfois remis en question (J'ai remplacé Apache par Nginx en terme de serveur web, et je suis très satisfait de ce choix). Et hop, encore une liste pour exposer mes choix :

• Logiciels :
  • Serveur mail : postfix +dovecot.
  • Serveur DNS : Bind .
  • Serveur XMPP : ejabberd. Je suis finalement passé à Prosody. J'ai eu un souci avec ejabberd et les logs sont vraiment très difficilement exploitables. Pourtant, je ne suis pas un perdreau de l'année.
  • Serveur SQL : mySQL. J'aurais bien tenté Postgre mais je ne me sentais pas de trop expérimenter.
  • Serveur Web : NGinx, j'ai été bluffé par le concept, la réactivité du serveur... Par contre, il faut reprendre des habitudes de configuration et les fichiers .htaccess ne sont pas interprétés.
    

• Services Web :
  • Webmail : Roundcube. Je pense qu'il a le meilleur rapport consommation / ergonomie / fonctionnalités.
  • Gestionnaire de flux RSS : Leed.
  • Blog : Dotclear.
  • Galerie photo : J'ai testé Gallery3 puis je suis revenu à Piwigo, mais il se peut que je change pour un script beaucoup plus simple...
  • Gestionnaire d'envoi de fichiers : J'ai choisi la solution de BlueImp.
  • Partage de liens : Shaarli (je l'adore).
  • ToDoList : MyTinyTodo, plus maintenu mais largement suffisant pour mes besoins.
  • Calendrier : WebCalendar. Simple et efficace.

Emplacement & esthétique

Cela peut sembler trivial, mais ce n'est finalement pas le choix le plus simple. Il ne faut pas être trop loin de la box pour éviter de tirer des câbles. Il faut trouver un meuble adapté en termes de ventilation et de passage des câbles. Personnellement, j'ai fait un meuble à ma convenance avec des chutes de bois (vous le verrez plus bas). Et une installation propre, silencieuse et esthétique voire peu encombrante augmente le facteur d'acceptation conjugal, qui n'est pas à négliger...

Choix du nom de domaine

L'air de rien, ce n'est pas forcément l'étape la plus simple. Le nom de domaine vous suivra plusieurs années, voire une bonne partie de votre vie. Il doit vraiment vous plaire et donner une idée à vos visiteurs. Vous pourrez toujours prendre de nouveaux noms de domaine, mais il vaut mieux conserver les anciens : cool urls don't change!. Parfois, il peut être bon d'utiliser deux noms de domaine, un plus orienté vers vos services "publics" (blog, partage de liens, ...) et l'autre plus privé, à votre nom s'il est disponible (pour les mails privés voire professionnels).

Mise en place

Emplacement physique

Voilà mon installation, à 1m50 de la prise électrique et de l'arrivée de la fibre optique, calée dans un angle de l'entrée entre un meuble de rangement et un radiateur (qui n'est jamais allumé) :

En bleu, le retour WRT-54GS. En blanc, le serveur lui même, l'EeeBox B202. Au fond, la box SFR. En bas, les alimentations électriques et en haut, la base pour le téléphone DECT. Le câblage est perfectible avec des câbles plus courts. Mais pour une "armoire de brassage" en matériau de récupération et artisanale, je ne suis pas mécontent du résultat !

Architecture réseau

L'idée est de séparer le serveur des autres machines du réseau. Ainsi, si le serveur est compromis, les postes de travail du réseau ne tombent pas avec lui. J'ai donc procédé comme suit :

• Box : 192.168.1.1
• Routeur : 192.168.1.2/192.168.0.1
• Serveur : 192.168.1.10
• LAN : 192.168.0.0/24, pour mes machines en filaire en IP fixe et une plage DHCP fournie par le routeur pour le WiFi.
  

Ainsi j'accède au serveur de mon LAN (via son IP ou le DNS avec des vues DNS) mais le serveur ne peut accéder à mon LAN. J'ai ouvert les ports nécessaires (NAT) de la box vers le serveur ou de la box vers le routeur.

Installation du système d'exploitation

Rien de bien extraordinaire de ce côté là. Une simple installation d'une Debian Testing sans interface graphique. J'ai branché clavier/écran sur la machine le temps de faire l'installation de base + paramétrage réseau + ssh et ensuite j'ai mis le serveur à sa place et j'ai tout fait via ssh.

Installation/Paramétrage des services & logiciels

La phase la plus longue et fastidieuse. Autant l'on peut bien connaître certains logiciels, autant on en découvre d'autres avec des fichiers de paramètres inhabituels. On en apprend beaucoup à ce moment. Je ne rentre pas dans le détail de cette phase, il faudrait presque un sujet par service.

Phase de stabilisation

Voilà, les services sont paramétrés et tout semble fonctionner. Il reste quelques points à améliorer. Tout cela entre dans la phase de stabilisation. Il faut bien penser à contrôler les ports ouverts sur sa machine, que le serveur mail ne puisse servir de relais aux spammeurs, que le serveur web ne donne pas accès à des dossiers normalement inaccessibles, et j'en passe. Des tests de montée en charge peuvent être judicieux. Dans tous les cas, il sera plus simple de revenir en arrière sur un paramètre, un choix technique ou de tout casser pour reprendre de zéro maintenant qu'une fois le serveur passé en production.

Quelques conseils en vrac

Je vous propose ici une petite liste en désordre de points qui peuvent être utiles à quelqu'un qui voudrait se lancer dans la même aventure :

• Un bon moyen que votre serveur smtp ne soit pas considéré comme un spammeur est d'ajouter des enregistrements SPF à votre zone DNS.
• Quand vous effectuez des modifications sur le pare-feu à distance, ne modifiez pas directement le script qui se lance au démarrage, testez-en une copie à part. Ainsi, si vous vous êtes enfermés dehors, un redémarrage réglera la solution (Oui, ça sent le vécu...) !
• Migrez progressivement votre boîte mail vers votre nouveau serveur. Commencez par copier les mail sur votre nouvelle adresse et rediriger les nouveaux messages sur la nouvelle boîte. Laissez les choses ainsi un certain temps avant d'indiquer votre changement d'adresse à tous vos contacts, voire de fermer l'ancienne boîte.
• Faites un carnet de bord de la mise en place de votre serveur, étape par étape. Cela vous forcera à être plus méthodique, et ensuite vous pourrez fièrement le publier sur votre site. Je ne l'ai pas fait et je le regrette.
• Certaines box bloquent le port 25 en sortie pour les smtp autres que celui du FAI. Si vos mails ne partent pas et que vous ne comprenez pas pourquoi, désactiver ce paramètre pourra vous débloquer.
• Faites taire les bavards. Certains services donne beaucoup d'informations sur l'OS et leur version lors des tentatives de connexion. Le nom du programme ou du service suffisent largement (Par exemple "Benvenue sur le serveur SMTP" ou "Bienvenue sur le serveur Posfix" plutôt que "Postfix V x.y.z sur Debian ..."). Inutile de trop aider les méchants pirates de l'Internet.

Conclusion

L'auto-hébergement est une excellente expérience, dans laquelle je me lancerais à nouveau si c'était à refaire. Cela demande certes du temps, de la patience et un minimum de compétences, mais le jeu en vaut la chandelle, malgré les moments de découragement qui peuvent parfois survenir.

Nous voici au terme de ce long billet, qui n'est pas exhaustif, ce n'était de toutes façons pas son but. Ce n'est ni un tutoriel, ni une dissertation sur les principes fondateurs de l'Internet, mais un retour d'expérience qui je l'espère motivera certains d'entre vous à héberger au maximum vos propres services. J'ai également probablement enfoncé joyeusement quelques portes ouvertes. Pour terminer, je donnerai aux courageux le lien par lequel commencer l'aventure : auto-hebergement.fr .

Difficile d'être passé à coté de la tempette médiatique des derniers jours, à savoir la programmation de la fermeture du tant apprécié Google Reader.
Et pourtant …

C'est vrai !

Qu'à cela ne tienne, pourquoi ne pas s'auto héberger pour avoir un gestionnaire de flux éfficace, gratuit, et sans avoir l'impréssionner d'être "espionné" par dieu tout puissant ( alias Google) ?

Et bien allons y
Perso je n'ai jamais utilisé Google Reader, mais j'utilise depuis pas mal de temps Tiny Tiny RSS, c'est donc le bon moment de vous le présenter

  http://tt-rss.org

De quoi s'agit il ?

C'est donc un agrégateur de flux rss, atom …
Il s'agit d'une application en php, qui utilise une BDD pour stocker les flux en provenance d'autres sites.

Il est basé sur une interface web, et peut être couplé à des applications mobile (Android).
Gestion du SSL, multi utilisateurs, gestion des tags et labels, systèmes de plugins, multilingue (dont le Français) …
Gratuit, mis à jour régulièrement, à la fois simple et complet à l'usage, bref un must have !!!

Les pré requis :

• un serveur web (Apache ou Lightppd)
• Php en version 5.3 (ou plus)
• Une base de données MySQL ou PostgreSQL

Téléchargement :

La dernière version à ce jour est là : 1.7.5 (en date du 23/03/2013)

https://github.com/gothfox/Tiny-Tiny-RSS/archive/1.7.5.tar.gz

L'installation :

Elle est assez simple, comme toutes applis web, copiez les fichiers dans votre répertoire (de base sur Apache il s'agit de /var/www).
Editez le fichier config.php afin de renseigner les paramètres de la base de données. (vous aussi la possibilité de modifier l'url de votre appli, les réglages utilisateurs …)

Une fois installé, rendez vous à l'adresse : http://mondomaine.tld/emplacementdemonappli

Vous devriez avoir quelque chose comme ça (vous noterez que je ne suis pas à jour, mais grâce au module de maj automatique, ça va être vite réglé ^^) :

Par défaut les identifiants sont : "admin" et le mot de passe "password" 

Après vous êtres logué, vous arriver sur l'interface principale (qui sera vide chez vous, vu que c'est la première fois que vous l'utilisez ).

Bon mon screen n'est pas très vendeur, ça fait un peu bordélique, car j'ai beaucoup, beaucoup de flux, mais je m'y retrouve très bien !
à vous de faire pareil, pour cela rendez vous dans les options (bouton en haut à droite) :

Là y a de TOUT, gestion des utilisateurs, des catégories, des flux, mise à jour, plugins …
Je vais pas expliquer chaque fonction, ça serait vraiment trop long !

L'intégration :

Pour moi l'intêret de cette application par rapport à d'autre (même si c'est pas un cas unique évidemment), c'est son intégration assez poussé, dans les navigateurs, les mobiles/tablettes …

Voici une petite liste (mais y en a surement d'autres !) :

• Plugin Chrome / Chromium : https://chrome.google.com/webstore/detail/tiny-tiny-rss-notifier/pehjgkflglcdbmhkjjpfjomemgaaljeb
  Celui ci vous permet d'avoir toujours un oeil sur les flux en attente sur votre serveur, il est présenté sous une forme de petite icone, qui scrute votre serveur selon un temps définis, et vous indique le nombre d'actu en attente de lecture.

   

   

  

• Appli Android Officielle: Tiny Tiny RSS
  https://play.google.com/store/apps/details?id=org.fox.ttrss
  Compatible Smartphone et Tablette
  Elle est très bien, payante depuis peu sur le Play Store (pour soutenir l'auteur), mais elle est gratuite sous licence GPLV2, (merci Simon2Cyrene pour l'info )
  https://f-droid.org/repository/browse/?fdcategory=Internet&fdid=org.fox.ttrss&fdpage=2

   

   

  

• Appli Android tierce : TTRSS-Reader
  Bien que très bien, et qu'elle mérite son prix, l'appli officielle à l'inconvéniant d'être payante, c'est pour ça que l'on trouve celle ci ! (que j'utilise maintenant d'ailleurs)
  Compatible elle aussi smartphone et tablette.
  https://play.google.com/store/apps/details?id=org.ttrssreader&feature=related_apps

   

   

     
   

• … il y a de base un plugin pour Owncloud, une intégration Firefox …

/!\ Par contre attention, c'est gourmand en BDD, je l'utilise depuis 4 mois, et j'ai une BDD contenant plus de 30000 articles, cela fait une base de 90 Mo !!!! (et ça représente en moyenne 15 req/s )

Si vous souhaitez l'essayer, vous pouvez créer un compte sur mon serveur : http://www.sheldon.fr/rss/register.php

Enjoy 

P.S il me reste plus qu'à faire la Maj de mon installation :

Quand on publie un site Web constitué de fichiers statiques avec le Serveur HTTP Apache, on peut réduire le débit utilisé pour servir ces fichiers en activant la compression à la volée, avec le mod_deflate. Ainsi, si le client annonce qu'il prend cela en charge, Apache compressera les fichiers avant de les lui envoyer, et le client les décompressera à la réception.

Pré-compression

L'inconvénient de cette approche, c'est que le serveur doit effectuer la compression pour chaque requête ; il est plus efficace de pré-compresser les fichiers une fois pour toute, en conservant le fichier original pour les clients qui ne prennent pas en charge la décompression :

$ ls
index.html
$ gzip < index.html > index.html.gz
$ ls
index.html index.html.gz

On peut ensuite servir ces fichiers directement en indiquant qu'ils sont compressés. Cela se fait avec le mod_mime, en déclarant un nouvel « encodage » gzip — terme désignant une encapsulation dans le langage de la norme HTTP :

LoadModule mime_module /usr/lib/apache2/modules/mod_mime.so
AddEncoding x-gzip .gz .tgz

Négociation de contenu

Cela suffit à servir des fichiers pré-compressés, mais seulement pour les clients qui les demandent explicitement, par exemple index.html.gz. Ce n'est pas très utile, on peut donc utiliser le mod_negociation pour servir automatiquement le fichier compressé en réponse à une requête normale, index.html dans ce cas. Pour activer cette fonctionnalité :

LoadModule negotiation_module /usr/lib/apache2/modules/mod_negotiation.so
Options +MultiViews

Le problème, c'est que la « négociation de contenu », qui permet à Apache de servir un fichier parmi plusieurs candidats selon la langue, le codage et la compression pris en charge par le client, ne se déclenche que si aucun fichier ne correspond exactement à la requête. Or, même si index.html.gz serait un bon candidat pour une requête sur index.html, il y a justement un fichier index.html qui correspond à cette requête, et la négociation de contenu n'entre donc pas en jeu. Il faut donc renommer le fichier original :

$ mv index.html index.html.raw
$ ls
index.html.gz index.html.raw

… et déclarer un nouveau type de (non-)compression :

AddEncoding identity .raw

Avec cela, et en redémarrant le Serveur HTTP Apache, le fichier index.html.raw sera servi aux clients qui ne prennent pas en charge la compression, et le fichier index.html.gz à ceux qui la prennent en charge.

Encore un article sur Proxmox ??
Ben oui, y a matière à faire dessus !

Cette fois je vais parler du Pci Passtrough, "kécécé" ??

Il s'agit de pouvoir utiliser des périphériques physiques (comme des cartes réseaux, graphiques …) dans une machine virtuelle, afin qu'elle bénéficie d'un usage unique aux ressources matériels du composant.
Vous allez avec ça pouvoir créer un routeur/firewall virtuel avec Pfsense ou IpCop, faire une vm dédiée aux calcul GPGPU, faire un NAS avec une carte raid …

Sur le papier ça semble simple, beau, pratique… bref tout ce qu'il faut pour plaire !

Et ben nan, pas chez Proxmox !

Dans la pratique, les options n'existent même pas dans l'interface, vous aurez beau chercher, y a rien… donc perdez pas de temps, et mettons les mains dans le cambouis.

Dans un premier temps il est important de vérifier que votre hardware soit compatible (c'est souvent là que ça bloque !).
(mon serveur hôte étant sous Intel, je vais garder ce constructeur dans mes exemples, mais AMD propose également du matériel compatible )

• Le CPU: il doit supporter les instructions VT-X, c'est souvent le cas pour les familles de Core2Duo, Core2Quad, Core i5 / i7, les Xeon (à partir des série Exxxx
  attention aux CPU "grand publique" (sauf exceptions) comme les Pentium, Atom, Core i3…  ils ne supportent pas toujours pas ces instructions.
  Pour savoir si votre CPU est compatible, faites une recherche sur le site Intel Ark (http://ark.intel.com/fr).
  Voici la liste des CPU Intel ayant le VT-X : http://ark.intel.com/fr/search/advanced/?s=t&VTX=true

   

   

• La carte mère: oui car pour faire fonctionner notre super carte TV, dans notre super VM, il faut que le chipset de la CM soit compatible lui aussi avec des instructions de virtualisations, chez Intel c'est le VT-d (chez AMD on parlera de gestion d'IOMMU).
  C'est malheureusement beaucoup plus rare que sur les processeurs, il va falloir chercher du coté des cartes mère pour serveurs ou workstations.
  Généralement chez Intel les chipsets compatibles sont de la gamme Q ou X (mais là encore avec des exceptions).
  Voici une liste non exaustive : Q45 / Q65 / Q57 / Q67 / Z77 / X79 / X58 / 5520 / 5500 …
  Pensez à bien vérifier si vous achetez du nouveau matériel !
   

Maintenant que vous être sûr d'avoir le bon matériel (et de l'avoir bien activé dans le bios ), il faut modifier notre Proxmox 2.3 :
(comme je l'avais dit sur HFR, j'ai fais pas mal de modifs avant d'arriver à tout faire fonctionner, j'ai fais une synthèse, de ce qui est nécessaire).

On commence par modifier le fichier "default" de Grub :

# nano /etc/default/grub

Puis on modifie la ligne :

 GRUB_CMDLINE_LINUX_DEFAULT="quiet"

en

GRUB_CMDLINE_LINUX_DEFAULT="quiet intel_iommu=on"

Il faut créer un fichier à l'endroit suivant : 

# nano /etc/modprobe.d/kvm_iommu_map_guest.conf

pour y ajouter :

options kvm allow_unsafe_assigned_interrupts=1

# update-grub

REBOOT !!   

On vérifie que l'IOMMU est bien géré :

dmesg | grep -e DMAR -e IOMMU

Chez moi ça donne :

root@Willbure:~# dmesg | grep -e DMAR -e IOMMU
ACPI: DMAR 00000000bdaa00f0 00178 (v01    AMI  OEMDMAR 00000001 MSFT 00000097)
Intel-IOMMU: enabled
DMAR: Host address width 36
DMAR: DRHD base: 0x000000fed90000 flags: 0x0
IOMMU fed90000: ver 1:0 cap c9008020e30272 ecap 1000
DMAR: DRHD base: 0x000000fed91000 flags: 0x0
IOMMU fed91000: ver 1:0 cap c0000020630272 ecap 1000
DMAR: DRHD base: 0x000000fed92000 flags: 0x0
IOMMU fed92000: ver 1:0 cap c0000020630272 ecap 1000
DMAR: DRHD base: 0x000000fed93000 flags: 0x1
IOMMU fed93000: ver 1:0 cap c9008020630272 ecap 1000
DMAR: RMRR base: 0x000000000ed000 end: 0x000000000effff
DMAR: RMRR base: 0x000000bdc00000 end: 0x000000bfffffff
DMAR: RMRR base: 0x000000bdaf0000 end: 0x000000bdafffff
DMAR: No ATSR found
IOMMU 0xfed92000: using Register based invalidation
IOMMU 0xfed91000: using Register based invalidation
IOMMU 0xfed90000: using Register based invalidation
IOMMU 0xfed93000: using Register based invalidation
IOMMU: Setting RMRR:
IOMMU: Setting identity map for device 0000:00:1d.0 [0xbdaf0000 - 0xbdb00000]
IOMMU: Setting identity map for device 0000:00:1d.1 [0xbdaf0000 - 0xbdb00000]
IOMMU: Setting identity map for device 0000:00:1d.2 [0xbdaf0000 - 0xbdb00000]
IOMMU: Setting identity map for device 0000:00:1d.7 [0xbdaf0000 - 0xbdb00000]
IOMMU: Setting identity map for device 0000:00:1a.0 [0xbdaf0000 - 0xbdb00000]
IOMMU: Setting identity map for device 0000:00:1a.1 [0xbdaf0000 - 0xbdb00000]
IOMMU: Setting identity map for device 0000:00:1a.2 [0xbdaf0000 - 0xbdb00000]
IOMMU: Setting identity map for device 0000:00:1a.7 [0xbdaf0000 - 0xbdb00000]
IOMMU: Setting identity map for device 0000:00:02.0 [0xbdc00000 - 0xc0000000]
IOMMU: Setting identity map for device 0000:00:02.1 [0xbdc00000 - 0xc0000000]
IOMMU: Setting identity map for device 0000:00:1d.0 [0xed000 - 0xf0000]
IOMMU: Setting identity map for device 0000:00:1d.1 [0xed000 - 0xf0000]
IOMMU: Setting identity map for device 0000:00:1d.2 [0xed000 - 0xf0000]
IOMMU: Setting identity map for device 0000:00:1d.7 [0xed000 - 0xf0000]
IOMMU: Setting identity map for device 0000:00:1a.0 [0xed000 - 0xf0000]
IOMMU: Setting identity map for device 0000:00:1a.1 [0xed000 - 0xf0000]
IOMMU: Setting identity map for device 0000:00:1a.2 [0xed000 - 0xf0000]
IOMMU: Setting identity map for device 0000:00:1a.7 [0xed000 - 0xf0000]
IOMMU: Prepare 0-16MiB unity mapping for LPC
IOMMU: Setting identity map for device 0000:00:1f.0 [0x0 - 0x1000000]
DMAR:[DMA Write] Request device [00:02.0] fault addr fffff000 
DMAR:[fault reason 05] PTE Write access is not set

Puis pour être sur un petit : cat /proc/cpuinfo

root@Willbure:~# cat /proc/cpuinfo 
processor	: 0
vendor_id	: GenuineIntel
cpu family	: 6
model		: 23
model name	: Intel(R) Core(TM)2 Quad CPU    Q9400  @ 2.66GHz
stepping	: 10
cpu MHz		: 2003.000
cache size	: 3072 KB
physical id	: 0
siblings	: 4
core id		: 0
cpu cores	: 4
apicid		: 0
initial apicid	: 0
fpu		: yes
fpu_exception	: yes
cpuid level	: 13
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 xsave lahf_lm dts tpr_shadow vnmi flexpriority
bogomips	: 5332.92
clflush size	: 64
cache_alignment	: 64
address sizes	: 36 bits physical, 48 bits virtual
power management:

On retrouve bien dans les flags les instructions : vmx et smx
Mon cpu est donc bien compatible VT-x, et il est bien pris en charge par la distribution. (cool !)

Pour attribuer des ressources physiques à une VM, il faut connaitre son adressage, chose facile à faire grâce à la commande lspci :

root@Willbure:~# lspci
00:00.0 Host bridge: Intel Corporation 4 Series Chipset DRAM Controller (rev 03)
00:02.0 VGA compatible controller: Intel Corporation 4 Series Chipset Integrated Graphics Controller (rev 03)
00:02.1 Display controller: Intel Corporation 4 Series Chipset Integrated Graphics Controller (rev 03)
00:03.0 Communication controller: Intel Corporation 4 Series Chipset HECI Controller (rev 03)
00:03.2 IDE interface: Intel Corporation 4 Series Chipset PT IDER Controller (rev 03)
00:03.3 Serial controller: Intel Corporation 4 Series Chipset Serial KT Controller (rev 03)
00:19.0 Ethernet controller: Intel Corporation 82567LM-3 Gigabit Network Connection (rev 02)
00:1a.0 USB Controller: Intel Corporation 82801JD/DO (ICH10 Family) USB UHCI Controller #4 (rev 02)
00:1a.1 USB Controller: Intel Corporation 82801JD/DO (ICH10 Family) USB UHCI Controller #5 (rev 02)
00:1a.2 USB Controller: Intel Corporation 82801JD/DO (ICH10 Family) USB UHCI Controller #6 (rev 02)
00:1a.7 USB Controller: Intel Corporation 82801JD/DO (ICH10 Family) USB2 EHCI Controller #2 (rev 02)
00:1b.0 Audio device: Intel Corporation 82801JD/DO (ICH10 Family) HD Audio Controller (rev 02)
00:1c.0 PCI bridge: Intel Corporation 82801JD/DO (ICH10 Family) PCI Express Port 1 (rev 02)
00:1d.0 USB Controller: Intel Corporation 82801JD/DO (ICH10 Family) USB UHCI Controller #1 (rev 02)
00:1d.1 USB Controller: Intel Corporation 82801JD/DO (ICH10 Family) USB UHCI Controller #2 (rev 02)
00:1d.2 USB Controller: Intel Corporation 82801JD/DO (ICH10 Family) USB UHCI Controller #3 (rev 02)
00:1d.7 USB Controller: Intel Corporation 82801JD/DO (ICH10 Family) USB2 EHCI Controller #1 (rev 02)
00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev a2)
00:1f.0 ISA bridge: Intel Corporation 82801JDO (ICH10DO) LPC Interface Controller (rev 02)
00:1f.2 SATA controller: Intel Corporation 82801JD/DO (ICH10 Family) SATA AHCI Controller (rev 02)
00:1f.3 SMBus: Intel Corporation 82801JD/DO (ICH10 Family) SMBus Controller (rev 02)
01:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection
02:02.0 Ethernet controller: Intel Corporation 82546EB Gigabit Ethernet Controller (Copper) (rev 01)
02:02.1 Ethernet controller: Intel Corporation 82546EB Gigabit Ethernet Controller (Copper) (rev 01)

Moi je voulais rajouter les cartes Intel 82546EB, les IDs sont donc 02:02.0 et 02:02.1

Je modifie le fichier de conf de ma VM (qui est éteinte pour l'occasion !!) :

# nano /etc/pve/qemu-server/111.conf

ce qui donne chez moi :

boot: c
bootdisk: scsi0
cores: 1
keyboard: fr
memory: 512
name: Pfsense
net0: e1000=A2:93:78:F6:32:BC,bridge=vmbr1
ostype: l26
scsi0: local:111/vm-111-disk-1.qcow2,size=2G
sockets: 1
tablet: 0

Et sous la ligne "cores: 1", je rajoute les commandes "hostpci".

boot: c
bootdisk: scsi0
cores: 1
hostpci0: 02:02.0
hostpci1: 02:02.1
keyboard: fr
memory: 512
name: Pfsense
net0: e1000=A2:93:78:F6:32:BC,bridge=vmbr1
ostype: l26
scsi0: local:111/vm-111-disk-1.qcow2,size=2G
sockets: 1
tablet: 0

y a plus qu'à !

pour faire booter ma VM (ou depuis l'interface graphique, c'est au choix !) :

# qm start 111

Et voici un petit screenshot de ma VM, où on voit apparaitre mes deux cartes physiques (les Copper):

Comme prévu, je viens de remplacer l'ancien Planet auto-hébergement par une nouvelle version basée sur Planet Venus sur mon propre serveur.

Vous pouvez donc maintenant venir découvrir la nouvelle Planète auto-hébergement, qui propose :

• une vue Web des articles récents des blogs affiliés ;
• des flux de syndication — Atom et RSS — pour suivre les nouveautés ;
• une liste — OPML — des blogs affiliés pour les suivre individuellement.

Si vous tenez un blog ou vous parlez d'auto-hébergement, il n'est pas trop tard pour me l'indiquer !

La configuration de Planet Venus est intéressante, et il faudra sans doute que je rédige un article synthétisant mon expérience avec ce logiciel, mais j'attends d'abord que les débats actuels se calment un peu pour pouvoir finaliser un autre projet de Planète Catholique…

Voilà quelques jours que je découvre OpenWRT sur mon TP-Link TL-WR1043ND. A force de jouer, j’ai réussi à rendre injoignable mon routeur. Seule solution trouvée: me connecter en telnet et lancer une commande permettant de le réinitialiser. C’est à dire de le remettre dans le même état que juste après l’avoir flasher sous OpenWRT. On y perd donc la configuration et les paquets installés, mais on repart sur des bases saines.

C’est assez simple, mais  j’ai essayé de faire en sorte d’apporter un maximum de détails. Bonne lecture, ça se passe par là:

Réinitialiser un routeur TL-WR1043ND sous OpenWRT.

Amis auto-hébergés, cet article vous est principalement destiné et surtout si votre nom de domaine a été acheté chez Gandi. Pour les autres, l'information qui suit peut peut-être s'avérer intéressante, on ne sait jamais...

Si comme moi, votre FAI ne vous fourni malheureusement pas d'adresse IP fixe, la solution généralement utilisée afin de mettre à jour votre IP est de créer un compte chez un fournisseur tel que DynDNS ou encore No-IP qui vous propose alors de choisir un domaine dans une liste imposée (ex. : homelinux.org). Vous pourrez alors déclarer l'enregistrement d'un hôte (limité à un seul chez DynDNS) dans ce domaine et ainsi mettre à jour cet enregistrement via un outil tel que Ddclient. Vous devrez ensuite créer des alias (CNAME) sur votre propre domaine et les faire pointer vers votre enregistrement DynDNS nouvellement créé (ex. toto.homelinux.org).

Une autre solution, si vous avez la main sur les serveurs DNS qui hébergent votre domaine (il faut dans ce cas que ces serveurs aient, eux, une ip fixe), est d'utiliser cette méthode proposée par GuiguiAbloc. Je confirme que cela fonctionne très bien, je l'utilise en production au boulot.

Enfin, la solution que je vous propose maintenant ne fonctionne qu'avec les noms de domaines enregistrés et gérés chez Gandi puisqu'elle s'appuie sur leur nouvelle API. Cette API en XML RPC permet d'automatiser ce qu'il est possible de faire via l'interface d'administration grâce à des scripts. La doc officielle fourni des exemples pour les langages suivants: python, php, nodejs, perl, ruby et C.

J'ai écrit le script suivant en Python 2.x (si une version en Python 3.x vous intéresse, laissez-moi un commentaire.). Un simple interpréteur Python suffit à le faire fonctionner sur toutes les plateformes supportées par le langage. La mise en place est très simple, copiez-le où bon vous semble sur votre serveur, rendez-le exécutable et modifiez les constantes en entête de fichier pour les faire correspondre à vos besoins. Planifiez ensuite son exécution à intervalles réguliers à l'aide d'une tâche cron et c'est tout.

A noter que l'activation de l'API et la génération de la clé s'effectuent depuis l'interface Gandi la première fois, cette dernière permet de s'affranchir d'une authentification par mot de passe.

Voici donc le script commenté:

# -*- coding: UTF-8 -*-
import xmlrpclib, urllib2, time, re, sys

# API de Production
api = xmlrpclib.ServerProxy('https://rpc.gandi.net/xmlrpc/')

############ A Modifier #############

# URL de la page retournant l'ip publique
url_page = 'http://ifconfig.me/ip'

# Renseignez ici votre clef API générée depuis l'interface Gandi:
apikey = 'dshjhkqsdk566456dsjhgdj82k65hgdsuytzz'

# Domaine concerné
mydomain = 'mondomaineamoi.org'

# Enregistrement à modifier
myrecord = {'name': 'monserveur', 'type': 'A'}

# TTL
myttl = 300

# id de la zone concernée (à récupérer depuis l'interface Gandi) 
zone_id = xxxxxx

####################################

# Récupération de l'ancienne ip
oldip = api.domain.zone.record.list(apikey, zone_id, 0, myrecord)[0].get('value')

try:
    # Récupération de l'ip actuelle
    f = urllib2.urlopen(url_page, None, 10)
    data = f.read()
    f.close()
    pattern = re.compile('\d+\.\d+\.\d+\.\d+')
    result = pattern.search(data, 0)
    if result == None:
        print("Pas d'ip dans cette page.")
        sys.exit() 
    else:
        currentip = result.group(0)

    # Comparaison et mise à jour si besoin
    if oldip != currentip:
        # On cree une nouvelle version de la zone
        version = api.domain.zone.version.new(apikey, zone_id)
        # Mise a jour (suppression puis création de l'enregistrement)
        api.domain.zone.record.delete(apikey, zone_id, version, myrecord)
        myrecord['value'] = currentip
        myrecord['ttl'] = myttl
        api.domain.zone.record.add(apikey, zone_id, version, myrecord)
        # On valide les modifications sur la zone
        api.domain.zone.version.set(apikey, zone_id, version)
        api.domain.zone.set(apikey, mydomain, zone_id)
        print("Modification de l'enregistrement effectuée avec l'ip: %s" % currentip)
except urllib2.HTTPError, xmlrpclib.ProtocolError:
    print("Site indisponible.")
finally:
    sys.exit()

Vous pouvez également le télécharger en cliquant sur ce lien.

MAJ du 19/03/2012: Plusieurs personnes m'ont demandé comment retrouver l'id de zone dans l'interface Gandi, il suffit de se positionner sur le domaine de son choix, puis de cliquer sur le lien "Voir" en face de "Fichier de zone" dans la colonne "Serveur de noms". Une fenêtre s'ouvre permettant de visualiser le fichier de zone, l'id se trouve dans l'url de cette fenêtre: https://www.gandi.net/admin/domain/zone/XXXXXX/see/ (représenté par des X ici)

MAJ du 03/10/2012: Charly Caulet a fait quelques modifs en se basant sur ce script et a packagé le tout. Vous pourrez trouver tout cela sur son dépôt.

Voilà à peu près un an et demi que j'héberge ce site et d'autres services à la maison, malheureusement le Sheevaplug qui me faisait office de serveur jusque là, a rendu l'âme fin juillet. Ces petits boitiers pas plus gros qu'un transfo sont vraiment de petites merveilles et ont, en plus de leur petites dimensions, l'énorme avantage de ne consommer que 5 watts en moyenne. Le tout dans un silence total puisque sans ventilateur !

Il avait pour moi un seul petit inconvénient: le processeur, un ARM (Marvell Kirkwood 88F6281) non supporté par OpenBSD. C'est pourquoi je faisais tourner la bête sous une Debian Squeeze (distro que je n'apprécie pas particulièrement mais qui supporte très bien ce matériel).

Bref, il m'a donc fallu investir... Je souhaitais trouver un mini-pc d'architecture x86 ou compatible, fanless, aux performances correctes mais consommant surtout très peu. Je me suis alors tourné vers un boitier de marque Shuttle, le XS35v2.

Le matériel

Je vous laisse regarder le détail des spécifications techniques du bébé sur le site du constructeur mais pour résumer rapidement, c'est un petit boitier de 25.2 x 16.2 x 3.85 cm à refroidissement passif et basse-consommation, vendu sans disque dur, ni RAM mais doté:

• d'un processeur Intel Dual Core Atom D525 (64bits) à 1.8 Ghz
• une interface Ethernet gigabit + une interface wifi
• un port VGA + chipset graphique Intel GMA 3150
• sortie audio analogique + entrée micro
• 5 ports USB
• un lecteur de cartes flash SDHC, MS et MS-pro

Le constructeur annonce une consommation électrique de 16 Watts au repos et 20 Watts en forte charge (l'équivalent d'une ampoule). Je n'ai pu hélas vérifier ces chiffres par moi-même car je ne dispose pas de wattmètre mais ayant fouillé pas mal sur la toile, cela semble se confirmer.

D'autres déclinaisons de ce modèle existent avec un chipset graphique plus performant (NVIDIA ION) et une sortie HDMI mais pour un serveur ce modèle me convenait tout à fait. J'ai ajouté à cela un disque dur 2.5" Western Digital Scorpio Blue de 500 Go et une barrette de 2 Go de DDR3, sans oublier le kit de fixation VESA permettant d'accrocher le boitier derrière un écran plat.

Le tout m'est revenu à environ 240 € TTC, frais de port compris, un investissement certes, mais pas si cher que cela quand on compare au prix annoncé d'un D2Plug, le dernier né de chez Globalscale Technologies (fabricant du Sheevaplug).

Les applis

Voici donc ce qu'il fait tourner sans peine dans mon salon, sous OpenBSD évidemment ;)

• 5 sites web à faible traffic grâce à Nginx, Django le framework qui sent le poney et Gunicorn
• un serveur XMPP ultra-léger avec Prosody et un client web: Jappix
• FDM, rss2email et Dovecot pour récupérer et filtrer mes emails (et flux RSS) depuis plusieurs boites IMAP
• Unbound un serveur cache DNS récursif.
• MPD un serveur/lecteur de musique
• un service sécurisé de partage de fichiers (SFTP) grâce à OpenSSH
• un client web bittorrent simple et léger, j'ai nommé Transmission
• un serveur Mozilla Sync
• les sauvegardes sont réalisées par rsnapshot sur un disque dur USB
• un serveur de dépôts Mercurial

L'ensemble (OS compris) consomme environ 385 Mo de RAM et le processeur se la coule douce...

Bilan

Après 2 semaines de fonctionnement 24h/24 et 7j/7, j'avoue être totalement satisfait de ce nouveau petit serveur qui ne chauffe pas du tout et qui est totalement silencieux (j'entends uniquement le disque dur tourner à condition d'être dans un silence absolu). Bref, un achat que je vous recommande si vous recherchez un matériel discret pour vous initier aux joies de l'auto-hébergement.

Au passage, si vous êtes intéressés par un article sur la mise en place d'un ou plusieurs des services cités ci-dessus, n'hésitez pas à me laisser un commentaire. ;)

MAJ du 26/08/2011: Après avoir testé avec un wattmètre, je confirme que le Shuttle XS35v2 consomme bien en moyenne 16 watts.

Depuis la mise à jour en 2.3 de Proxmox, je me suis rendu compte que mes VMs sous KVM consommaient
un peu plus de ressources CPU en idle.

Après quelques recherches sur les forums de Proxmox, j'ai trouvé une astuce pour réduire cette conso :

Désactiver le support "Tablet Pointer"

Faites un hard reboot de votre VM (un simple reboot ne suffit pas !).

Et sous votre hyperviseur faites un :

# qm config VMID

afin de vérifier que le pointer est bien désactivé, chez moi ça donne :

root@Willbure:~# qm config 109
bootdisk: sata0
cores: 4
description: Windows 2008 R2
ide2: none,media=cdrom
keyboard: fr
memory: 2048
name: Minus
net1: virtio=B6:92:31:25:B6:AD,bridge=vmbr1
onboot: 1
ostype: win7
sata0: local:109/vm-109-disk-1.qcow2,size=32G
sockets: 1
tablet: 0

Après cela la conso de ma VM est passé de 15/20 % en idle à 2/3 %

C'est pas grand chose, et c'est bien mieux 

Un client pour les gourverner tous, ça en jette nan ?

Vous avez installer un serveur XMPP, mais vos amis son sur Facebook, MSN, Gtalk, Skype …
Vous vous sentez seul ?

Le XMPP, le protocole de furieux, n'a pas dit son dernier mot !

On va installer des passerelles vers les protocoles qu'utilisent vos autres contacts, et ainsi les fédérer sous le même logiciel, une gestion de groupe unifiée, avec une seule authentification…
Bref, ça semble pas trop mal

Pour ça on va installer un nouveau programme sur notre serveur XMPP (basé sur ejabberd dans notre cas, mais ça fonctionne avec d'autres !).

Ce programme c'est: Spectrum2 ⇒ http://spectrum.im

Dans ce "tuto" on va créer des passerelles pour : Facebook, MSN, et Gtalk, mais il en existe beaucoup d'autres, et c'est très simple à faire !

On commence par rajouter les sources de spectrum (afin de pouvoir l'installer par le gestionnaire de paquet) à notre source liste.

# nano /etc/apt/sources.list

Editez votre fichier et rajoutez :

deb http://repo.spectrum.im wheezy main

Et on installe :

# aptitude update
# aptitude install spectrum2 spectrum2-backend-libpurple

Après avoir installé les trouze millions de dépendances, on va aller configurer tous ça

Premièrement, préparer les fichiers de conf :

# cd /etc/spectrum2/transports
# cp spectrum.cfg.example msn.cfg
# cp spectrum.cfg.example facebook.cfg
# cp spectrum.cfg.example gtalk.cfg

On commence avec MSN ?
Alors modifiez (et adaptez selon vos besoins) votre fichier msn.cfg, de la façon suivante :

# JID of Spectrum instance.
jid = msn.sheldon.fr

# Password used to connect the XMPP server.
password = monsecret1

# XMPP server port.
port = 5347

# Libpurple protocol-id for spectrum_libpurple_backend
#protocol=prpl-jabber
protocol=prpl-msn
#protocol=prpl-icq

[identity]
# Name of Spectrum instance in service discovery
name=MSN

# Type of transport ("msn", "icq", "xmpp").
# Check http://xmpp.org/registrar/disco-categories.html#gateway
type=msn

#à rajouter à la fin du fichier
[purple]
# avatar, vcard, roster storage
# needs to be unique for each spectrum instance
userdir=/var/lib/spectrum/$jid/userdir
port=80
http_method=1

Pas trop compliqué ça va ?
Alors la suite avec Facebook :

# JID of Spectrum instance.
jid = facebook.sheldon.fr

# Password used to connect the XMPP server.
password = monsecret2

# XMPP server port.
port = 5348

# Libpurple protocol-id for spectrum_libpurple_backend
protocol=prpl-jabber
#protocol=prpl-msn
#protocol=prpl-icq

[identity]
# Name of Spectrum instance in service discovery
name=Facebook

# Type of transport ("msn", "icq", "xmpp").
# Check http://xmpp.org/registrar/disco-categories.html#gateway
type=facebook

Pour Gtalk, c'est strictement identique, on change juste les noms (et le port):

# JID of Spectrum instance.
jid = gtalk.sheldon.fr

# Password used to connect the XMPP server.
password = monsecret

# XMPP server port.
port = 5349

# Libpurple protocol-id for spectrum_libpurple_backend
protocol=prpl-jabber
#protocol=prpl-msn
#protocol=prpl-icq

[identity]
# Name of Spectrum instance in service discovery
name=Gtalk

# Type of transport ("msn", "icq", "xmpp").
# Check http://xmpp.org/registrar/disco-categories.html#gateway
type=gtalk

Maintenant que Spectrum est configuré, on va s'occuper de ejjaberd.

# nano /etc/ejabberd/ejabberd.cfg

Rajouter les éléments suivant dans la partie "Listening Ports".
Chez moi ça donne :

%%%   ===============
%%%   LISTENING PORTS

%%
%% listen: Which ports will ejabberd listen, which service handles it
%% and what options to start it with.
%%
{listen,
 [
  {5222, ejabberd_c2s, [
                        {access, c2s},
                        {shaper, c2s_shaper},
                        {max_stanza_size, 65536},
                        %%zlib,
                        starttls, {certfile, "/etc/ejabberd/ejabberd.pem"}
                       ]},


  {5269, ejabberd_s2s_in, [
                           {shaper, s2s_shaper},
                           {max_stanza_size, 131072}
                          ]},

%%Passerelle msn

{{5347, "127.0.0.1"}, ejabberd_service, [
                                        {access, all},
                                        {host, "msn.sheldon.fr", [{password, "monsecret1"}]}
                                        ]},

%%Passerelle facebook

{{5348, "127.0.0.1"}, ejabberd_service, [
                                        {access, all},
                                        {host, "facebook.sheldon.fr", [{password, "monsecret2"}]}
                                        ]},

%%Passerelle gtalk

{{5349, "127.0.0.1"}, ejabberd_service, [
                                        {access, all},
                                        {host, "gtalk.sheldon.fr", [{password, "monsecret3"}]}
                                        ]},

On démarre les services spectrum :

# spectrum2_manager start

Ce qui doit donner :

root@ovz-XMPP:~# spectrum2_manager start
Starting "/etc/spectrum2/transports/gtalk.cfg": OK
Starting "/etc/spectrum2/transports/msn.cfg": OK
Starting "/etc/spectrum2/transports/facebook.cfg": OK

Puis on redémmarre ejabberd :

# /etc/init.d/ejabberd restart

Voilà c'est fini !

Pour tester si ça fonctionne, allez sur votre client préféré (Gajim, Pidgin, Jappix …) et faites une recherche de services :

Pour moi ça fonctionne, je vois bien mes passerelles, je n'ai cas en sélectionner une, cliquer sur "Souscrire" :

Voilà à quoi ressemble mon client lorsque je me connect à mon unique compte XMPP

P.S : Si vous souhaitez essayer ce service, vous pouvez créer un compte XMPP ici : http://www.sheldon.fr/jappix/
Et par la suit utiliser le client léger à la même adresse ou un client lourd de votre choix