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

6. Le contrôle de votre serveur via un WebSocket

_No Cookie Crew - Avertissement n°4 : Ce tutoriel est le dernier de la série ou vous allez encore avoir besoin de mettre à jour votre serveur personnel en utilisant un client ssh/scp.

Web shell

Les applications web Unhosted sont encore une technologie très nouvelle. Cela signifie qu'en tant que membre du No Cookie Crew, vous êtes autant mécanicien que conducteur. Vous vous retrouverez souvent à utiliser des applications web Unhosted avec la console web ouverte dans votre navigateur, de manière à pouvoir inspecter les variables et les résultats des commandes javascript pour lesquelles il n'existe aucune option. Ceci est également vrai pour les services que vous exécutez sur votre serveur de données personnel.

Jusqu'à présent, nous avons déjà installé nodejs, “forever”, un serveur web avec le support TSL, ainsi que des passerelles vers Twitter et Facebook. Et alors que nous progressons, même si nous cherchons à maintenir le serveur personnel aussi minimal et générique que possible, plusieurs autres morceaux de logiciels et de services vont devoir être ajoutés à cette liste. Pour installer, configurer, maintenir, et (“last but not least”) développer ces services, vous allez avoir besoin d'un moyen pour exécuter des commandes sur votre serveur personnel.

Dans la pratique, il s'est même révélé utile d'exécuter un second serveur personnel au sein de votre réseau local, par exemple sur votre ordinateur portable, auquel vous pouvez ensuite accéder à partir du même périphérique ou à partir d'un smartphone, au sein du même réseau wifi. Même si celui-ci ne peut pas remplacer la face visible de votre serveur personnel, du fait qu'il ne soit pas toujours allumé, il peut tout de même remplir certaines tâches, comme par exemple diffuser de la musique en streaming, ce qui s'avère plutôt pratique. Nous aborderons plus en détails ce sujet dans les prochains billets, mais pour l'instant, admettons que vous choisissez d'exécuter deux serveurs personnels, alors bien sûr vous allez avoir besoin d'un accès "web shell" pour ces deux instances, afin de les administrer efficacement depuis votre navigateur.

Il existe plusieurs bons logiciels disponibles que vous pouvez héberger sur votre serveur pour profiter d'une interface “web shell”. Celui que je peux vous recommander est GateOne. Si vous l'installez depuis Ubuntu, assurez-vous d'installer “dtach” à l'aide de apt-get install dtach, sinon l'écran de connexion se bloque à plusieurs reprises. Mais à part ça, je l'ai utilisé comme alternative à la console de mon ordinateur portable (Ctrl-Shift-F1), avec de bons résultats jusqu'à ce jour.

Le service GateOne n'est pas à proprement parlé un vrai webshell pour le serveur sur lequel il fonctionne, mais plutôt un client ssh qui vous permet de vous connecter sur ce même (ou un autre) serveur. Cela signifie que vous devez également exécuter ssh-server, alors assurez-vous que tous les utilisateurs de celui-ci ont les bons mots de passe.

Clients shell Unhosted

Vous pouvez héberger des logiciels web shell comme celui-ci sur votre serveur(s), mais cela signifie que l'application que vous utilisez (la page Web dans laquelle vous tapez vos commandes shell interactives) est choisie et déterminée au moment de l'installation. Cela pourrait être OK pour vous si vous installez votre serveur personnel vous-même et si vous êtes content de l'application que vous avez choisie, mais il existe une restriction sur le choix de l'application si cette décision a été prise par le fournisseur de l'hébergement où vous avez installé votre serveur. Ce problème peut être résolu en utilisant un client shell unhosted en lieu et place d'une solution hébergée. Le principe de séparation des applications web Unhosted depuis des passerelles et des services minimaux côté serveur est bien sûr le sujet principal de cette série de billets, alors allons-y et essayons de l'appliquer ici même.

Le chemin le plus court pour mettre en œuvre un service de commande shell serait par exemple d'ouvrir un websocket sur le serveur, et d'exécuter les commandes qui lui sont envoyés sous formes de chaînes. Vous pouvez mettre ce WebSocket sur une URL “hard-to-guess”, de sorte que n'importe qui ne pourra accéder à votre serveur sans votre permission.

Une application web unhosted pourrait alors fournir une interface pour taper et envoyer une commande, un peu dans la même veine que celle que le tableau de bord social que nous avons construit la semaine dernière.

