Journal Installer un serveur Firefox Accounts et Firefox Sync

Posté par  . Licence CC By‑SA.
Étiquettes :
35
22
fév.
2016

Sommaire

Depuis longtemps Firefox, comme d'autres navigateurs, permet de stocker ses données dans le Cloud pour pouvoir les sauvegarder et facilement les partager entre plusieurs instances du navigateur. Et en plus, on peut l'auto-héberger ! Suivez le guide.

Pré-requis globaux

On va partir du principe qu'on veut un backend sous MySQL.

Je recommande de tout mettre dans /opt, mais vous êtes libres de faire comme bon vous semble.

L'ensemble préfère naturellement les connexions chiffrées. Équipez-vous donc de certificats (personnellement, j'opte pour un par serveur accessible de l'extérieur), faut de quoi votre serveur de synchronisation ne fonctionnera pas correctement.

Backend MySQL

On récupère les sources:

git clone https://github.com/mozilla/fxa-auth-db-mysql.git
cd fxa-auth-db-mysql
npm install

On créé le fichier de configuration:

nano config/prod.json

{
    "master": {
        "host": "127.0.0.1",
        "user": "root",
        "password": "",
        "database": "fxaccounts"
    },
    "slave": {
        "host": "127.0.0.1",
        "user": "root",
        "password": "",
        "database": "fxaccounts"
    }
}

Notez que comme fxa-auth-server et fxa-content-server que nous verrons plus loin, fxa-auth-db-mysql fait appel à convict pour la gestion de la configuration. Si vous avez besoin d'autres paramètres de configuration que ceux que nous venons de créer, regardez le fichier config/config.js, et modifiez le fichier config/prod.json en conséquence.

Notez également que la base de données n'a pas besoin d'être créée à l'avance.

Vous pouvez ensuite démarrer le serveur et vous assurer que tout va bien:

npm start

fxa-auth-server

cd /opt
git clone https://github.com/mozilla/fxa-auth-server.git
cd fxa-auth-server
npm install

Lancez une première fois le serveur pour générer les clés de chiffrement:

npm start

Vous devriez voir la sortie suivante:

> npm start

> fxa-auth-server@1.56.0 start /opt/fxa-auth-server
> NODE_ENV=dev scripts/start-local.sh 2>&1

Generating keypair
Secret Key saved: /opt/fxa-auth-server/config/secret-key.json
Public Key saved: /opt/fxa-auth-server/config/public-key.json
fxa-auth-server.INFO: [...]

Arrêtez ensuite le serveur en faisant Control + C

Modifiez le fichier de configuration:

nano .env.dev

PUBLIC_URL=https://ffaccounts.example.org
IP_ADDRESS=0.0.0.0
CONTENT_SERVER_URL=https://ffcontent.example.org
[...]
USE_TLS=true
TLS_KEY_PATH=/etc/ssl/private/ffaccounts.key
TLS_CERT_PATH=/etc/ssl/private/ffaccounts.crt

Dans le cas présent, remplacez les domaines par les vôtres. Notez que l'on va reverse-proxyfier tout ça, donc dans votre serveur web préféré, il faudra configurer un reverse proxy pour ffaccounts.example.org pointant sur l'adresse de votre serveur (127.0.0.1 si le serveur web et le serveur de comptes firefox sont sur la même machine) et sur le port 9000.

De même, le reverse proxy de ffcontent.example.org pointera sur le serveur de contenu (voir plus bas) sur le port 3030.

Démarrez le serveur afin de vous assurer que tout va bien:

npm start

Vous devriez voir un bloc JSON avec votre configuration.

fxa-content-server

cd /opt
git clone https://github.com/mozilla/fxa-content-server.git
cd fxa-content-server
npm install

Si vous installez fxa-content-server en tant que root, entrez la commande suivante:

bower --allow-root update --config.interactive=false -s

Si vous ne l'installez pas en tant que root:

npm postinstall

Lancez le serveur:

npm start

Ce qui aura pour effet de créer le fichier server/config/local.json.

Il se peut que cette commande s'arrête brusquement:

fxa-content-server.CRITICAL: uncaughtException Error: ENOENT: no such file or directory, open '/opt/fxa-content-server/node_modules/express-able/node_modules/able/bundle.js'

Lancez la commande suivante pour corriger le problème:

cd /opt/fxa-content-server/node_modules/express-able/node_modules/able/
npm run bundle

