Unhosted

Aventures Unhosted

Une traduction approximative du Journal de bord officiel du No Cookie Crew

d’après Unhosted Adventures
by Michiel B. de Jong

3. Configuration de votre serveur personnel

Pourquoi avez-vous besoin d’un serveur

La semaine dernière, nous avons créé un éditeur javascript/html/markdown Unhosted qui peut fonctionner depuis l’url d’un fichier, créer d’autres fichiers d’applications via des urls, charger des fichiers via le système de fichiers local, et les enregistrer à nouveau (certes, un peu maladroitement…). Cependant ce n’est pas suffisant pour nous permettre de communiquer avec d’autres appareils, ni avec d’autres utilisateurs, sans parler du “web 2.0”. Par exemple, nous voulons envoyer et recevoir des e-mails et des messages de chat, et pour faire ce genre de choses avec une application web Unhosted, nous allons avoir besoin d’une sorte de serveur proxy.

Il existe trois restrictions importantes pour les applications web Unhosted par rapport aux applications web hébergées :

Pour ces raisons, vous ne pouvez pas contrôler votre vie en ligne à partir d’applications Web Unhosted seules. Vous aurez besoin d’un serveur web personnel. Pour lancer votre propre serveur web personnel, vous allez d’abord avoir besoin de vous procurer quatre éléments :

Allons donc faire notre marché

Le VPS est l’investissement le plus onéreux, à partir de 12 €uros par mois chez Gandi par exemple (regarder tout de même leur solution Simple Hosting qui propose une offre de PAAS à partir de 4 €uros…). Le nom de domaine vous coûtera environ 12 € par an environ, toujours en prenant exemple chez Gandi, pour le certificat TLS vous pouvez l’obtenir gratuitement chez StartCom, ou pour un faible coût auprès d’autres fournisseurs. En théorie, vous pouvez configurer manuellement vos DNS depuis votre VPS, mais généralement l’enregistrement de votre nom de domaine comprend la gestion complète et gratuite de vos DNS.

Sauf si vous avez déjà un nom de domaine, vous allez alors devoir faire un choix important, à savoir le choix du nom de domaine qui va devenir votre identité personnelle sur le web. La plupart du temps, les gens utilise la même identité à travers les différents univers du web 2.0, par exemple, j’utilise souvent “michielbdejong”. Quand j’ai décidé, il y a quelques mois déjà, qu’il était temps pour moi de créer ma propre présence indépendante sur le web, et que je suis parti à la recherche d’un nom de domaine, “michielbdejong.com” était encore libre, c’est donc celui-ci que j’ai choisi. De même, vous trouverez probablement un nom de domaine qui sera en quelque sorte lié à l’un des noms d’utilisateur que vous utilisez déjà ailleurs.

J’ai enregistré mon certificat TLS pour “apps.michielbdejong.com” parce que je souhaite proposer un état des lieux des applications Unhosted existantes à ce jour, mais vous pouvez également opter pour le “www.” ou “blog.” ou n’importe quel autre sous-domaine sortie de votre imagination. Dans tous les cas, vous obtenez un sous-domaine ainsi que le domaine racine gratuitement, mais également autant d’autres adresses étendues que vous le souhaitez avec les autres ports que le 443. La création de sous-domaine n’est donc pas sans limite, mais vous pouvez toujours héberger vos différents types de contenus dans autant de sous-répertoires que vous le souhaitez (comme ce blog par exemple qui est hébergé dans le sous-répertoire /aventures sur le domaine racine de unhosted.org), et vous pouvez créer une adresse https://michielbdejong.com:10001/ comme instance javascript isolée fonctionnant sur la même adresse IP et le même certificat SSL.

