Planète auto-hébergement

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).

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.

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

Le PLUG, Provence Linux User Group, est une association basée à Marseille qui regroupe des passionné-e-s d’informatique et de logiciel libre, propose des échanges en ligne (mailing-lists, IRC, twitter, …) et organise une réunion mensuelle à La Bo[a]te, 35 rue de la Paix Marcel Paul,  13001 Marseille, 09 54 24 09 15. L’entrée est sur un pallier de l’escalier entre la place aux Huiles et la rue Sainte, sur la gauche en montant.

Le vendredi 5 avril 2013, à partir de 19h00, le Plug a choisi de mettre à l’honneur le Raspberry Pi.

« Venez avec le(s) vôtre(s), des cartes SD, des images de distributions, … pour tester des configurations nouvelles ou faire la démo de ce que vous en avez fait. Si vous avez des accessoires pratique ou atypiques, prenez les aussi.

Venez également pour participer au légendaire apéro, la grande session des pizzas, les rencontres et discussions über-geek, … bref tout ce qui fait la magie et la convivialité des soirées du PLUG. »

Selon la tradition de l’auberge espagnole, les participant-e-s à la réunion sont invité-e-s à apporter un petit quelque chose à boire et/ou à grignoter.

Pour promouvoir l’auto-hébergement sur Raspberry Pi, helios.im sera présent avec quelques exemplaires du serveur à tester et un diaporama succinct pour présenter le projet.

Avoir un système d'exploitation libre du noyau jusqu'aux applications c'est quelque chose dont on a pris l'habitude et plus personne ne s'en étonne. Cependant il y a quelques années ce n'était pas la même histoire. Avant que des gens inspirés aient l'idée de mettre leurs connaissances, leurs efforts et leur travail au service de la communauté il n'y avait aucun moyen de faire tourner un ordinateur avec autre chose que du code propriétaire opaque. Ainsi si vous aviez un bug, seule la société qui vous avait vendu le logiciel était à même de vous dépanner. C'est ici le point de départ du film documentaire Revolution OS.

Ce film sorti en 2001 n'a pas pris une ride. Il explique très clairement le contexte qui a amené le projet GNU, le logiciel libre et Linux sur le devant de la scène. Il pose aussi des questions qui sont toujours d'actualité, par exemple sur le modèle économique des entreprises qui font du logiciel libre. Ce film est à l'opposé de celui sur The Pirate Bay (Away from keybord). Si dans ce dernier on y voyait trois jeunes gens qui donnaient l'impression de ne pas trop savoir ce qu'ils font là, dans Revolution OS les interlocuteurs expliquent leur argumentaire de manière précise.

Je recommande vivement le visionnage de ce film à toutes les personnes qui touchent de près ou de loin au logiciel libre.

Le routeur TP-Link TL-WR1043ND est pour moi un bon produit. J’en ai d’ailleurs 2 à la maison. Il est relativement abordable puisqu’on le trouve à 50€, et bien équipé. Il possède un port USB 2.0, un switch 4 ports gigabit, le wifi N. Mais pour compléter tout ça, il faut savoir que sont chipset wifi est un atheros capable de fonctionner entre autre en mode monitor, et que le routeur est compatible avec les firmwares alternatifs comme OpenDWRT.

C’est donc bien souvent ce routeur que je conseille autour de moi. Je le considère un peu comme le WRT54G(L) actuel. Seulement voilà, les acquéreurs de ce routeur souhaitant tater d’OpenWRT mais débutants en matière d’administration réseau me font souvent la remarque à propos du fait qu’OpenWRT est en anglais. J’ai donc écrit un petit article sur la façon de mettre l’interface web en français. Si l’article est basé sur le routeur TP-Link, il evrait être appliquable à toutes les machines fonctionnant via ce firmware.

Bonne lecture, ça se passe par là:

[Wiki]Passez l’interface de votre routeur sous OpenWRT en français.

Si vous avez une IP dynamique et un nom de domaine chez Gandi.net, voici une solution pour se passer de services de DNS dynamiques tels que dyn.com ou noip.com.En effet, grâce à l'API de Gandi vous pouvez modifier votre zone DNS automatiquement. Et voici un script Python qui fait ça pour vous

Qui n'a jamais révé de briller en société avec son serveur de messagerie ?
C'est chose possible grâce au super protocole XMPP !

Qu'est ce que le XMPP ?