Puis, relancez le serveur:

cd /opt/fxa-content-server
npm start

Cette fois, il ne devrait plus y avoir d'erreur. Arrêtez le serveur avec Control + C, il faut maintenant le configurer.

nano server/config/local.json

{
  "public_url": "https://ffcontent.example.org",
  "fxaccount_url": "https://ffaccounts.example.org",
  "oauth_client_id": "98e6508e88680e1a",
  "oauth_url": "http://127.0.0.1:9010",
  "profile_url": "http://127.0.0.1:1111",
  "profile_images_url": "http://127.0.0.1:1112",
  "client_sessions": {
    "cookie_name": "session",
    "secret": "YOU MUST CHANGE ME",
    "duration": 86400000
  },
  "env": "development",
  "use_https": false,
  "static_max_age" : 0,
  "i18n": {
    "supportedLanguages": ["af", "an", "ar", "as", "ast", "az", "be", "bg", "bn-BD", "bn-IN", "br", "bs", "ca", "cs", "cy", "da", "de", "dsb", "el", "en", "en-GB", "en-ZA", "eo", "es", "es-AR", "es-CL", "es-MX", "et", "eu", "fa", "ff", $
  },
  "route_log_format": "dev_fxa",
  "logging": {
    "fmt": "pretty",
    "level": "debug"
  },
  "static_directory": "app",
  "allowed_parent_origins": ["http://127.0.0.1:8080"],
  "csp": {
    "enabled": true,
    "reportUri": "/_/csp-violation"
  }
}

Le plus important est de changer l'URL public pour qu'il corresponde à la variable CONTENT_SERVER_URL, que l'on a spécifié dans la configuration de fxa-auth-accounts. Assurez-vous aussi de rajouter fxaccount_url puisque ce paramètre n'existe pas dans la configuration générée automatiquement.

Une fois la configuration faite, on relance le serveur:

npm start

On devrait maintenant pouvoir se connecter, créer son compte et le valider par mail. Accédez à votre serveur avec l'adresse https://ffcontent.example.org (en remplaçant bien sûr par votre propre domaine), et créez le compte.

Une fois la validation par mail effectuée, une "erreur inattendue" apparaitra. Je ne sais pas à quoi elle est dûe, mais ne semble pas affecter négativement la suite. On ne s'en soucie donc pas pour l'instant, mais si quelqu'un a une explication/solution, je suis preneur !

Serveur de synchronisation

Enfin, dernière pièce de notre puzzle, le serveur de synchronisation. La page dédiée de la documentation fournie par Mozilla est plus accessible et plus à jour que celles concernant le serveur Firefox Accounts. Voici tout de même mon guide, par soucis de centralisation et d'exhaustivité.

Les paquets suivants sont requis:

python-dev git-core python-virtualenv g++

On récupère les sources et on compile:

cd /opt
git clone https://github.com/mozilla-services/syncserver
cd syncserver
make build

On configure:

nano syncserver.ini

[syncserver]
public_url = https://ffsync.example.org/
sqluri = pymysql://root:motdepasse@127.0.0.1/fxsync
force_wsgi_environ = true

[browserid]
backend = tokenserver.verifiers.LocalVerifier
audiences = https://ffsync.example.org

Contrairement à fxa-auth-db-mysql, ici la base de données doit être créée avant de lancer le serveur. Dans mon cas, je l'ai nommée fxsync.

Là aussi, on va créer un reverse proxy dans son serveur web préféré, pour ffsync.example.org vers l'adresse du serveur de synchronisation, sur le port 5000.

On place la variable force_wsgi_environ à true pour éviter que le scheme ne pose problème avec le reverse proxy (qui est en HTTPs) et ce serveur (qui est en HTTP).

Mettez à jour la valeur de secret, comme indiqué en commentaire dans le fichier.

On peut lancer le serveur:

make serve

Configuration de firefox

Maintenant que tout est installé, reste à configurer firefox pour prendre en compte notre propre serveur de synchronisation. Fiez-vous à la capture d'écran suivante pour ajuster vos paramètres (dans about:config):

firefox

Remplacez les domaines par les vôtres, bien entendu.

Remarquez qu'une option identity.fxaccounts.allowHttp a été créée. Si vous voulez vous aventurer à créer un serveur de synchronisation sans chiffrement, positionnez cette valeur à true.

Enfin, rendez-vous dans les options, onglet "Sync", et connectez-vous avec le compte précédemment créé. Firefox devrait pouvoir se synchroniser sans problème.

À noter que si vous cliquez sur le lien "Gérer le compte" une fois configuré, vous aurez la même erreur inattendue que précédemment, ce qui m'incite à croire qu'elle est liée à l'absence d'un serveur d'identité. Mais je laisse ça à un hypothétique futur article.

  • # C'était mieux avant

    Posté par  . Évalué à 10. Dernière modification le 22 février 2016 à 22:58.

    node

    Je me suis arrêté là, je fuis cette technologie comme la peste. Pour moi, c'est du même temps niveau que Java ou Oracle qui sont des usines à gaz dans leurs domaines respectifs.

    Il est où le temps ou un simple serveur LAMP faisait l'affaire, sans les 15.000 dépendances utilisées et un gestionnaire de paquets propre à chaque couche (OS, langage de l'appli…).

    Au hasard d'un commitstrip, j'ai appris qu'il existait une stack MEAN… Putain, si à 18 ans t'as pas développé sur MEAN, t'as raté ta vie de stagiaire !

    • [^] # Re: C'était mieux avant

      Posté par  . Évalué à 9.

      Je suis d'accord.

      Mais il ne faut pas se voiler la face: node est incontournable. Je me demande d'ailleurs s'il ne va pas finir par être intégré par défaut dans les distros. Comme perl en son temps, puis comme python.

      Ça me fait d'ailleurs penser qu'il y a quelques années, je me suis fais incendier sur la place publique parce que j'avais publié quelques outils console écrits en PHP. On m'a complétement décrédibiliser parce que j'utilisais PHP pour de l'administration système.

      Et aujourd'hui, on fait de javascript, un langage de client web à la base, un langage à tout faire. Et donc, forcément bardé de dépendances diverses et variées, y compris (et surtout dans node bien sûr) du… serveur.

      Je relativise aujourd'hui en me disant que le bon côté des choses, c'est que ça laisse le choix aux développeurs de la techno qu'ils veulent utiliser. C'est pas pour autant que je cautionne.

      Mais je dois dire que comparativement à d'autres projets, y compris où l'utilisation de javascript se limite à un usage client, les serveurs mentionnés dans mon article restent relativement légers (sous entendu avec relativement peu de dépendances).

    • [^] # Re: C'était mieux avant

      Posté par  . Évalué à 9. Dernière modification le 23 février 2016 à 09:11.

      sans les 15.000 dépendances utilisées et un gestionnaire de paquets propre à chaque couche

      Tu veux dire, le temps où chacun réinventait la roue de son côté, de préférence carrée en apportant son lot de trous de sécurité (XSS, SQL injections, local/remote file inclusions) et ses correctifs douteux (magic quotes) ?

      Après si c’est ton trip tu peux très bien faire du node sans npm et 0 dépendances en réécrivant tout toi-même avec amour, la technologie de base n’a pas grand chose à voir avec ça. Dans le fond j’ai du mal à voir en quoi express est plus usine à gaz que symfony.

      • [^] # Re: C'était mieux avant

        Posté par  . Évalué à 4.

        Tu veux dire, le temps où chacun réinventait la roue de son côté, de préférence carrée en apportant son lot de trous de sécurité (XSS, SQL injections, local/remote file inclusions) et ses correctifs douteux (magic quotes) ?

        Ça n'a rien à voir. Là tu parles techno alors que moi, si je fais abstraction du fait que je n'aime pas node, je parle d'un problème de packaging (facilité d'install, mise à jour) mais plus globalement de "lourdeur".

        Tu te rends compte que pour exposer ce service REST, je dois me manger git/node/bower et pour chacun d'eux peut-être des dépendances supplémentaires qu'il va falloir que je gère sur le long terme. Ensuite viens encore l'application qui va elle-même me demander d'installer des librairies complémentaires. Et puis mon appli nodejs, je ne suis pas assez tête brûlée pour la mettre en 1ère ligne et vais sûrement la mettre derrière un apache/nginx.

        Si je compare à une bête appli PHP : je décompresse le zip sur mon ftp et l'appli juste marche et se met à jour (prend n'importe quel CMS largement plus compliqué que firefox-sync).
        Au passage, je ne vois pas le rapport entre réinventer la roue et les trous de sécurité. De trous de sécurité, il y en a partout même sur une bibliothèque un peu utilisée.

        Après si c’est ton trip tu peux très bien faire du node sans npm et 0 dépendances en réécrivant tout toi-même avec amour, la technologie de base n’a pas grand chose à voir avec ça. Dans le fond j’ai du mal à voir en quoi express est plus usine à gaz que symfony.

        Non c'est pas mon trip de recoder, simplement node ne passera pas par moi. De toute façon Firefox-sync a déjà subit des réécritures dans 3 langages différents (PHP, Python, Node). Mozilla est encore pire qu'un chevreuil en rut en plein mois d'août : il saute sur tout ce qui bouge. J'attends juste qu'ils passent à ASP.NET Core et là j'installerai ;)

        • [^] # Re: C'était mieux avant

          Posté par  . Évalué à 2.

          Ben ouais, se taper un serveur ftp sur chaque instance juste pour uploader un zip, c'est vachement leger.
          Idem, se taper mod_php + un opcache et tout, c'est super leger.
          Et on va pas mentionner le php.ini, et les 12000 niveaux d'overrides possible, super leger et simple.

          La verite c'est que deployer un service web un tant soit peu professionel de facon un tant soit peu professionelle, c'est jamais simple, ni leger. T'as au moins un runtime, probablement un reverse proxy, un keepalived ou autre pour t'assurer que ca tombe pas en route, un script d'init (ou unit systemd), un log forwarder, que sais je encore.

          Linuxfr, le portail francais du logiciel libre et du neo nazisme.

        • [^] # Re: C'était mieux avant

          Posté par  . Évalué à 4.

          Tu te rends compte que pour exposer ce service REST, je dois me manger git/node/bower et pour chacun d'eux peut-être des dépendances supplémentaires qu'il va falloir que je gère sur le long terme

          Tout ça n’a rien à voir avec PHP vs node. Tu peux très bien faire un .tar d’une appli node, tout comme tu peux déployer une appli PHP avec git+composer (et pour info, bower a encore moins à voir avec la choucroute, c’est pour le frontend, et c’est aussi utilisé dans des projets faits en PHP). Faudra m’expliquer la différence fondamentale entre https://github.com/symfony/symfony/blob/master/composer.json et https://github.com/expressjs/express/blob/master/package.json pour appeler l’un usine à gaz et pas l’autre.

          Ce dont tu te plains c’est jusque que les devs d’applications node s’embêtent plus rarement que les devs d’application PHP à fournir une archive prépackagée. Alors je peux comprendre que ce soit légèrement irritant pour certains (perso j’ai du mal à voir en quoi git clone && npm install est tellement plus pénible que tar xzf, mais admettons…), mais de là à en faire un point bloquant, ça me dépasse…

          Au passage, je ne vois pas le rapport entre réinventer la roue et les trous de sécurité.

          Tu vois sincèrement pas en quoi un projet qui utilise un ORM connu et largement testé comme Doctrine aura beaucoup moins de chances d’avoir des SQL injections qu’un projet qui décide de faire toutes ses requêtes SQL à la main parce que « je veux pas embarquer 150.000 dépendances » ?

          De trous de sécurité, il y en a partout même sur une bibliothèque un peu utilisée.

          Je n’ai jamais prétendu que l’utilisation de librairie externes garantissait l’absence de failles.

          • [^] # Re: C'était mieux avant

            Posté par  (site web personnel) . Évalué à 4.

            (perso j’ai du mal à voir en quoi git clone && npm install est tellement plus pénible que tar xzf, mais admettons…),

            Quand tu travailles sur un réseau déconnecté, tu prends goût aux .deb/.rpm, voire aux .tar.gz quand ça reste correct.

          • [^] # Re: C'était mieux avant

            Posté par  . Évalué à 2. Dernière modification le 24 février 2016 à 17:35.

            et pour info, bower a encore moins à voir avec la choucroute, c’est pour le frontend, et c’est aussi utilisé dans des projets faits en PHP

            bower est marqué en pré-requis dans ce journal c'est donc un nième outil à installer.

            Faudra m’expliquer la différence fondamentale entre https://github.com/symfony/symfony/blob/master/composer.json et https://github.com/expressjs/express/blob/master/package.json pour appeler l’un usine à gaz et pas l’autre.

            Il n'y en a pas puisque c'est la même chose. J'ai parlé, par exemple, d'un CMS : il peut très bien utiliser symfony (donc d'y dépendre) mais va assurer sa propre mise à jour de manière autonome…

            Tu vois sincèrement pas en quoi un projet qui utilise un ORM connu et largement testé comme Doctrine aura beaucoup moins de chances d’avoir des SQL injections qu’un projet qui décide de faire toutes ses requêtes SQL à la main

            Non, je ne vois toujours pas de rapport entre le nombre d'utilisateurs et les risques de sécurité. Il y a un ensemble de facteurs (complexité du projet, taille du projet, qualité technique du codeur…) mais celui-ci tout seul n'en est pas un !

            Tu confonds un utilisateur/testeur avec quelqu'un qui :

            • va effectivement auditer le code
            • a les connaissances techniques pour trouver des bugs (failles incluses)
            • va les remonter UPSTREAM

            Les récents événements ont montré que même les librairies les plus utilisées ne sont pas exemptes de bugs/failles depuis des années, elles ont "autant de chances" (pour reprendre ton expression) d'en avoir :

            • openssl tellement secure que forké en libressl,
            • debian : on se rappelle tous du petit problème de génération ssh
            • glibc
            • rails : qui se vantait d'une protection native des sql injections et s'en est mangé une monstrueuse il y a 2 ans…

            A côté de ça, le stagiaire de ma boîte a peut-être fait toutes ses requêtes SQL à la main mais c'est de bonne qualité et sans sql injection. La qualité d'un projet ne dépend pas du nombre d'utilisateurs.

            • [^] # Re: C'était mieux avant

              Posté par  . Évalué à 5. Dernière modification le 24 février 2016 à 20:18.

              bower est marqué en pré-requis dans ce journal c'est donc un nième outil à installer.

              Comme il pourrait être en prérequis d’un projet en PHP. Encore une fois, rien à voir avec la plateforme.

              mais va assurer sa propre mise à jour de manière autonome…

              Pas nécessairement : seulement si les devs prennent la peine de fournir une version pré-empaquetée. Exactement comme en node donc…

              Non, je ne vois toujours pas de rapport entre le nombre d'utilisateurs et les risques de sécurité

              J’ai parlé de « millions d’utilisateur » pour une chose : indiquer que c’est quelque chose de testé, y compris en production et à large échelle.

              Les récents événements ont montré que même les librairies les plus utilisées ne sont pas exemptes de bugs/failles depuis des années

              Ça tombe bien, personne n’a prétendu ça.

              Maintenant, faisons simple. Tu prends 200 développeurs de tous niveaux. Aux cent premiers, tu leur fait coder un CMS où ils doivent faire toutes leurs requêtes SQL à la main. Au cent autres, tu leur fait coder un CMS avec obligation d’utiliser un ORM. À ton avis, quel groupe aura statistiquement le plus d’injections SQL ? Petit indice : le groupe 2 en aura 0. Ça veut pas dire que ce sont des meilleurs codeurs, et qu’ils n’introduiront aucun bug ni aucune faille. Mais au moins il ne tomberont pas dans ce piège bien précis. Ajoute à cette image un système de template qui échappe les variables par défaut (en opposition à coder à coups de <?php echo $row["user_comment"] ?>), un système de routage qui évite les pièges genre <?php include $_GET['module']."/".$_GET['page']; ?>, et tu te trouveras certes avec 150.000 dépendances, mais un code vachement plus sûr (et non, je n’ai pas dit à 100% sûr).

              Je te rejoins sur un truc : ce qui fait la sécurité, c’est la qualité du code. Et la qualité du code, elle passe par des bonnes pratiques, qui incluent :

              • Factorisation et réutilisation du code: utilisation de librairies externes éprouvées tant que possible.
              • Automatisation maximale (tests, génération de code, gestions des asset). Le « bower » dont tu te plains.

              Alors oui, dans la qualité du code il n’y a pas que ça (loin de là), mais ce dont tu te plains (150.000 dépendances, outillage lourd) sont deux aspects très important de la qualité du code. D’où le fait que je réagisse assez violemment à ta remarque « ah, de mon temps, on avait pas à s’encombrer de tout ça, pas de dépendances, on faisait nos requêtes SQL avec amour » (oui, je caricature ;)). Ce bon vieux temps, c’est aussi un bon vieux temps où on voyait passer dans les CVE des dizaines de SQL injection par semaine sur une base de code totale (beaucoup !) moins large. Ce qui a endigué l’épidémie de SQL injection (et je suis optimiste. Disons, vaguement contenu, vu qu’il y a encore beaucoup de projets dans la nature en mode « YOLO les ORM c’est pour les noobs »), c’est pas un coup de baguette magique qui a rendu les devs plus intelligent, c’est l’exemple de Rails et les émules qu’il a fait dans le monde PHP.

              rails : qui se vantait d'une protection native des sql injections et s'en est mangé une monstrueuse il y a 2 ans…

              C’est un excellent exemple que tu nous sors là. Déjà, ce n’est pas une injection SQL à proprement parler (tu ne peux pas injecter de commande SQL arbitraire). Je te refais la faille en PHP :

              Le formulaire :

              Nom: <input name="user[name]"><br>