Mais il existe deux choses dans cette proposition que nous pouvons améliorer. Tout d'abord, nous devons documenter le “wire protocol”, à savoir le format exact des messages que l'application web unhosted envoie au WebSocket, et de ceux qui reviennent dans la réponse de retour. Et ensuite, si nous ouvrons une nouveau WebSocket pour chacun des services que nous ajouterons à notre serveur personnel, cela pourra vite devenir très compliqué. Il serait plus agréable d'avoir une seule interface claire pouvant accepter différents types de commandes, et qui les expédie à l'une ou l'autre (et même plusieurs) des fonctionnalités qui s'exécutent sur le serveur.

Sockethub à la rescousse

Nick Jennings, qui était aussi à la non-conférence Unhosted 2012, et qui est maintenant aussi ici à Hacker Beach, a récemment reçu un financement NLnet pour démarrer un projet appelé Sockethub. Il s'agit d'un programme de redistribution basée sur nodejs qui répond exactement à ça : une interface WebSocket qui permet aux applications web Unhosted de discuter avec votre serveur. Mais aussi, et par le biais de votre serveur, elles peuvent également communiquer efficacement avec le reste du monde, et ce quelque soit leur rôle d'émetteur ou de récepteur.

Jetons donc un œil pour voir comment cela pourrait fonctionner. Le format de commande Sockethub est vaguement basé sur ActivityStreams. À cet égard, il est très similaire au nouveau projet d'Evan Prodromou, pump.io. Une commande Sockethub requière trois champs : rid, platform, et verb. Puisque plusieurs commandes peuvent être en circulation en même temps, le champ rid (identifiant de requête) permet de savoir que telle réponse arrivant au serveur est la réponse à telle commande parmi celles qui ont été envoyées. Le champ platform détermine quel module se chargera de la demande. Du coup, il est facile d'écrire des modules pour Sockethub au moins aussi simplement que d'écrire un plugin. Et enfin, le champ verb détermine parmi les autres champs lesquels sont obligatoires ou facultatifs. Certains verbs ne peuvent exister que pour une platform particulière, mais d'autres, comme “post”, peuvent faire sens pour plusieurs platforms, ainsi leur format n'est défini qu'une seule fois, de manière indépendante à la platform lorsque cela est possible.

Pour exécuter des commandes shell, nous allons définir un “shell” platform qui va soumettre un “execute” verb. Pour faire cela dans Sockethub il nous suffit d'ajouter un fichier appelé shell.js dans le répertoire lib/protocols/sockethub/platforms/ de Sockethub, avec le contenu suivant :

var https = require('https'),
    exec = require('child_process').exec;

module.exports = {
  execute: function(job, session) {
    exec(job.object, function(err, stdout, stderr) {
      session.send({
        rid: job.rid,
        result: (err?'error':'completed'),
        stdout: stdout,
        stderr: stderr
      });
    });
  }
};

Nous allons avoir besoin d'ajouter aussi un “shell” pour la variable PLATFORMS dans config.js, ajouter le “execute” verb et le “shell” platform dans lib/protocols/sockethub/protocol.js, et ajouter le “execute” command dans lib/protocols/sockethub/schema_commands.js avec une propriété de chaîne requise pour la commande shell effective que nous voulons avoir à exécuter. Nous appellerons ce paramètre “object”, conformément aux usages d'ActivityStreams :

  ...
  "execute" : {
    "title": "execute",
    "type": "object",
    "properties": {
      "object": {
        "type": "string",
        "required" : true
      }
    }
  },
  ...

Conclusion

Sockethub n'existe en tant que projet que depuis une semaine, mais il promet d'être une base très utile pour la plupart des fonctionnalités des passerelles que nous allons vouloir ouvrir avec nos applications web Unhosted, comme par exemple, pour l'accès au courriel, aux plates-formes de réseaux sociaux, aux fils d'actualités, à bittorrent , et toutes autres plateformes qui utilisent des APIs serveur-à-serveur, mais qui ne sont pas directement accessibles aux applications Web Unhosted par le biais d'une interface centrale publique.

Notamment, la combinaison de Sockethub avec RemoteStorage et un environnement d'exécution web comme Firefox OS par exemple qui ressemble à une plate-forme d'applications complète très prometteuse. Plus d'infos la semaine prochaine !

Commentaires bienvenus!

Suivant: Ajout de stockage distant aux applications Web Unhosted_…