No Cookie Crew - Avertissement n°1 : Le tutoriel de la semaine dernière pourrait être entièrement suivie avec les cookies désactivés. Je suis probablement la seule personne dans le monde qui a encore tous ses cookies désactivés. Donc, dans le cas ou certain(e)s des lecteurs/lectrices de ce blog souhaiteraient rejoindre le No Cookie Crew, je vais maintenant préciser clairement lorsque certaines exceptions sont nécessaires. Bien que Rackspace fonctionne sans cookies (avec l’URL de base de sessions sur https), StartCom utilise des certificats côté client pour leur assistant.D’autres services sont également susceptibles de vous obliger à ajouter leur cookies à votre liste blanche. Maintenant donc, vous allez avoir besoin d’acquérir trois produits qui vont nécessiter l’ajour des cookies de leur service d’application e-commercxe à votre liste-blanche, mais aussi ceux correspondant au panneau de contrôle des applications hébergées par chacun de leur fournisseur. Ces exceptions ne sont pas en soi une infraction, mais vous allez aussi avoir probablement besoin d’utiliser un ordinateur de bureau ou bien des applications hébergées pour validez votre adresse e-mail lors de votre inscription, et vous allez avoir besoin d’un client ssh et scp pour les prochaines étapes.

Première manche

Une fois votre serveur opérationnel, dirigez votre nom de domaine dessus, et téléchargez y votre certificat TLS. La première chose que vous voulez toujours faire quand vous vous connectez à votre nouveau serveur via ssh, c’est de le mettre à jour. Sur Debian cela se fait en tapant :

apt-get update
apt-get upgrade

Il existe différentes instances de serveur, mais ici nous allons utiliser nodejs, d’une, parce que c’est amusant et de deux, parce que c’est puissant. Pour procéder à son installation sur votre serveur, le plus simple est de suivre les instructions proposées sur le site nodejs. Par défaut, Nodejs est livré avec le “nœud” ou module vous permetant de faire fonctionner des programmes javascript, ainsi qu’avec le gestionnaire de paquet “npm”, qui lui vous donne accès à un univers de bibliothèques intéressantes et de très haute qualités.

Votre serveur web

Une fois votre serveur node opérationnel, n’hésitez pas à utiliser l’exemple proposé dans la documentation de nodejitsu pour mettre en place votre site web, l’adaptation ci-dessous vous permet d’y accéder depuis https :

var static = require('node-static'),
    http = require('http'),
    https = require('https'),
    fs = require('fs'),
    config = {
      contentDir: '/var/www',
      tlsDir: '/root/tls'
    };

http.createServer(function(req, res) {
  var domain = req.headers.host;
  req.on('end', function() {
    res.writeHead(302, {
      Location: 'https://'+domain+'/'+req.url.substring(1),
        'Access-Control-Allow-Origin': '*'
      });
    res.end('Location: https://'+domain+'/'+req.url.substring(1));
  });
}).listen(80);

var file = new(static.Server)(config.contentDir, {
  headers: {
    'Access-Control-Allow-Origin': '*'
  }
});

https.createServer({
  key: fs.readFileSync(config.tlsDir+'/tls.key'),
  cert: fs.readFileSync(config.tlsDir+'/tls.cert'),
  ca: fs.readFileSync(config.tlsDir+'/ca.pem')
}, function(req, res) {
  file.serve(req, res);
}).listen(443);

Ici, tls.key et tls.cert correspondent aux informations secrètes et publiques de votre certificat TLS, et la ca.pem est une chaîne de certificat supplémentaire fourni par StartCom dont vous aurez besoin si vous utilisez un certificat de chez StartCom.

Notez que nous avons également mis en place un site web http, qui redirige vers votre site web https, et nous avons ajouté à l’ensemble l’entête CORS, de manière à contribuer nous aussi à l’esprit du “Web ouvert“.

En utilisant “forever” pour démarrer et arrêter les processus serveur

Maintenant que vous avez dans votre script, un serveur http et un serveur https, téléchargez le fichier sur votre serveur, puis exécutez:

npm install  node-static
npm install -g forever
forever start path/to/myWebServer.js
forever list

Si tout va bien, vous avez maintenant un nouveau fichier de log dans ~/.forever/. Dans le cas ou il serait trop volumineux, vous pouvez, à l’aide de echo > ~/.forever/abcd.log, découper ce fichier de log “forever” pour n’obtenir que la partie “abcd” du processus.

N’hésitez pas à tester si votre serveur HTTP redirige bien vers votre site web https, et ajoutez y des informations de base, ou bien copiez et collez y le contenu d’une page d’un de vos site web 2.0 existants.

Le partage de fichiers