Adresse email: <input name="user[email]">
<input type="submit"/>

              Gestion du formulaire :

              $user = User::findOne($_SESSION["userid"]);
foreach($_POST["user"] as $attr => $val) {
    $user->set($attr, $val); // ici $attr et $val sont correctement échappés : pas d’injection SQL
}
$user->validate();
$user->save();

              La faille ? Simple, l’utilisateur ayant le contrôle des entrées, il peut très bien envoyer en données POST user[is_admin] = 1.

              Pourquoi c’est un exemple intéressant ? Parce qu’on a là des développeurs expérimentés, qui savent ce qu’est qu’une injection SQL, qui sont tombés le panneau. Je vais te faire une confession : j’ai un jour, comme beaucoup, succombé au syndrome NIH. J’ai fait un rails-like dans mon langage favori (Objective-C. On a tous nos perversions inavouables). Devine quoi ? Quand la faille pour rails a été révélée, j’étais bien évidemment tombé dans le même panneau. En quoi cette remarque est pertinente sur ce qui nous intéresse ? Après tout, tu vas me dire : le truc fait à la main a la faille, le framework connu a la faille, 1 partout balle au centre.

              Sauf que cette histoire a deux ans. Presque tout le monde l’a oubliée. Contrairement aux SQL injections qui sont martelées à la tête de tous les développeurs (ce qui n’empêche pas certains de continuer à en introduire régulièrement, parce que les ORM c’est trop usine à gaz…), le détail de cette faille n’est connu presque de personne.

              Un dev qui partira sur Rails ne sera pas affecté. L’erreur a été corrigée. Lesson learned, comme disent les anglais. Par contre, un wanabee « moi j’aime pas les dépendances, je vais tout refaire à la main », je te fiche mon billet qu’il a plus (bien plus !) d’une chance sur deux de retomber dans ce panneau.

              Les devs de framework ne sont pas des dieux qui codent mieux que toi, mais ils ont généralement fait les erreurs que tu vas faire avant que tu ne les aies faites. Et les ont corrigées avant que tu les fasses. Et celles qu’ils n’ont pas encore faites mais qu’ils vont faire, ben tu vas les faire aussi. Profite de leur expérience.

              • [^] # Re: C'était mieux avant

                Posté par  (site web personnel) . Évalué à 3.

                Je suis massivement d'accord avec toi sauf sur un point :)

                À ton avis, quel groupe aura statistiquement le plus d’injections SQL ? Petit indice : le groupe 2 en aura 0.

                Il y aura aussi des failles dans le groupe 2 avec ceux qui utiliseront l'équivalent de orm.executeUnsafeQuery("select * from users where " + params.yolo) // what could possibly go wrong? mais bon eux au moins n'ont aucune excuse pour ne pas aller à Pôle Emploi se reconvertir en manutention.

              • [^] # Re: C'était mieux avant

                Posté par  (site web personnel) . Évalué à 2.

                Je ne comprends pas pourquoi utiliser un framework signifie utiliser 150 000 dépendances. Quand tu utilises Django en Python, tu installes Django… et c'est tout. (bon, ok, il faut probablement rajouter gunicorn ou un équivalent).
                Rien n'oblige à installer beaucoup plus de dépendances, je pense que s'il est fréquent d'avoir quelques dépendances supplémentaires, le nombre de dépendances à avoir est beaucoup plus faible avec Django qu'avec bower.

    • [^] # Re: C'était mieux avant

      Posté par  . Évalué à 5.

      Salut,

      Dans le fond, je suis aussi d'accord avec toi, c'est toujours plus sympa un système sans dépendances, dépouillé j'ai envie de dire.

      Après, il faut voir l'aspect gestion. Une application qui implémente énormément de fonctionnalités, c'est toujours plus sympa de la gérer par 15000 plugins, indépendamment, que d'avoir un monobloc énorme difficile à maintenir.

      Ça se voit rapidement avec des framework comme Django par exemple.
      Gérer des plugins via pip et un fichier requirements.txt, c'est cool, mais c'est pas l'éclate non plus hein.

      Un simple serveur LAMP, c'est cool aussi, mais c'est pas l'éclate. Et c'est pas non plus le même besoin.

      Et puis il faut comparer ce qui est comparable. Tu ne feras jamais avec un simple serveur LAMP ce que tu fais avec Node.js.
      Enfin si, tu pourras, mais j'imagine déjà l'usine à gaz que ce sera.

  • # Maintenance?

    Posté par  . Évalué à 5.

    Est-ce que la maintenance est compliquée?
    Si quelqu'un met ça sur son serveur perso, quid de la sécurité par rapport à la maintenance par Mozilla?

    • [^] # Re: Maintenance?

      Posté par  . Évalué à 10.

      Quand l'installation se fait à coup de git clone, la maintenance ne peut pas être simple :p

  • # Super !

    Posté par  . Évalué à 2.

    Super idée de partager ça.

    J'ai la vieille version du serveur de synchro qui tourne et hélas, c'est fragile et tout aussi opaque, et je désespérais de pouvoir mettre à jour vu que le serveur est abandonné ainsi que la partie client.

    Deux remarques après une lecture rapide:

    1. Ca serait bien de décrire sommairement les différentes briques qui tournent sur le serveur et à quoi elles servent.

    2. Quid de la maintenance ? C'est bien beau d'ouvrir un service mais cela ne peut fonctionner que s'il est maintenu. Comme il ne s'agit pas de paquets de la distribution, cela demande de faire des actions manuelles pour vérifier les corrections et les installer.

    • [^] # Re: Super !

      Posté par  . Évalué à 3.

      1.

      • fxa-auth-server, c'est le serveur d'authentification
      • fxa-content-server, c'est le serveur de contenu (les différentes pages lors de la connexion, de l'enregistrement, les js/css, etc.
      • fxa-sync-server, c'est le serveur de synchronisation à proprement parlé.

      Un petit graphique: https://wiki.mozilla.org/Identity/Firefox_Accounts#Architecture

      2.

      git stash