Sous ce bel acronyme ce cache : Extensible Messaging and Presence Protocol.
C'est donc un protocole de communication décentralisé et libre (ne dépend donc pas d'une marque, d'un seul serveur, d'une seule équipe de dev' …)
Par le biais de ce support, on peut transporter du texte, de la voie, de la vidéo … bref ça roxx du poney !
Il est utilisé par de très grands groupes sans que beaucoup d'entre nous ne le sachent (bien que parfois adapté à leurs besoins) : Google, Facebook, Apple …
(Je vous invite à consulter la page wiki du XMPP si vous cherchez plus d'infos.)

Et nous là dedans ?

On va installer notre propre serveur XMPP et rejoindre la grande famille d'internet

Pour ça on va utiliser ejabberd → http://www.ejabberd.im/
Serveur XMPP sous licence GPLv2 et compatible multi-plateforme.

Comme d'habitude, je zap la partie installation de la VM, le reste du tuto est basé sur une Debian 7.0 en testing (soyons fous, vivons dangereux !).

Pour commencer, un classique (ça mange pas de pain) :

# aptitude update && aptitude upgrade

Pensez à adapter dès maintenant votre fichier hosts (ça peut poser pas mal de problèmes inutiles par la suite).

# nano /etc/hosts

Après vient le choix de la méthode d'installation, il y a 3 solutions possibles :

1. Installation via paquet debian présent dans les dépots (actuellement en 2.1.10)
2. installation via paquet binaire précompilé (disponible sur le site en 2.1.11)
3. en compilant tout comme des barbus à partir des sources (il faudra penser à activer le support ODBC lors de la compilation)

J'aime bien compiler par moi même, mais le erlang n'est pas franchement ma tasse de thé, je vais donc choisir la solution n°1 (de toute façon on va vite devoir revenir aux sources pour compiler le connecteur MySQL).

c'est parti !!

# aptitude install ejabberd

ouf, c'est fini !!

Jusque là, ça va, maintenant, on va commencer à mettre les mains dedans !

# nano /etc/ejabberd/ejabberd.cfg

modifiez la partie :

{hosts, ["localhost"]}.

en (à vous d'adapter votre nom de domaine !) :

{hosts, ["sheldon.fr"]}.

Passons un peu ce fichier de conf (il est imbuvable hein ?), et arrêtons nous aux ACL.
Changez :

%% Admin user
{acl, admin, {user, "", "localhost"}}.

par :

%% Admin user
{acl, admin, {user, "monutilisateuradmin", "sheldon.fr"}}.

Si vous voulez vous arrêter là, et utiliser base de données interne Messina, vous n'avez qu'à créer votre utilisateur maintenant avec la commande :

# ejabberdctl register monutilisateuradmin sheldon.fr monsupermotdepasse

Mais ça serait être faible, et surtout utiliser une BDD très sensible, et pas facile à dépanner en cas de couille,
couille qui arrivera si vous modifier votre fichier hosts après avoir installé ejabberd !! (c'est du vécu !)

Vous êtes un barbus ? vous avez des couilles ?
Alors on va utiliser une BDD externe MySQL !

Je pars du principe que vous avez déjà un serveur MySQL et que vous savez vous en servir

tant que l'on a le nez dans notre fichier de conf (ejabberd.cfg), allez à la partie "Authentication", et commentez à l'aide de "%%" (et oui c'est du erlang) la ligne.
Ce qui donnera :

%%{auth_method, internal}.

Juste en dessous, cette fois décomenter, la partie ODBC (ainsi on indique à ejabberd, de ne pas utiliser ça base interne, mais une externe via connecteur ODBC).

%% Authentication using ODBC
%% Remember to setup a database in the next section.
%%
{auth_method, odbc}.

Comme nous l'indique si gentillement ejabberd, il nous faut configurer la BDD (on verra plus tard pour la remplir).
(n'oubliez pas de décommenter le début de la ligne !)

%%
%% MySQL server:
%%
{odbc_server, {mysql, "ip de mon serveur BDD", "nom BDD", "nom user BDD", "mot de passe user BDD"}}.

cette fois, c'est fini pour ce fichier de conf !
maintenant, commence les choses plus délicates, à savoir compiler le connecteur MySQL.

Commencez par installer subversion (pour récuper les fichiers sur le dépôt via svn).

# aptitude install subversion

on récupère les sources :

# cd /tmp
# svn co https://svn.process-one.net/ejabberd-modules/mysql trunk mysql

il va aussi nous falloir les sources de ejabberd (je vous avait bien dit qu'on allait y revenir )
attention à bien récuper la bonne version des sources, il faut qu'elles correspondent à la version installée par le biais des paquets debian.

# wget http://www.process-one.net/downloads/ejabberd/2.1.10/ejabberd-2.1.10.tar.gz

on décompresse dans la foulé !

# tar xvzf ejabberd-2.1.10.tar.gz

bon les commandes qui suivent sont très simples, mais faute de doc/tuto j'ai pas mal cherché pour trouver comment procéder !
On retourne dans le répertoire du connecteur MySQL, et copie les fichiers sources dans le répertoire des sources de ejabberd.
Chez moi, ça donne :

# cd /tmp/mysql/mysql/trunk/src/
# cp * /tmp/ejabberd-2.1.10/src/

Maintenant on a besoin des outils pour compiler ce fameux connecteur :

# aptitude install erlang-tools make

ready ??

# cd /tmp/ejabberd-2.1.10/src/
# erl -pz ebin -make

Logiquement, si tout à bien fonctionné, on doit avoir nos fichiers *.beam dans le répertoire "ebin".

C'est bon pour moi

Et on en fait quoi de ces fichiers ?

# cd /tmp/ejabberd-2.1.10/src/ebin/
# cp * /usr/lib/ejabberd/ebin/

Tant que l'on est dans le répertoire des sources de ejabberd, on récupère le script sql présent dans le répertoire "odbc".
Voici ce qu'il contient, vous allez devoir l'injecter dans la BDD que vous aurez créé à cet effet :

CREATE TABLE users (
    username varchar(250) PRIMARY KEY,
    password text NOT NULL,
    created_at timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP
) CHARACTER SET utf8;


CREATE TABLE last (
    username varchar(250) PRIMARY KEY,
    seconds text NOT NULL,
    state text NOT NULl
) CHARACTER SET utf8;


CREATE TABLE rosterusers (
    username varchar(250) NOT NULL,
    jid varchar(250) NOT NULL,
    nick text NOT NULL,
    subscription character(1) NOT NULL,
    ask character(1) NOT NULL,
    askmessage text NOT NULL,
    server character(1) NOT NULL,
    subscribe text NOT NULL,
    type text,
    created_at timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP
) CHARACTER SET utf8;

CREATE UNIQUE INDEX i_rosteru_user_jid ON rosterusers(username(75), jid(75));
CREATE INDEX i_rosteru_username ON rosterusers(username);
CREATE INDEX i_rosteru_jid ON rosterusers(jid);

CREATE TABLE rostergroups (
    username varchar(250) NOT NULL,
    jid varchar(250) NOT NULL,
    grp text NOT NULL
) CHARACTER SET utf8;

CREATE INDEX pk_rosterg_user_jid ON rostergroups(username(75), jid(75));


CREATE TABLE spool (
    username varchar(250) NOT NULL,
    xml text NOT NULL,
    seq BIGINT UNSIGNED NOT NULL AUTO_INCREMENT UNIQUE,
    created_at timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP
) CHARACTER SET utf8;

CREATE INDEX i_despool USING BTREE ON spool(username);


CREATE TABLE vcard (
    username varchar(250) PRIMARY KEY,
    vcard mediumtext NOT NULL,
    created_at timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP
) CHARACTER SET utf8;


CREATE TABLE vcard_search (
    username varchar(250) NOT NULL,
    lusername varchar(250) PRIMARY KEY,
    fn text NOT NULL,
    lfn varchar(250) NOT NULL,
    family text NOT NULL,
    lfamily varchar(250) NOT NULL,
    given text NOT NULL,
    lgiven varchar(250) NOT NULL,
    middle text NOT NULL,
    lmiddle varchar(250) NOT NULL,
    nickname text NOT NULL,
    lnickname varchar(250) NOT NULL,
    bday text NOT NULL,
    lbday varchar(250) NOT NULL,
    ctry text NOT NULL,
    lctry varchar(250) NOT NULL,
    locality text NOT NULL,
    llocality varchar(250) NOT NULL,
    email text NOT NULL,
    lemail varchar(250) NOT NULL,
    orgname text NOT NULL,
    lorgname varchar(250) NOT NULL,
    orgunit text NOT NULL,
    lorgunit varchar(250) NOT NULL
) CHARACTER SET utf8;

CREATE INDEX i_vcard_search_lfn       ON vcard_search(lfn);
CREATE INDEX i_vcard_search_lfamily   ON vcard_search(lfamily);
CREATE INDEX i_vcard_search_lgiven    ON vcard_search(lgiven);
CREATE INDEX i_vcard_search_lmiddle   ON vcard_search(lmiddle);
CREATE INDEX i_vcard_search_lnickname ON vcard_search(lnickname);
CREATE INDEX i_vcard_search_lbday     ON vcard_search(lbday);
CREATE INDEX i_vcard_search_lctry     ON vcard_search(lctry);
CREATE INDEX i_vcard_search_llocality ON vcard_search(llocality);
CREATE INDEX i_vcard_search_lemail    ON vcard_search(lemail);
CREATE INDEX i_vcard_search_lorgname  ON vcard_search(lorgname);
CREATE INDEX i_vcard_search_lorgunit  ON vcard_search(lorgunit);

CREATE TABLE privacy_default_list (
    username varchar(250) PRIMARY KEY,
    name varchar(250) NOT NULL
) CHARACTER SET utf8;

CREATE TABLE privacy_list (
    username varchar(250) NOT NULL,
    name varchar(250) NOT NULL,
    id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT UNIQUE,
    created_at timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP
) CHARACTER SET utf8;

CREATE INDEX i_privacy_list_username  USING BTREE ON privacy_list(username);
CREATE UNIQUE INDEX i_privacy_list_username_name USING BTREE ON privacy_list (username(75), name(75));

CREATE TABLE privacy_list_data (
    id bigint,
    t character(1) NOT NULL,
    value text NOT NULL,
    action character(1) NOT NULL,
    ord NUMERIC NOT NULL,
    match_all boolean NOT NULL,
    match_iq boolean NOT NULL,
    match_message boolean NOT NULL,
    match_presence_in boolean NOT NULL,
    match_presence_out boolean NOT NULL
) CHARACTER SET utf8;

CREATE TABLE private_storage (
    username varchar(250) NOT NULL,
    namespace varchar(250) NOT NULL,
    data text NOT NULL,
    created_at timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP
) CHARACTER SET utf8;

CREATE INDEX i_private_storage_username USING BTREE ON private_storage(username);
CREATE UNIQUE INDEX i_private_storage_username_namespace USING BTREE ON private_storage(username(75), namespace(75));

-- Not tested in mysql
CREATE TABLE roster_version (
    username varchar(250) PRIMARY KEY,
    version text NOT NULL
) CHARACTER SET utf8;

-- To update from 1.x:
-- ALTER TABLE rosterusers ADD COLUMN askmessage text AFTER ask;
-- UPDATE rosterusers SET askmessage = '';
-- ALTER TABLE rosterusers ALTER COLUMN askmessage SET NOT NULL;

CREATE TABLE pubsub_node (
  host text,
  node text,
  parent text,
  type text,
  nodeid bigint auto_increment primary key
) CHARACTER SET utf8;
CREATE INDEX i_pubsub_node_parent ON pubsub_node(parent(120));
CREATE UNIQUE INDEX i_pubsub_node_tuple ON pubsub_node(host(20), node(120));

CREATE TABLE pubsub_node_option (
  nodeid bigint,
  name text,
  val text
) CHARACTER SET utf8;
CREATE INDEX i_pubsub_node_option_nodeid ON pubsub_node_option(nodeid);
ALTER TABLE `pubsub_node_option` ADD FOREIGN KEY (`nodeid`) REFERENCES `pubsub_node` (`nodeid`) ON DELETE CASCADE;

CREATE TABLE pubsub_node_owner (
  nodeid bigint,
  owner text
) CHARACTER SET utf8;
CREATE INDEX i_pubsub_node_owner_nodeid ON pubsub_node_owner(nodeid);
ALTER TABLE `pubsub_node_owner` ADD FOREIGN KEY (`nodeid`) REFERENCES `pubsub_node` (`nodeid`) ON DELETE CASCADE;

CREATE TABLE pubsub_state (
  nodeid bigint,
  jid text,
  affiliation character(1),
  subscriptions text,
  stateid bigint auto_increment primary key
) CHARACTER SET utf8;
CREATE INDEX i_pubsub_state_jid ON pubsub_state(jid(60));
CREATE UNIQUE INDEX i_pubsub_state_tuple ON pubsub_state(nodeid, jid(60));
ALTER TABLE `pubsub_state` ADD FOREIGN KEY (`nodeid`) REFERENCES `pubsub_node` (`nodeid`) ON DELETE CASCADE;

CREATE TABLE pubsub_item (
  nodeid bigint,
  itemid text,
  publisher text,
  creation text,
  modification text,
  payload text
) CHARACTER SET utf8;
CREATE INDEX i_pubsub_item_itemid ON pubsub_item(itemid(36));
CREATE UNIQUE INDEX i_pubsub_item_tuple ON pubsub_item(nodeid, itemid(36));
ALTER TABLE `pubsub_item` ADD FOREIGN KEY (`nodeid`) REFERENCES `pubsub_node` (`nodeid`) ON DELETE CASCADE;

CREATE TABLE pubsub_subscription_opt (
  subid text,
  opt_name varchar(32),
  opt_value text
);
CREATE UNIQUE INDEX i_pubsub_subscription_opt ON pubsub_subscription_opt(subid(32), opt_name(32));

Un dernier :

# /etc/init.d/ejabberd restart

Et tout devrait fonctionner !

Si pas d'erreur, on créé notre utilisateur (même commande qu'au début du tuto), vous pourrez aller faire un petit tour dans votre BDD vérifier si l'utilsateur est bien créé 

# ejabberdctl register monutilisateuradmin sheldon.fr monsupermotdepasse

Et on va faire un petit essai à l'adresse suivante :

http://monserver:5280/admin

Et vous devriez obtenir l'interface web d'administration :

Si cela ne fonctionne pas, il vous reste à aller faire un tour dans les logs (qui se trouvent dans /var/log/ejabberd/ ),
et vérifier que vous n'avez pas zappé une partie du tuto.

Si ça fonctionne et que vous êtes satisfait, vous pouvez vous connecter avec votre client favoris (comme Gajim, Pidgin …).
Ou via un client web comme Jappix (je ferais surement un article dessus plus tard.)

enjoy

Crédit photo : Benoit Theodore

Dans l’épisode précédent, on a vu comment remplacer le coeur de réseau de notre copain FAI-du-début. Il ne reste que deux choses sur lesquelles nous n’avons pas la main :

• Le transport de nos données entre chez nous et le datacenter qui abrite notre coeur de réseau
• La sortie du tunnel L2TP qui supporte notre connexion ADSL qui se fait toujours sur le LNS du FAI copain que nous utilisons

Attardons nous sur ce second point. Le LNS est donc, comme expliqué dans un article précédent, un serveur (ou un routeur hardware si vous avez les moyens de vous en offrir un) qui concentre les terminaisons de connexions ADSL. Si vous avez l’habitude de la commande ifconfig, vous vous retrouverez, au choix, avec une interface qui concentre tout le trafic des utilisateurs ADSL, ou bien une interface par connexion distante. Pour ceux qui n’ont rien compris à la phrase précédente, vous voyez votre switch à la maison (ou bien votre box ADSL) avec plusieurs connecteur réseau derrière, eh ben le LNS c’est la même chose de l’autre coté, une connexion réseau par utilisateur ADSL connecté, à ceci prêt que ce ne sont bien entendu pas des connexions physiques mais virtuelles puisque l’ensemble du trafic arrive sur un seul câble.

Quel intérêt, me direz vous, d’avoir son propre LNS, puisqu’on en a déjà un qui fait le job ? Il y en a plein en fait. Avec votre propre LNS, vous pouvez par exemple distribuer des adresses IP privées à certaines connexions, ajouter des blocs d’adresse IP vous même sans avoir besoin d’aller parler au LNS du copain-FAI, etc.

Mais avant de mettre en route votre LNS, vous allez avoir besoin d’un radius. Il s’agit d’un logiciel plutôt idiot à qui on dit « tiens, y’a tatie Martine qui veut se connecter, elle dit que son mot de passe c’est ‘canard’, est-ce qu’elle a bon ? », et le radius de répondre « non » ou bien « oui, et tiens, tant que t’es là, tu vas lui donner telle adresse IP, tels serveurs DNS, etc. ».

On va donc installer notre LNS sur le routeur au datacenter (oui, le même que celui qui fait BGP, vous avez à peine 20 utilisateurs derrière, ça ira très bien pour commencer) et son petit copain radius et on va expliquer au premier qu’il faut aller demander au second si les gens ont le droit de se connecter.

Et là, c’est le drame. Vous avez un LNS et un radius qui discutent ensemble, mais comment faire pour que le LNS de votre copain FAI envoie les connexions qui vous concernent à votre LNS à vous et ne se les garde pas jalousement pour lui comme il le faisait jusqu’à présent ? C’est ici que je vous introduis auprès d’un nouveau terme barbarre : le realm.

C’est la seconde partie d’un login ADSL. Par exemple, chez SFR, votre login est du genre adresse_mac@neufpnp. Le realm est neufpnp. C’est lui qui va permettre à tout le réseau de transport entre chez vous et le coeur de réseau du FAI de savoir où doit aboutir votre lien ADSL. Chez FDN, les logins sont de la forme login@fdn.nerim. Le « nerim » permet à SFR ou Orange (qui assurent le début du transport) de savoir qu’il faut ensuite envoyer les données à Nerim, et le « fdn » permet à Nerim de savoir qu’il faut passer la communication à FDN.

On pourrait éventuellement utiliser quelquechose comme login@monfai.fdn.nerim, mais ça obligerait à ennuyer Nerim à chaque nouveau FAI, ce qui serait un poil enquiquinant. On va donc tricher et utiliser un bout du login comme un realm secondaire, avec un identifiant du type login%monfai@fdn.nerim. Le radius de FDN voyant arriver un login sous la forme tatiemartine%monfai va savoir qu’il ne faut pas traiter directement la demande de connexion mais aller poser la question à votre radius à vous.

Et que doit répondre votre radius ? Quelquechose qui permettra au LNS de FDN de propager la connexion de vos utilisateurs jusqu’à votre LNS.

Votre LNS à vous va, ensuite, reposer la même question à votre radius, qui, à présent, va répondre « ah oui, tatie Martine, elle a le droit, et son IP c’est 85.65.21.2″ et votre LNS va accepter la connexion de tatie Martine. Pour la petite histoire, un LNS qui ne termine pas une connexion mais ne fait que la propager à un autre, c’est un LAC (mais il n’y a pas d’eau dedans).

Je récapitule :

1. Tatie Martine allume son modem ADSL (oui, depuis le temps, elle a été couverte, et maintenant, c’est elle qui partage son ADSL avec ses voisins malchanceux)
2. Le modem initie une connexion L2TP à travers le réseau de l’opérateur de la ligne ADSL (fort probablement SFR ou Orange, donc)
3. L’infrastructure de l’opérateur reconnait la fin de l’identifiant de tatie Martine et renvoie la demande de connexion à Nerim
4. Le LAC de Nerim reconnait ‘fdn’ dans le realm et renvoie donc la connexion au LNS de FDN
5. Le LNS de FDN reconnait ‘monfai’ entre le % et l’@ de l’identifiant et va donc demander à votre radius à vous quoi faire
6. Votre radius répond, sans même vérifier que l’identifiant est bon, qu’il faut renvoyer la connexion vers votre LNS à vous
7. Le LNS de FDN se transforme en LAC et renvoie la connexion vers votre LNS à vous
8. Votre LNS redemande à votre radius ce qu’il doit faire de la demande de connexion
9. Votre radius répond que tatie Martine a bien le droit de se connecter avec le mot de passe ‘canard’ et fournit, en prime, l’adresse IP à attribuer à tatie
10. Votre LNS accueille à bras ouverts le modem ADSL de tatie Martine et l’informe de l’adresse IP qu’il conviendra d’utiliser pour communiquer avec le reste d’internet

Quand vous allez avoir un nombre important de connexions ADSL, il sera temps de redonder tout ça. Rien de bien compliqué, il faut ajouter une seconde machine avec radius et LNS dedans, et faire en sorte qu’elles utilisent une même IP pour discuter avec le LAC/radius de l’opérateur qui est en face. Si l’une des deux tombe en panne, l’autre prend le relais.

Notez enfin que tant que vous y êtes, si vous avez envie d’avoir une collecte opérateur directe, vous avez tout ce qu’il vous faut. Il suffit de négocier avec SFR ou Orange pour obtenir une porte de collecte et la brancher directement à votre couple LNS/radius. Prévoyez un petit chèque avec 5 zéros et un coût mensuel non négligeable.

Nous voilà donc arrivés au moment fatidique où il ne reste plus que la collecte ADSL à remplacer pour être 100% autonome depuis vos utilisateurs jusqu’à internet. Ça va pas être facile ni bon marché, je vous préviens. Nous y reviendrons un peu plus tard. D’ici là, le prochain article traitera un peu plus en détail du coeur de réseau et des relations de transit et de peering.

Depuis quelques temps, j'ai en tête un "projet" que j'aimerais bien mettre en place chez moi : un cloud personnel. Ayant un serveur@home avec deux disques durs (avec réplication de l'un sur l'autre), je souhaitais en faire un serveur de stockage de mes données (présentes sur plusieurs PC fixes et portables) via un logiciel de cloud. Au départ, j'ai testé Owncloud (version 5) mais je n'ai pas été convaincu donc j'ai cherché un autre logiciel. Le deuxième plus "connu" est Sparkleshare, j'ai décidé de le tester.

Voici comment j'ai installé le serveur sur une Debian Squezze et le client sur une Ubuntu 10.04 et une 12.04. Je vous donnerai ensuite mes impressions sur cette solution.

I. Serveur

Installation

Nous allons utiliser un assistant très pratique pour installer et configurer le serveur Sparkleshare. Cet assistant s'appelle dazzle. Pour l'obtenir, il suffit de lancer cette commande (en tant que root) :

curl https://raw.github.com/hbons/Dazzle/master/dazzle.sh --output /usr/bin/dazzle && chmod +x /usr/bin/dazzle

Une fois installé, vous devez utiliser la commande dazzle pour configurer le serveur :

dazzle setup

L'assistant effectuera toutes les actions nécessaires pour la mise en place de Sparkleshare :

1. Vérification de la présence de git et installation si nécessaire
2. Création d'un compte utilisateur "storage" qui sera utilisé pour utiliser Sparkleshare
3. Configuration du compte "storage" (en particulier des accès SSH, car tout se fait en SSH)
4. Rechargement du serveur SSH

Note : À ce moment, j'ai eu une erreur avec mon serveur SSH. Il refusait de redémarrer et m'affichait l'erreur suivante :

Il s'agit d'une erreur due aux lignes ajoutées par Sparkleshare à la fin du fichier /etc/ssh/sshd_config (utilisée pour l'accès SSH au compte "storage"). Après pas mal de recherches, je me suis rendu compte que l'erreur était due à la version de mon openssh-server. Sur ma Debian Squeeze, la version installée était la 5.5 (1:5.5p1-6+squeeze3). La configuration ajoutée par Sparkleshare n'est compatible qu'avec la version d'openssh-server 6.x.

Pour remédier à ce problème, j'ai dû mettre à jour mon openssh-server via les dépôts testing de Debian (ce qui a nécessité une mise à jour du paquet libc6-dev) au passage. Cela a installé la version 6 (1:6.0p1-4) d'openssh-server et cela a résolu mon problème.

Configuration

Maintenant que mon serveur est installé, j'ai créé (toujours via dazzle) un répertoire destiné à accueillir mes données à synchroniser. Pour ce faire, il faut utiliser la commande suivante :

dazzle create DOSSIER

ou en crypté :

dazzle create-encrypted DOSSIER_CRYPTE

Voici le résultat de la commande :

Creating encrypted project "DOSSIER_CRYPTE"...
  -> /usr/bin/git init --bare /home/storage/DOSSIER_CRYPTE-crypto
  -> /usr/bin/git config --file /home/storage/DOSSIER_CRYPTE-crypto/config receive.denyNonFastForwards true
  -> echo "*.DMG -delta" >> /home/storage/DOSSIER_CRYPTE-crypto/info/attributes      
  -> chown --recursive storage:storage /home/storage
  -> chmod --recursive o-rwx /home/storage/DOSSIER_CRYPTE-crypto
 
Project "DOSSIER_CRYPTE-crypto" was successfully created.
To link up a SparkleShare client, enter the following
details into the "Add Hosted Project..." dialog:
 
  Address: ssh://storage@mon_ip:mon_port
  Remote Path: /home/storage/DOSSIER_CRYPTE-crypto
 
To link up (more) computers, use the "dazzle link" command.

On voit que le dossier est créé dans le répertoire /home/storage (qui est la homedir de notre utilisateur storage).

Voila, la partie serveur est presque terminée, il faudra faire une dernière action lors de la configuration de notre client mais nous verrons cela plus bas.

II. Client

Installation

Sparkleshare n'est pas officiellement packagé pour Ubuntu dans ses versions 10.04 jusqu'à 11.10. Ceci dit, un dépôt PPA est disponible (compatible avec Ubuntu 10.04 -> 11.10). Il ne s'agit pas des dépôt officiels, aussi, installez-le en connaissance de cause. Vous devez l'ajouter et lancer l'installation grâce à ces commandes :

sudo add-apt-repository ppa:warp10/sparkleshare
sudo apt-get update
sudo apt-get install sparkleshare libwebkit1.1-cil git-core python-nautilus

Depuis la version 12.04, tout est packagé de base, donc cette commande sera suffisante :

sudo apt-get install sparkleshare libwebkit1.1-cil git-core python-nautilus

Configuration

Le premier lancement du client vous permettra de renseigner quelques informations (nom, prénom, adresse mail) et vous affichera un petit tuto. Une fois passé cette présentation, il va falloir "relier" le client avec le serveur. Pour cela, récupérez le contenu du fichier présent dans le répertoire SparkleShare de votre homedir (il s'agit de la clé publique du client). Retournez sur le serveur puis lancez la commande suivante :

dazzle link

Après avoir appuyé sur Entrée, vous n'avez plus qu'à coller la clé publique de votre client, valider une dernière fois et le tour est joué.

Dernière étape, l'ajout du nouveau dépôt (le répertoire que nous avons créé ci-dessus) sur le client. Pour cela, il suffit de cliquer sur l'icône Sparkleshare de votre zone de notification puis "Ajouter un projet hébergé" :

Choisissez ensuite "on my own server" (notez que vous pouvez vous brancher sur des serveurs git publics tels que Github) puis renseignez l'adresse de votre serveur et le répertoire de destination (il s'agit des données que vous avez eu lors de la configuration du répertoire sur le serveur) :

    Address: ssh://storage@mon_ip:mon_port
    Remote Path: /home/storage/DOSSIER_CRYPTE-crypto

Après avoir validé, vous avez accès à votre répertoire (qui sera synchronisé avec tous les clients en temps réel).

Note : Je n'ai pas testé les clients Mac et Windows mais je suppose que l'installation et surtout la configuration sont à peu près identiques.

III. Conclusion

Sparkleshare est un très bon logiciel. Les échanges sont chiffrés (via SSH), rapides, l'installation n'est pas trop difficile et c'est basé sur git. Malheureusement, le gros point noir qui est vraiment rédhibitoire pour moi c'est que je ne peux pas retrouver mes fichiers directement sur le serveur. Dans le fameux répertoire créé sur le serveur, tout est hashé, crypté, bref, complètement inutilisable :

Autrement dit, il faut obligatoirement avoir un client pour accéder aux données. Moi je voulais pouvoir avoir les données disponibles depuis les clients mais également directement sur mon serveur. Sparkleshare ne propose pas cela.

C'est la raison pour laquelle je n'irai pas plus loin dans mon utilisation de cet outil. Il faut que j'en trouve un autre. Si vous avez des idées, faites-moi signe :)

Edit : Du coup, voici ce que j'ai fait pour supprimer Sparkleshare :

userdel storage
rm -rf /home/storage/
rm /usr/bin/dazzle
#Modification du fichier /etc/ssh/sshd_config pour supprimer les liens avec /home/storage puis :
/etc/init.d/ssh reload

GIT reste installé sur le serveur mais ça c'est pas bien grave.

A la demande (pas) générale, je fais un méta-billet pour récapituler ce qui se passe dans la série »Fabriquer son internet »

Les articles écrits ont un lien, et les autres sont juste indiqués pour vous faire baver.

• Connecter tatie Martine à son ADSL à soi
• Obtenir des adresses IP à son nom
• Créer son coeur de réseau pour sortir son trafic de manière indépendante
• Gérer ses propres radius et LNS
• Routeurs, transit et peering
• Réseau d’administration et accès out of band
• Montée en débit de collecte et collectes alternatives
• Topologie wireless et recherche de points hauts
• Passage de la boucle locale en fibre
• NAT, pénurie d’IPv4 et IPv6
• Réseaux géographiquement étendus
• Pérennité et concurrence publique & privée
• Modèle associatif et usage professionnels
• Neutralité et besoins spécifiques

Les camarades de chez Ilico ont compilé avec brio quelques schémas pour pondre un truc vraiment pas mal. Ça n’illustre pas tous les points abordés dans cette série d’article, mais ça peut clarifier les idées :

Remplacement du Planet auto-hébergement

Vous connaissez peut-être le Planet auto-hébergement. Comme il ne fonctionne pas bien, je vais le remplacer par un logiciel plus simple, Planet Venus, sur mon propre serveur.

L'adresse de la planète auto-hébergement ne changera pas, mais il n'y aura plus de fioritures comme le système de vote. Ce sera également plus ouvert puisque la liste des blogs agrégés sera disponible en OPML pour ceux qui préfèrent les suivre directement.

À vos blogs !

Le Planet actuel ne permet pas de récupérer la liste des blogs agrégés. J'ai pu en récupérer une partie en regardant les articles publiés, mais il en manque, sans compter les blogs pertinents qui ne l'ont jamais rejoint.

Donc, si vous tenez un blog où vous parlez d'auto-hébergement, ou de sujets connexes comme le modèle acentré d'Internet ou le logiciel libre sur serveur, n'hésitez pas à m'indiquer l'adresse du flux correspondant à ce blog ou à une catégorie spécifique, avec si possible un logo ou votre tête détourée.

Crédit photo : clauretano

Vous avez déjà appris comment apporter votre internet à tatie Martine et vous avez une assez bonne idée de comment faire en sorte que l’adresse IP que vous lui fournissez soit à votre nom et pas à celle d’un autre FAI.

Vous êtes par contre toujours dépendant du bon vouloir d’autres personnes pour tout ce qui se trouve en dehors de chez vous jusqu’à Internet. Pour ce soir, nous allons donc nous intéresser à comment faire en sorte de maîtriser la sortie de vos connexions ADSL. Je m’excuse d’avance auprès de ma mère et de @_doudette qui ont, jusqu’ici, tout compris mais je me vois dans l’obligation d’employer des acronymes barbares comme L2TP ou LNS, et ça va pas aller en s’arrangeant, mais promis, je vais essayer de les expliquer.

Reprenons la chaîne.  Entre votre modem ADSL et le coeur de réseau du FAI (fort probablement situé à Paris ou pas loin), il y a un tas de réseaux de toutes sortes qui transportent vos données encapsulées dans un tunnel L2TP. Pour simplifier, il s’agit d’un câble réseau virtuel qui serait branché d’un côté à votre modem et de l’autre à une machine chez le FAI qu’on nomme LNS (L2TP Network Server). Ce LNS a généralement une seule et unique sortie vers l’extérieur via le réseau du FAI.

Si votre FAI est sympathique comme FDN, il est fort possible que vous puissiez venir brancher un câble sur ce LNS puis aller lui parler au creux de l’oreille pour lui dire quelque chose comme « ehhh, pssst, si tu vois passer des paquets dont l’adresse IP source fait partie de mon bloc à moi, s’il-te-plaît, fais-les sortir par le nouveau câble que je viens de te brancher aux fesses et plus par l’opérateur de mon FAI. C’est le principe du source routing, par opposition au destination routing habituel sur internet qui se formule comme « si la destination des paquets est untel, alors envoie les par tel lien ».

Nous nous retrouvons donc dans une configuration où les connexions ADSL se terminent toujours sur un équipement d’un autre FAI mais où on est en mesure de choisir par où le trafic va sortir. Si vous avez, par exemple, un bon pote qui a un réseau qui dessert le même bâtiment que le FAI que vous utilisez et qui est prêt à vous filer gratuitement ou presque de la bande passante entrante parce qu’il en a à ne plus savoir qu’en faire.

Notez que vous n’avez pas bougé d’un iota question indépendance, vu que vous avez juste fait passer votre trafic d’un opérateur à un autre. Pour aller plus loin, vous allez devoir monter votre propre opérateur. Vous allez voir, c’est pas la mer à boire.

Administrativement parlant, tout est quasi fait, il ne vous manque qu’un numéro d’AS que le LIR qui vous a donné les IP peut vous fournir (toujours pour une somme entre 50 et 100 € par ans). Vous expliquez ensuite, toujours via ce LIR, à monsieur RIPE NCC, que vos blocs d’adresses IP ne vont plus avoir pour origine le réseau de votre FAI bien aimé mais le votre (votre numéro d’AS que vous venez d’avoir, vous suivez ?).

Ensuite, techniquement, vous allez devoir investir dans une machine (ou bien en récupérer une à bon prix, disons 150/200 €) et la faire héberger au plus proche du LNS où arrivent vos connexions (on doit être entre 50 et 75 € par mois pour ça). Cette machine, elle aura trois cartes réseau :

• Une avec un câble qui ira sur le LNS où arrivent vos connexions ADSL
• Une vers un opérateur A
• Une vers un opérateur B (qui peut aussi, pourquoi pas, être un point d’échange, vous ouvrant les portes de plein d’opérateurs avec un seul lien physique)

Cette machine fera tourner un daemon BGP qui, pour simplifier, se cantonnera à dire à A et B « coucou, moi c’est AS188769 et je m’occupe des classes d’IP 75.56.214.0/24 (IPv4) et 2a01:af54::/32 (IPv6)… toute ressemblance avec des blocs existant serait fortuite). En échange, A et B répondront « coucou, moi c’est ASxxxxx, et je sais comment aller sur tout internet ». La notion de « tout internet » en BGP tient, au choix, en une ligne ou en 435905 (à l’instant ou j’écris ces lignes). Vous avez donc le choix entre la route par défaut (notée 0.0.0.0/0) ou bien l’ensemble de tous les blocs existants sur internet (qui sont donc au nombre de 435905 actuellement, chiffre variant en permanence, tenez, maintenant il y en a 435907… Et maintenant 435902) Ces variations permanentes sont la résultante d’un type comme vous, qui gère un opérateur, et qui reboot ses routeurs ou configure de nouveaux blocs quelque part sur internet.

J’aborderai un peu plus tard les conséquences du choix entre la route par défaut et l’ensemble des routes d’internet détaillées. Considérons simplement que A et B vous offrent la possibilité de joindre tout internet.

Notez que la bande passante a un prix, variant entre 10 centimes et 50 € le Mbps en fonction de l’opérateur à qui vous l’achetez, du lieu et de la quantité. Pour un petit FAI associatif qui s’adresse à des opérateurs amis sur la place parisienne, on peut raisonnablement tabler sur 6 ou 7 euro du Mbps pour un volume de 10Mbps. On peut aussi avoir beaucoup moins, voir même 0 € du Mbps, mais il est sage de prévoir ce coût dans son prévisionnel financier même si on n’a pas à le supporter. Reste à déterminer combien vont consommer les utilisateurs, et ça, c’est mission impossible tant qu’on n’a pas constaté en vrai, surtout lorsqu’on en a relativement peu. Si tatie Martine ne fait que du mail, elle ne coûtera rien, si elle tombe amoureuse des petits chats sur youtube, elle pourra représenter 2Mbps à elle toute seule sur le mois.

Vous avez acquis l’indépendance de votre connexion vers le réseau en plus de celle entre votre connexion ADSL et vos utilisateurs. En effet, si A vous fait un coup de vache ou vous envoie balader, il suffit de signer un contrat avec C qui vous apportera le même genre de prestation, de brancher le câble à votre routeur, de refaire 3/4 lignes de configuration BGP, et vous serez toujours là et redondant. Vous n’aurez pas eu à changer les IP de vos utilisateurs puisqu’elles sont à votre nom, et tout ira bien dans le meilleur des mondes.

Coté tarif, vous avez donc déboursé, toujours sur un an :

• 100 € pour avoir un numéro d’AS
• 200 € pour un serveur qui fera office de routeur
• 900 € pour le faire héberger
• 600 € de bande passante (si on imagine que vous faites 10Mbps)

Ajouté aux 1100 € annuel de l’article précédent, nous en sommes donc à 2900 € annuel. La solution est donc viable à partir de 9 utilisateurs branchés derrière votre ligne ADSL, ce qui commence à faire un peu serré, il vaut donc mieux en prendre une seconde, ce qui nous monte le total annuel, en supposant que vos utilisateurs paient eux même le matériel pour leur propre desserte, à 3000 €, ce qui tient encore avec 9 utilisateurs payant 30 euro par mois chacun.

Si vous tenez à financer le matériel des utilisateurs, toujours en prenant l’hypothèse d’un amortissement pourri sur un an, il vous faudra deux fois plus d’utilisateurs, donc plus de lignes, la solution est viable autour d’une trentaine. Il est donc vivement conseillé de faire supporter aux utilisateurs l’installation de leur équipement.

Au prochain épisode, on abordera comment prolonger plus loin vos connexions ADSL pour ne plus les faire atterrir sur le LNS du FAI mais seulement le traverser (il deviendra donc… un LAC) ou bien carrément se substituer au LNS de notre ancien FAI pour terminer soi-même les connexions directement depuis le réseau de collecte de SFR ou d’Orange (ou d’un autre…) si vous en avez les moyens financiers. On parlera aussi peut être de radius si on a le temps.

Il y a quelques temps j'avais fait quelques tests avec un collègue sur les attaques DDos.
Après plusieurs tests et quelques recherches, j'ai trouvé un début de réponse (mais juste un début hein !)

• mettre un reverse proxy sur une VM
• bien cloisonner cette VM et mettre de la QOS
• utiliser Nginx en reverse (RP)
• limiter le nombre de requêtes sur vers le serveur web derrière le RP
• modifier le fichier sysctl.conf

Je ne vais pas détailler l'installation de la VM et de nginx, il y a pour ça déjà de nombreux tutos qui seront mieux que ce que j'aurais pu écrire.

Une fois votre Reverse proxy installé, configuré, testé … et que tout va bien, on va le modifier !

Éditez votre fichier "defaut"

nano /etc/nginx/sites-enabled/default

Créez une nouvelle zone

server {
        listen   80;
        server_name     sheldon.fr;
        location / {
                limit_req zone=one burst=8;
                proxy_pass         http://192.168.0.249/;
        }
}

Lorsque l'on contact le nom de domaine : sheldon.fr, celui ci redirige vers le serveur web local 192.168.0.249 (une VM avec Apache 2).
Ce qui fait la différence, c'est la petite ligne limit_req zone=one burst=8;

Elle va limiter le nombre de requêtes envoyé au serveur web Apache2 (qui lui n'accepte que les requêtes du reverse proxy).
De cette façon il est "protégé", car notre RP sert ni plus ni moins que de fusible.

Une attaque extérieure aura beau s'acharner sur mon nom de domaine, ip, chien, grand mère …
C'est le reverse qui va tout se prendre sur les dents, et faire le tri autant qu'il pourra. Mon serveur web, restera gentiment accessible en local (ce que je souhaite), et le serveur hôte ne devrait pas trop souffrir étant donné que l'on a mis de la QoS sur la VM du RP,
afin de limiter la consommation de ressources

On peut après essayer de garder en vie le RP le plus longtemps possible, en modifiant le fichier sysctl.conf, et en rajoutant :

• net.ipv4.conf.all.rp_filter = 1 → Cela permet d'éviter le spoofing ip (on vérifie l'origine de la requête).

   

   

• net.ipv4.tcp_syncookies = 1 → Active la protection contre les cookies SYN TCP
  
  

Bon tout ça c'est dans la théorie, si une attaque a lieu avec de très nombreux clients différents, le RP ne va pas tenir, la connexion et le routeur vont faire la tronche …
Il n'existe pas de vraie parade aux grosses attaques DDos, mais cette petite astuce a permis de résister à plusieurs petites attaques utilisées pendant mes tests.
(je dormirais tranquille maintenant ^^).

Le plus important étant de bien délimiter et isoler les VMs, afin d'épargner le plus possible la machine hôte…

Crédit photo : Robert Lender

Où en étions nous à la fin de l’article précédent ? Ah oui, tatie Martine était fort contente d’avoir de l’internet avec une adresse IP rien qu’à elle au travers de votre box ADSL à vous. Vous avez peut être fait ce qu’il fallait côté administratif, à savoir créer une association (je ne vais pas vous prendre par la main là dessus, c’est pas difficile), et faire une déclaration à l’ARCEP (c’est encore plus facile, ça se passe ici). Vous en aurez besoin pour la suite.

Pour avancer vers le but final, qui, je le rappelle, est d’avoir votre petit bout d’internet à vous, il est important de saisir quelques notions de base :

• Vouloir à tout prix n’utiliser que des réseaux dont on est propriétaire est une hérésie technique et économique : on fera toujours appel, à un moment ou un autre, à un tiers pour transporter des données
• La phrase précédente n’exclut cependant pas de tenter de s’approprier un maximum de la chaîne de transmission, tant qu’il y a un sens technique et/ou économique à le faire
• Il y a toute fois une différence fondamentale entre acheter une connexion à internet chez soi et l’acheter dans le coeur du réseau puis la transporter chez soi : on gère soi même le transport (même si, au final, il passe dans les mêmes tuyaux que les données de ceux qui ne le gèrent pas)

Nous allons donc travailler ce troisième point. Remettons les choses à plat, dans l’état où nous en sommes, voici les propriétaires des liens entre tatie Martine et internet, si on suppose que vous avez fait le choix d’utiliser FDN comme FAI pour vous fournir en attendant mieux :

1. Le pont wireless entre chez elle et chez vous : vous êtes, vous ou votre association naissante, propriétaire
2. La ligne de téléphone entre chez vous et le NRA : c’est probablement Orange qui est propriétaire
3. La liaison entre le NRA et le coeur du réseau ADSL de collecte choisi : les gestionnaires sont probablement au choix Orange ou SFR. Quant aux propriétaires des réseaux, il y a de tout : des societés d’autoroutes, du RFF, des réseaux d’initiatives publiques, des réseaux opérateurs en propre…
4. La liaison entre le réseau de collecte ADSL et Nerim : c’est un vulgaire bout de fibre optique de quelques mètres dont la propriété n’a que peu d’intérêt
5. La liaison entre Nerim et FDN : idem, sauf que c’est un câble en cuivre
6. On arrive ici à un endroit intéressant, c’est précisément là que se trouve l’autre bout de votre connexion ADSL (qui a donc, comme vous le voyez, déjà traversé au moins une demi douzaine de réseau sans qu’on ne s’en rende vraiment compte)
7. De la, le trafic sort sur le réseau Gitoyen qui est l’opérateur en charge du trafic de FDN
8. Et nous nous retrouvons ensuite sur internet via les liens que Gitoyen a établis avec d’autres opérateurs

La suite logique des choses, en terme de liaison, serait de chercher à remplacer l’ADSL de monsieur Orange ou SFR, supportant la connexion vers FDN, par quelque chose sur lequel on aurait la main. Dans le vrai monde, c’est la dernière chose à laquelle on pourra toucher pour la bonne et simple raison que c’est la chose la plus chère à remplacer. Nous allons donc nous concentrer sur les points 6 et suivants qui offrent plus de souplesse et sont plus accessibles.

Pour faire vite, l’opérateur de FDN, Gitoyen, dispose d’un petit paquet d’adresses IP publiques dont il a l’usage exclusif. Il paye une cotisation de l’ordre de 2000 € par ans pour ça à un organisme portant le doux nom de RIPE NCC, qui s’occupe de la gestion des adresses IP pour l’Europe. Cette cotisation lui donne le statut de LIR (local internet registry), ce qui lui donne le droit de redistribuer tout ou partie des adresses IP qu’il a à disposition. Il en a donc délégué un morceau à FDN qui, lui-même, refile des adresses à la découpe à ses adhérents. Généralement, une adresse par adhérent, mais on peut en mettre plus sans aucun souci (chose que les gros FAI du marché ne font pas).

Le premier pas vers l’indépendance est de trouver un LIR (ça peut être Gitoyen ou un autre) pour obtenir des adresses IP au nom de votre association. Si vous avez de quoi vous offrir la cotisation annuelle pour être vous même LIR, c’est une très bonne solution, mais elle ne vous garantira pas d’obtenir des adresses IPv4 (les plus répandues actuellement, qui sont quasi épuisées). Vous pourrez, ceci-dit, obtenir des IPv6 sans souci (coucou @bortzmeyer). Si vous en êtes à cette étape et que vous cherchez un LIR pour avoir des IP, lancez moi un petit mail, je vous trouverai ça. Ça aura un coût qu’on peut actuellement estimer entre 50 et 100 € par an.

Armé de votre bloc d’adresses IP et de votre déclaration ARCEP, vous pouvez à présent tenter l’aventure de la fédération FDN. Outre le fait de faire partie d’une communauté plus que sympathique, l’adhésion à la fédération vous ouvre la possibilité d’attribuer vos propres adresses IP via les infrastructures de FDN. Le cheminement des données reste strictement identique à celui exposé ci-dessus, mais vos abonnés ont une adresse IP qui a votre association pour étiquette et non plus FDN.

Etant donné le coût de la chose, c’est une étape envisageable dès que vous aurez 2 ou 3 utilisateurs de votre solution, le bilan financier mal taillé et absolument pas optimisé étant, en gros :

• Achat du matériel nécessaire pour 3 points desservis : 450 €
• Ligne de téléphone en annuel : 192 €
• Abonnement ADSL FDN : 360 €
• Bloc d’adresses : 100 €
• Total des coûts pour un an : 1102 €
• Total des recettes pour 3 abonnés (si on suppose 30 € par mois) : 1080 €

En optimisant bien tout ça (équipements wireless mieux choisis en fonction de la topologie, abonnement FDN au tarif fédération, bloc d’IP à pas cher), on arrive à moins de 700 € de coût sur un an.

Ça n’a l’air de rien de changer l’étiquette d’une adresse IP, mais vous avez fait un grand pas vers l’indépendance. Au prochain article, on parlera de comment faire entrer et sortir le trafic de vos adhérents par autre chose que Gitoyen. C’est ce que font beaucoup des membres de la fédération en même temps qu’ils se trouvent leurs propres IP, d’ailleurs.

Pour vous faire patienter jusqu’à l’arrivée du stock de Raspberry π et l’ouverture de la boutique, je vous laisse tester l’interface web de consultation de mails Roundcube qui a été retenue pour helios.im Comme tous les logiciels installés sur helios.im, c’est un logiciel libre, c’est à dire qu’il respecte vos libertés en tant qu’utilisateur. Vos mails sont stockés en lieu sûr chez vous, mais vous pouvez les consulter via une connexion sécurisée https depuis le monde entier, sur PC ou smartphone.

Les deux comptes de test:

1. Login: test@helios.im Mot de passe: Helios13!
2. Login: toast@helios.im Mot de passe: Helios13!

Merci d’entrer toute l’adresse et pas seulement le début.

L’adresse du webmail: https://webmail.helios.im (merci d’accepter le certificat, l’alerte vient simplement du fait que le certificat a été délivré pour www.helios.im et non pour webmail.helios.im).

Vous pouvez tester  Roundcube en envoyant des messages de l’un à l’autre compte mais pas vers des adresses extérieures à helios.im (pour éviter le spam). Les attachements sont limités à 100 Ko pour les mêmes raisons. Sur votre serveur, il n’y aura aucune limitation.

En belgique, l'opérateur historique Belgacom fournit un Internet vraiment limité : IP dynamique mutualisée... Port 80, 443 fermés...

Autrement dire, impossible d'héberger un serveur internet dans ces conditions. Voici la procédure à suivre pour récupérer un vrai Internet (réseau de serveurs interconnectés et non architecture serveur-client type minitel

1ere étape : Se connecter sur le site de Belgacom grâce aux identifiants présent sur votre facture.

• Mettre le profil technique en mode "basic" pour ouvrir les ports 80, 443, etc...
• Désactiver la traduction d'IP pour avoir une vraie IP publique

Puis redémarrer la B-box

2ème étape : Nous allons exposer un ordinateur du réseau local à Internet. Cet ordinateur aura tous ses ports ouverts à l'extérieur et pourra donc communiquer librement.

Pour cela, il faut lui attribuer une IP fixe. Chaque OS a sa procédure. Voici les paramètres que vous devez mettre :

Ensuite on se connecte sur l'interface de configuration de la B-box à l'adresse : http://192.168.1.1 et on se logue grâce au numéro de série placé sous la B-box (S/N)

Puis dans l'onglet Advanced settings -> Firewall -> DMZ host, rentrez l'IP locale du PC qui sera exposé à Internet :

Cliquez sur Apply et vous devriez être bon !

Une connexion entrante depuis l'internet sur votre IP publique devrait maintenant arriver jusqu'à votre serveur. Hourra !

Crédit photo : nusepas

J’ai déjà fait une série « comment devenir son propre FAI » qui aborde, dans les grandes lignes, la théorie. Un peu de pratique à présent.

Par les temps qui courent, maîtriser son petit bout d’internet, ça va juste devenir indispensable. Mais avant d’avoir un réseau national avec plein de gens dessus, il y a quelques étapes à franchir. Je vous propose donc de commencer petit : vous avez une connexion ADSL à peu près correcte mais tatie Martine qui habite le bourg voisin, elle, au mieux elle a 512Kbps, et encore, quand le vent souffle dans le bon sens.

Prérequis à notre petit FAI naissant, qu’on puisse voir un bout du toit de la maison de tatie Martine depuis notre propre toit. Si ce n’est pas le cas, il faudra aller chez tatie Martine et essayer de trouver un endroit visible où on sait que l’ADSL marche à peu près bien et où on a un bon ami prêt à aider tatie Martine. Pour ça, on a, par exemple, l’outil magique de Heywhatsthat qui permet de connaitre les endroits théoriquement à vue d’un point défini.

Bien, nous avons donc un point A avec de l’internet qui marche et un point B avec de l’internet ravitaillé par les corbeaux. Ces deux points sont, pour notre exemple, distant de 15km, ce qui doit, à peu de choses près, être le cas de 99.9% des maisons en France vis à vis d’un endroit où l’ADSL marche.

Premier challenge : relier le point A et le point B. Pour ça, il vous faudra un peu d’argent, quelque chose comme 150 €. Vous achetez deux NanoBridge M5 de chez Ubiquiti. Vous configurez le premier (rien de bien sorcier) en point d’accès avec chiffrement WPA2, vous lui collez une IP (par exemple 192.168.0.2), puis vous prenez le second, vous le configurez en station du point d’accès et lui collez une IP (par exemple 192.168.0.3). Vous branchez le premier à votre modem ADSL, le second à votre PC, vous les mettez en face et vous verrez que vous avez de l’internet sur votre PC.

Un peu de sport à présent, vous montez la première antenne sur votre toit, par exemple accroché à la place de votre râteau boitâkon, et vous faites la même chose chez tatie Martine en prenant soin d’essayer à peu près de mettre les antennes en face. Une page de l’outil de configuration vous aidera à faire l’alignement. Le plus difficile étant probablement de ramener le câble ethernet à l’intérieur des deux maisons. Notez que si tatie Martine est un peu fashion et n’a que des périphériques wifi, vous pouvez planquer un point d’accès wifi standard dans son grenier juste à coté de l’antenne du toit et c’est fini.

Vous avez fait le plus difficile côté physique. Bravo. Tatie Martine a de l’internet chez elle.

Par contre, si tatie Martine va sur bittorent pour partager Rihanna ou bien diffuse des photos de son patron déguisé en marsupilami, c’est vous qui irez (ou pas) voir le juge. Et puis c’est pas très neutre, ce serait bien que tatie Martine ai son adresse IP à elle pour par exemple monter un node de darknet ou héberger elle-même son blog de recettes de cuisine.

Pour faire propre, vous allez devoir investir encore un peu, par exemple dans un routeur wifi TPLink à 25 € si tatie Martine ne maîtrise pas toute la subtilité de quoi faire d’une IP routable. Il faudra ensuite vous débarrasser de votre FAI mainstream-boitâkon-téléfon-bidule  pour choisir un FAI qui saura vous fournir plusieurs adresses IP (au hasard, n’importe quel membre de la FFDN). Vous installez le TPLink chez tatie Martine et lui affectez l’une des adresse IP publique que le FAI vous aura fourni et vous vous gardez les autres pour vous (ou bien pour tonton Jean-Claude).

Il ne vous reste que la paperasserie administrative pour être tout à fait en règle : création d’une association avec tatie Martine, ouverture d’un compte en banque, déclaration L33 auprès de l’ARCEP, et voilà. Notez que cette étape est surtout utile si vous comptez réitérer l’opération avec quelqu’un d’autre que tatie Martine. Si vous restez en famille, vous vous en passerez fort bien.

Vous n’êtes pas encore vraiment un FAI indépendant puisque vous dépendez d’un autre qui vous ramène ses IP à lui, mais vous avez fait le premier pas : vous avez un réseau entre deux points géographiques distants, il est à vous et rien qu’à vous et vous l’avez connecté au reste du monde via un lien neutre.

Dans le prochain épisode, je vous expliquerai comment faire évoluer votre petit FAI pour distribuer vos propres adresses IP.

Si vous avez des questions, n’hésitez pas. Si vous voulez vous lancer, n’hésitez pas. Si vous voulez me lancer des cailloux, hésitez, on sait jamais.