Un avantage lorsque vous avez votre propre site web avec une prise en charge du protocole TLS est que vous pouvez alors y héberger les fichiers pour d’autres personnes, et tant que votre serveur Web ne propose pas de moyen pour trouver ces fichiers sans en connaître leur URL, seules les personnes connaissant (ou étant capable de deviner) les lien vers ces fichiers, et les personnes ayant accès à votre serveur, seront en mesure de récupérer les-dits fichiers. Cela inclut nécessairement les employés du fournisseur qui héberge votre serveur VPS, ainsi que les employés des gouvernements exercant un pouvoir sur le-dit fournisseur.

En théorie, les employés du fournisseur de certificats TLS peuvent également y avoir accès si ils ont la possibilité d’écouter votre trafic TCP ou de celui qui récupère un fichier, ou encore si ils parviennent à infecter les DNS de votre nom de domaine, mais tous ces scénarios ne sont pas très courants. Dans tous les cas, si vous faites confiance au fournisseur qui héberge votre VPS et au gouvernement du pays ou se trouve celui-ci, ou bien encore si vous hébergez vous même votre serveur, et que vous êtes capable de générer des URL sécurisées, alors votre serveur peut devenir un bien bel outil pour envoyer des fichiers à d’autres personnes. Et si vous êtes capable de le mettre en œuvre sans bugs, ce moyen est alors plus sécurisé, par exemple, que l’envoi d’e-mail non-crypté.

En outre, vous pouvez confier l’envoi des fichiers à d’autres personnes, il suffit pour cela de lancer sur votre serveur un script tel que celui proposé ci-dessous :

var https = require('https'),
    fs = require('fs'),
    config = {
      tlsDir: '/root/tls',
      uploadDir: '/root/uploads',
      port: 3000
    },
    formidable = require('formidable'),
    

https.createServer({
  key: fs.readFileSync(config.tlsDir+'/tls.key'),
  cert: fs.readFileSync(config.tlsDir+'/tls.cert'),
  ca: fs.readFileSync(config.tlsDir+'/ca.pem')
}, function(req, res) {
  var form = new formidable.IncomingForm();
  form.uploadDir = config.uploadDir;
  form.parse(req, function(err, fields, files) {
    res.writeHead(200, {'content-type': 'text/plain'});
    res.end('upload received, thank you!\n');
  });
}).listen(config.port);

et permettre ainsi aux gens de poster des fichiers avec un formulaire HTML comme celui-ci:

<form action="https://example.com:3000/" enctype="multipart/form-data" method="post">
  <input type="file" name="datafile" size="40">
  <input type="submit" value="Send">
</form>

Web Indépendant

Si vous avez suivi la totalité de cet épisode, alors vous aurez peut-être dépensé 10 ou 20 €uros, et probablement passé une journée de travail pour comprendre la manière dont tous ces éléments s’assemblent et pour les faire fonctionner, mais vous aurez fait alors un pas de géant pour libéré vos outils technologiques : vous êtes maintenant un membre du “Web Indépendant” - petit groupe encore modeste des personnes qui administrent eux-mêmes leur propre serveur, indépendamment de toutes les grosses plateformes. Cela pourrait s’apparenter aux musiciens publiant leurs propres vinyles sur des petits labels indépendants. :) Et c’est certainement quelque chose dont vous pouvez être fiers. Tout cela étant installé et fonctionnel, n’hésitez pas à ajouter quelques petites pages sympathiques à votre site Web en téléchargeant tout simplement des fichiers html sur votre serveur.

A partir de maintenant vous allez avoir besoin de votre serveur personnel pour à peu près tous les épisodes à venir. La semaine prochaine par exemple, nous allons explorer une jeune mais très puissante technologie Web, qui constituera une base importante pour toutes les communications entre votre serveur personnel et les applications web Unhosted que vous allez développées : WebSockets. Et la semaine suivante, nous relierons votre serveur Web indépendant à vos comptes Facebook et Twitter… excitant! :) Restez à l’écoute, suivez-nous, et faites passer le mot* : atom, liste de diffusion, canal IRC, twitter, facebook

Commentaires bienvenus!

Suivant : WebSockets