git pull
npm update

      Et:

      bower update

      pour fxa-content-server.

      Je suppose que ça devrait suffire, hors cas de gros changement dans leurs specs.

  • # configuration client

    Posté par  . Évalué à 2.

    L'image de la configuration client a sauté (404).
    Il me semble que c'était du texte.
    Peut être peut il être directement mis dans l'article.

  • # commande erronée

    Posté par  (site web personnel) . Évalué à 1.

    Merci beaucoup pour ce guide. Il m'a fallu changer quelques petits détails sur mon serveur, mais globalement, je n'y arriverais pas sans ce guide.
    Une petite erreur s'est glissée dans une commande ; il faut exécuter :
    npm run postinstall
    et non :
    npm postinstall

    • [^] # Re: commande erronée

      Posté par  . Évalué à 1.

      Chez moi, sur debian Jessie:

      Ne pas utiliser le nodejs de Debian qui est visiblement répudié par les dev nodejs (j'imagine que nodejs embarque des libs trafiquées), prendre celui qui est packagé sur https://github.com/nodesource/distributions (on n'est pas obligé d'exécuter un script en root, on peut ajouter la clef PGP à la main et les lignes qui vont bien dans le sources.list, j'ai pris nodejs 0.12

      Installer python3-virtualenv et virtualenv également.

      Si vous voulez une petite idée de la place que ça occupe:

      $ du -sh *
117M    fxa-auth-db-mysql
311M    fxa-auth-server
554M    fxa-content-server
1.6M    scrypt-hash
41M     syncserver

      Auquel il faut ajouter le paquet nodejs qui consomme 34 Mo en version 0.12

  • # docker

    Posté par  . Évalué à 0.

    Le plus simple serait d'utiliser docker. J'ai pas chercher mais il doit y avoir des Dockerfile dispo.

    Docker prend ici tout son sens…

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.