CérénIT

Container & Orchestration

• Kubernetes 1.6: Multi-user, Multi-workloads at Scale : à l’occasion de KubeCon à Berlin, sortie d’une nouvelle version de Kubernetes avec son lot de nouveautés, de nouvelles fonctionnalités et de fonctionnalités qui évolue de alpha > beta > stable en fonction de leurs maturités respectives. 4 grands axes d’amélioration : scaling avec le support jusqu’à 5.000 noeuds / 150.000 pods est supporté via la fédération de clusters, sécurité avec la mise en place de RBAC (Role Based Access Control) et amélioration de kubeadm pour initialiser votre cluster, scheduling amélioré pour mieux gérer la distribution des workloads sur votre cluster et enfin le provisionning dynamique du stockage pour simplifier la vie et la gestion du stockage par une allocation à la demande.

DevOps

• Déployer son infrastructure Google Cloud Platform grâce à Terraform : Introduction à Terraform, l’outil de provisionning d’infrastructure développé par HashiCorp dans un contexte Google Cloud. D’ailleurs Terraform 0.9 vient de sortir.
• Terraform & Scaleway - Getting Started : un autre exemple d’utilisation de Terraform assez bien expliqué dans un contexte Scaleway
• IT Landscape for sysadmins : Panorama des solutions et outils opensource à usage des profils sysadmin/devops regroupés par catégories.
• Tutorial: How to test your docker image in half a second : Ce tutoriel montre comment tester le bon fonctionnement d’une image docker via l’outil goss. Goss, une alternative à serverspec, permet de tester et valider la configuration d’un serveur ou d’un container dans le cas présent.
• Announcing Longhorn: an open source project for microservices-based distributed block storage : Rancher sort le projet Longhorn, un système de stockage block distribué (et non pas un système de fichier distribué comme Ceph, GlusterFS ou Minio). Compatible uniquement avec Docker pour le moment, prochainement avec Kubernetes, reste à voir justement comment la partie système de fichiers sera traitée. Projet intéressant en tous cas.
• RancherOS Hits General Availability : la mini-distribution Linux optimisée pour lancer des containers Docker, Rancher OS, sort en version GA.

HTML5

• Practical CSS Grid: Adding Grid to an Existing Design : la dernière nouveauté CSS, c’est la grille. Une fois cette grille définie, on peut y positionner les éléments de son choix. L’article permet de voir un cas pratique de mise en place de cette grille dans le cadre de la refonte d’un blog. On y voit aussi les quelques limitations et soucis que l’on peut actuellement rencontrer avec ce nouveau système disponible dans tous les navigateurs ou presque depuis Mars 2017.

Javascript

• What’s new in Angular 4? ou Angular 4.0: La version 4.0 vient de sortir, revue des nouveautés et des changements pour ceux qui s’intéressent (encore) à AngularJS.

Kafka

• Kafka Streams 101 : un article simple et pédagogique sur Kafka Streams, la librairie Java qui permet de consommer ou de produire des messages dans un topic kafka.

MySQL

• How we Upgraded a 22TB MySQL Cluster from 5.6 to 5.7 (in 9 months) : retour d’expérience sur la migration d’un cluster MySQL de 22 To de MySQL 5.6 vers 5.7 et les écueils rencontrés. Intéressant.

Postgres

• https://github.com/begriffs/postgrest : Pour permettre de mettre une API Rest devant votre base Postgres. Un écosystème existe autour de cette solution pour facilement l’intégrer dans votre projet.

Python

• Python’s Instance, Class, and Static Methods Demystified : Tout est dans le titre ! Je connaissais peu les “class methods” et “static methods”. Cela aurait pu m’être utile pour mon précédent projet !
• Building microservices with Python (Part 1, Part 2, Part 3) : un récit assez complet pour batir un microservice s’appuyant sur Flask. Les autres outils intéressants sont connexions (API, oAuth, OpenAPI Specs), Flask-injector pour l’injection de dépendance et fastavro

Objectifs

Pour pouvoir tester différentes solutions, il peut être utile de pouvoir créer rapidement une infrastructure chez un fournisseur tiers. Pour cela nous allons nous appuyer sur la solution Terraform, dont l’objectif est de pouvoir gérer une insfrastructure via du code qui permet de décrire cette infrastructure et les règles associées (dans la tendance Infrastructure as Code).

Cela se fera chez Scaleway mais cela peut se faire chez d’autres fournisseurs tant qu’un provider Terraform existe.

Nous allons nous appuyer sur l’intégration Terraform/Scaleway pour créer un cluster de 3 machines.

Pré-requis

• Un compte chez Scaleway
• Avoir créé un token (via Account > Credentials)
• Avoir terraform sur son PC ; version 0.9.2 dans mon cas.

Créer un ficheir cluster-3.tf dans un dossier vide. Il est important qu’il soit vide car Terraform prend en compte tous les fichiers .tf qu’il rencontre dans le répertoire courant.

Il faut commencer par déclarer notre provider ; je fournis les infos de key & token, ainsi que le datacenter où je souhaite lancer mon cluster :

provider "scaleway" {
  organization = "<access key>"
  token        = "<token>"
  region       = "par1"
}

Je déclare ensuite des data, que l’on peut assimiler à des variables à ce stade :

• le bootscript est une option de démarrage, notamment au niveau du noyau, d’un serveur chez Scaleway,
• l’image est l’OS voulu, ici une version Ubuntu Xenial en 64 bits.

data "scaleway_bootscript" "latest" {
  architecture = "x86_64"
  name_filter  = "stable"
}

data "scaleway_image" "ubuntu" {
  architecture = "x86_64"
  name         = "Ubuntu Xenial"
}

Ensuite, je définis une politique de sécurité en 2 étapes :

• Je déclare la politique de sécurité,
• J’y ajoute les différentes règles : ici on autorise par défaut ssh, http et https.

resource "scaleway_security_group" "cluster_default" {
  name        = "cluster_default"
  description = "Allow SSH, HTTP, HTTPS traffic"
}

resource "scaleway_security_group_rule" "ssh_accept" {
  security_group = "${scaleway_security_group.cluster_default.id}"
  action         = "accept"
  direction      = "inbound"
  ip_range       = "0.0.0.0/0"
  protocol       = "TCP"
  port           = 22
}

resource "scaleway_security_group_rule" "http_accept" {
  security_group = "${scaleway_security_group.cluster_default.id}"
  action         = "accept"
  direction      = "inbound"
  ip_range       = "0.0.0.0/0"
  protocol       = "TCP"
  port           = 80
}

resource "scaleway_security_group_rule" "https_accept" {
  security_group = "${scaleway_security_group.cluster_default.id}"
  action         = "accept"
  direction      = "inbound"
  ip_range       = "0.0.0.0/0"
  protocol       = "TCP"
  port           = 443
}

Je pourrais donc me connecter en ssh, http et https sur l’ensemble de mon cluster une fois qu’il sera initialisé.

Je déclare ensuite une IP et je l’associe au serveur qui l’utilisera :

resource "scaleway_ip" "cluster-master_ip" {
  server = "${scaleway_server.cluster-master.id}"
}

Enfin, je déclare mon serveur qui va reprendre l’ensemble des informations précédentes, ainsi que quelques informations spécifique comme le type d’instance (type) ou encore le volume additionnel (volume) attaché au serveur. Il y a des directives scaleway_volume ou scaleway_volume_attachment mais l’API Scaleway ne permet pas de les utiliser pour ce type de serveur.

resource "scaleway_server" "cluster-master" {
  name           = "cluster-master"
  image          = "${data.scaleway_image.ubuntu.id}"
  type           = "VC1M"
  bootscript     = "${data.scaleway_bootscript.latest.id}"
  security_group = "${scaleway_security_group.cluster_default.id}"
  
  volume {
    size_in_gb = 50
    type       = "l_ssd"
  }
}

Sur le même modèle, nous allons instancier les 2 autres noeuds de notre cluster :

resource "scaleway_ip" "cluster-node1_ip" {
  server = "${scaleway_server.cluster-node1.id}"
}

resource "scaleway_server" "cluster-node1" {
  name           = "cluster-node1"
  image          = "${data.scaleway_image.ubuntu.id}"
  type           = "VC1M"
  bootscript     = "${data.scaleway_bootscript.latest.id}"
  security_group = "${scaleway_security_group.cluster_default.id}"
  
  volume {
    size_in_gb = 50
    type       = "l_ssd"
  }
}

resource "scaleway_ip" "cluster-node2_ip" {
  server = "${scaleway_server.cluster-node2.id}"
}

resource "scaleway_server" "cluster-node2" {
  name           = "cluster-node2"
  image          = "${data.scaleway_image.ubuntu.id}"
  type           = "VC1M"
  bootscript     = "${data.scaleway_bootscript.latest.id}"
  security_group = "${scaleway_security_group.cluster_default.id}"
  
  volume {
    size_in_gb = 50
    type       = "l_ssd"
  }
}

Vous pouvez déjà valider qu’il n’y a pas d’erreur de syntaxe avec

↪ terraform fmt
cluster-3.tf

Si pas d’erreur, alors il ne retourne que le nom du fichier ou rien si commande déjà exécutée.

Ensuite vous pouvez regarder ce qu’il va se passer avec terraform plan. Cela vous sort un diff de ce qui va être réalisé (ou changé s’il y a mise à jour du plan)

Dans notre cas :

↪ terraform plan

[...]

+ scaleway_ip.cluster-master_ip
    ip:     "<computed>"
    server: "${scaleway_server.cluster-master.id}"

+ scaleway_ip.cluster-node1_ip
    ip:     "<computed>"
    server: "${scaleway_server.cluster-node1.id}"

+ scaleway_ip.cluster-node2_ip
    ip:     "<computed>"
    server: "${scaleway_server.cluster-node2.id}"

+ scaleway_security_group.cluster_default
    description: "Allow SSH, HTTP, HTTPS traffic"
    name:        "cluster_default"

+ scaleway_security_group_rule.http_accept
    action:         "accept"
    direction:      "inbound"
    ip_range:       "0.0.0.0/0"
    port:           "80"
    protocol:       "TCP"
    security_group: "${scaleway_security_group.cluster_default.id}"

+ scaleway_security_group_rule.https_accept
    action:         "accept"
    direction:      "inbound"
    ip_range:       "0.0.0.0/0"
    port:           "443"
    protocol:       "TCP"
    security_group: "${scaleway_security_group.cluster_default.id}"

+ scaleway_security_group_rule.ssh_accept
    action:         "accept"
    direction:      "inbound"
    ip_range:       "0.0.0.0/0"
    port:           "22"
    protocol:       "TCP"
    security_group: "${scaleway_security_group.cluster_default.id}"

+ scaleway_server.cluster-master
    bootscript:          "8fd15f37-c176-49a4-9e1d-10eb912942ea"
    enable_ipv6:         "false"
    image:               "89457135-d446-41ba-a8df-d53e5bb54710"
    name:                "cluster"
    private_ip:          "<computed>"
    public_ip:           "<computed>"
    public_ipv6:         "<computed>"
    security_group:      "${scaleway_security_group.cluster_default.id}"
    state:               "<computed>"
    state_detail:        "<computed>"
    type:                "VC1M"
    volume.#:            "1"
    volume.0.size_in_gb: "50"
    volume.0.type:       "l_ssd"
    volume.0.volume_id:  "<computed>"

+ scaleway_server.cluster-node1
    bootscript:          "8fd15f37-c176-49a4-9e1d-10eb912942ea"
    enable_ipv6:         "false"
    image:               "89457135-d446-41ba-a8df-d53e5bb54710"
    name:                "cluster-node1"
    private_ip:          "<computed>"
    public_ip:           "<computed>"
    public_ipv6:         "<computed>"
    security_group:      "${scaleway_security_group.cluster_default.id}"
    state:               "<computed>"
    state_detail:        "<computed>"
    type:                "VC1M"
    volume.#:            "1"
    volume.0.size_in_gb: "50"
    volume.0.type:       "l_ssd"
    volume.0.volume_id:  "<computed>"

+ scaleway_server.cluster-node2
    bootscript:          "8fd15f37-c176-49a4-9e1d-10eb912942ea"
    enable_ipv6:         "false"
    image:               "89457135-d446-41ba-a8df-d53e5bb54710"
    name:                "cluster-node2"
    private_ip:          "<computed>"
    public_ip:           "<computed>"
    public_ipv6:         "<computed>"
    security_group:      "${scaleway_security_group.cluster_default.id}"
    state:               "<computed>"
    state_detail:        "<computed>"
    type:                "VC1M"
    volume.#:            "1"
    volume.0.size_in_gb: "50"
    volume.0.type:       "l_ssd"
    volume.0.volume_id:  "<computed>"

Plan: 10 to add, 0 to change, 0 to destroy.

Pour provisionner l’infrastructure, il ne vous reste plus qu’à faire terraform apply.

↪ terraform apply
data.scaleway_bootscript.latest: Refreshing state...
data.scaleway_image.ubuntu: Refreshing state...
scaleway_security_group.cluster_default: Creating...
  description: "" => "Allow SSH, HTTP, HTTPS traffic"
  name:        "" => "cluster_default"
scaleway_security_group.cluster_default: Creation complete (ID: 06b93dc3-...2beffd62)
scaleway_security_group_rule.ssh_accept: Creating...
  action:         "" => "accept"
  direction:      "" => "inbound"
  ip_range:       "" => "0.0.0.0/0"
  port:           "" => "22"
  protocol:       "" => "TCP"
  security_group: "" => "06b93dc3-9a8b-4022-80bf-e9172beffd62"
scaleway_server.cluster-master: Creating...

[...]

Apply complete! Resources: 10 added, 0 changed, 0 destroyed.

Vous pouvez consulter l’ensemble des informations de votre infrastructure avec la commande terraform show.

Il ne vous reste plus qu’à vous connecter sur vos serveurs, faire les actions dont vous avez besoin.

Supposons que nous ayons besoin d’un 4ème noeud, il suffirait de rajouter dans le fichier cluster-3.tf :

resource "scaleway_ip" "cluster-node3_ip" {
  server = "${scaleway_server.cluster-node3.id}"
}

resource "scaleway_server" "cluster-node3" {
  name           = "cluster-node3"
  image          = "${data.scaleway_image.ubuntu.id}"
  type           = "VC1M"
  bootscript     = "${data.scaleway_bootscript.latest.id}"
  security_group = "${scaleway_security_group.cluster_default.id}"

  volume {
    size_in_gb = 50
    type       = "l_ssd"
  }
}

On peut valider notre changement avec terraform plan :

↪ terraform plan

[...]

+ scaleway_ip.cluster-node3_ip
    ip:     "<computed>"
    server: "${scaleway_server.cluster-node3.id}"

+ scaleway_server.cluster-node3
    bootscript:          "8fd15f37-c176-49a4-9e1d-10eb912942ea"
    enable_ipv6:         "false"
    image:               "89457135-d446-41ba-a8df-d53e5bb54710"
    name:                "cluster-node3"
    private_ip:          "<computed>"
    public_ip:           "<computed>"
    public_ipv6:         "<computed>"
    security_group:      "06b93dc3-9a8b-4022-80bf-e9172beffd62"
    state:               "<computed>"
    state_detail:        "<computed>"
    type:                "VC1M"
    volume.#:            "1"
    volume.0.size_in_gb: "50"
    volume.0.type:       "l_ssd"
    volume.0.volume_id:  "<computed>"


Plan: 2 to add, 0 to change, 0 to destroy.

Puis de mettre à jour le cluster avec terraform apply

↪ terraform apply

[...]

Apply complete! Resources: 2 added, 0 changed, 0 destroyed.

Enfin, comme toutes les choses ont une fin, vous pouvez détruire l’ensemble de l’infrastructure créé via terraform destroy.

↪ terraform destroy

[...]

Destroy complete! Resources: 14 destroyed.

J’espère que cette introduction à Terraform vous donnera des idées ; les éditeurs de code modernes fournissent souvent des plugins pour la syntaxe et les snippets terraform. Scaleway reste assez limité en tant que provider terraform. Si vous regardez le provider AWS, vous pouvez interagir avec énormément de services AWS (pour ne pas dire tous) : VPC, EC2, ELB, RDS, etc.

Admin Sys

• l y a un poisson dans ma coquille ! : J’avais fait il y a quelques années un détour par le shell zsh via “Oh My ZSH” mais je n’étais pas allé bien loin, revenant au final au bon vieux bash. L’article m’a donné envie d’essayer fish et pour le moment, je trouve ça plutôt pas mal. Ne pas se fier à la première impression du site :)
• Pour faire fonctionner virtualenv(wrapper) avec Fish: VirtualFish
• Pour enrichir votre Fish, vous pouvez vous appuyer sur fisherman ou le projet oh-my-fish

Containers

• Adventures in GELF : où l’on apprend notamment que les logs sont par défaut au format JSON et surtout qu’il n’y a pas de rotation des journaux par défaut :’( ; l’article montre ensuite les intérêts du format GELF (avoir un message sous la forme d’un dictionnaire/tableau au format clé/valeur) et les limites (connextion UDP) avec les solutions de contournement actuelles et les solutions à venir prochainement.
• Announcing Docker Entreprise Edition : Docker Inc annonce une version “Docker Community Edition” et une version “Docker Entreprise Edition” (avec support). Il y aura désormais une version stable trimestrielle (avec changement de versionning à la Ubuntu : YY.MM et une politique de support de 4 mois) ou une version “bleeding edge” mensuelle pour la version communautaire (support mensuel). Pour la version entreprise, c’est trimestrielle avec 1 an de support & maintenance. Docker Inc se dote également d’un programme de certification pour la partie matérielle, système sous jacent, les plugins et les conteneurs en eux même. Une réponse notamment fait à Docker de trop changer le comportement de docker et de ses composants/fonctionnalités d’une version à une autre.
• CoreOS a l’intention de donner rkt à la Cloud Native Computing Foundation qui hébergedéjà de nombreux projets cloud dont Kubernetes. Docker Inc va faire de même avec containerd. Si le billet de CoreOS laissait penser un travail commun, le billet de Docker ne me donne pas cette impression. Donc a priori chacun va travailler de son côté et on regarde qui sort vainqueur à la fin ? La guerre des containers n’est pas finie…
• From dotCloud to docker : Une retrospective sur l’histoire de Docker.

Cloud

• Google Cloud Platform: your Next home in the cloud : Google avait jusqu’à présent plutôt un positionnement de marché de niche où pour aller sur leur cloud il fallait adopter leurs produits. Avec la Conférence Google Cloud Next 2017, s’opère un sacré changement et que Google semble revendiquer : devenir un acteur global du cloud et être en mesure d’accompagner ses clients sur l’ensemble de leurs sujets. S’il ne fallait qu’un exemple, je pendrais bien celui de la certification de SAP HANA sur GCP. On notera aussi l’arrivée de Postgresql en service managé, de nouveaux langages pour App Engine, etc. Je vous laisse trouver les nouveautés mais pour moi la nouveauté est ce changement de positionnement de Google. Les autres fournisseurs de cloud ne doivent pas forcément être ravis de ce changement ; reste à voir si Google convaincra les autres clients. Si par ailleurs, les clients sont déjà chez Google Suite, on peut imaginer qu’ils passent plus aisément dans Google Cloud pour n’avoir qu’un fournisseur…
• 100 announcements from Google Cloud Next 17 : la liste complète des 100!! annonces…

DevOps

• Site Reliability Engineering : le terme de Site Reliability Engineering (SRE) prend de plus en plus d’ampleur depuis quelques mois. Un SRE est une personne avec un profil plutôt développeur mais qui est aussi à l’aise sur la partie “opérations” et donc en mesure d’assurer l’exploitation de son application (avec les incidents liés) ; il travaille donc sur les 2 tableaux pour son application. Google partage dans ce livre son expérience de la mise en place de ses équipes SRE pour une partie de leurs produits.

GraphQL

• Use all the databases - part1 et Use all the databases - part 2 : Deux billets présentant GraphQL qui se veut un successeur de REST. L’article montre comment avec une seule requête faite sur un endpoint GraphQL, on peut aller récupérer des données dans plusieurs bases de données. Intéressant, mais à voir si cela n’est pas trop magique et si on ne crée pas un SPOF de l’application en procédant ainsi.
• GraphQL Guide : site du livre en cours de préparation sur GraphQL
• Appolo : le client de référence sur GraphQL utilisable notamment avec React (Native), AngularJS, iOS & Android.

HTML5

• Managing Push Subscriptions : nouvel article d’une série sur les bonnes pratiques à adaopter lorsque l’on génère des notifications en Push via WebPush.
• State of Responsive Images 2017 : en version courte, c’est mieux, mais c’est pas encore tout à fait ça. Plus sérieusement, un état des lieux sur les images responsives, ce qui a été fait, les chantiers incomplets voire ratés.

Javascript

• NPM vs Yarn : une revue assez détaillée des avantages de Yarn sur NPM.

Opensource

• What it feels like to be an open-source maintainer, Sustainable Open Source: The Maintainers Perspective or: How I Learned to Stop Caring and Love Open Source et Time to leave : Le premier billet revient sur la difficulté et la peine à maintenir un projet open source rencontrant un certain succès. Les deux autres billets sont des réactions à ce premier billet encourgeant soit à apprendre à ne plus se soucier autant du projet, voire à quitter le projet. Des réflexions intéressantes que l’on peut appliquer aussi à sa façon de gérer un projet et la rapidité à laquelle on répond aux sollicitations de ces clients…

Queues & Messages

• Why Messaging Queues Suck : Réflexion intéressante autour des bus de messages et de la soi-disante agnosticité des producteurs de topics vis à vis de leur consommateurs. Au final, de part les procédures de définition d’accès à un topic (dans un contexte cloud), la partie agnosticité est toute relative. Du coup, pour l’auteur, il est plus intéressant de faire des “endpoints” HTTP entre 2 services et que ce soit le client qui implémente son propre système de queue en interne. Cela mérite réflexion et peut avoir ses intérêts en fonction de votre architecture.

Sécurité

• Announcing the first SHA1 collision : Google a annoncé la première collision obtenue avec le protocole de chiffrement SHA-1. Une collision est obtenue lorsque la signature de deux fichiers est identique, alors que théoriquement, chaque fichier devrait avoir une signature unique. Même si les conditions pour obtenir cette collision reste assez peu exploitable de part les ressources nécessaires pour le faire, la dépréciation de SHA-1 est accélérée. Par ex, Firefox, qui avait prévu de le finaliser l’abandon du support de SHA-1 avec la version 52 du navigateur vient de le faire en accéléré suite à cette publication et Google Chrome en a fait de même.
• Incident report on memory leak caused by Cloudflare parser bug : un bug identifié par l’équipe de Google a révélé que depuis septembre 2016 et jusqu’à fin février 2017, un composant de l’infrastructure de Cloudflare divulguait des informations sensibles (identifiants, cookies, etc) de ses utilisateurs lorsqu’il parsait des pages HTML mal formées. L’article de NextImpact l’explique bien, il faut globalement changer vos mots de passes et renouveller vos cookies pour les sites utilisant Cloudflare (une liste ici ou ce site)
• HTTPS : De SSL à TLS 1.3 : rétrospective et explications sur les différents mécanismes de chiffrement disponibles, leurs forces/faiblesses et l’avenir avec TLS 1.3

Contexte

Un de nos clients souhaite pouvoir envoyer des newsletters à ses membres et utiliser des listes de diffusion pour la communication entre les membres.

Ayant de précédentes expériences avec mailman, je me suis naturellement tourné vers celui-ci. Pour l’occasion, j’ai installé une première instance de mailman3 via mailman-bundler. Si l’installation se fait sans trop de soucis, les versions packagées avec mailman-bundler ne sont pas les plus récentes et contiennent des bugs (parfois déjà corrigés dans les versions supérieures) rendant quelques fonctionnalités inopérantes (comme la modération des messages) ou provoquant des comportements étranges (certaines modifications d’options de liste ne sont parfois pas pris en compte). Même si le service fonctionnait à peu près correctement, nous décidions de revenir en mailman dans sa version 2. Même si cela résolvait les problèmes de stabilité et les bugs, il nous manquait une fonctionnalité : l’abonnement à une liste sans confirmation (la confirmation par réponse à un email étant jugé trop complexe).

Pour revenir à Mailman 3, la documentation et les développeurs considèrent qu’il n’est pas encore tout à fait prêt. A l’instar de la suite KDE, il faudra attendre une version 3.2 ou plus pour pouvoir l’utiliser sereinement. En tous cas, la nouvelle interface est prometteuse !

Notre client souhaitant pouvoir envoyer des listes avec son nom de domaine et celui-ci n’étant pas forcément prêt à payer pour cette fonctionnalité, cela disqualifiait plusieurs solutions hébergées (SaaS).

Je me suis donc rabattu sur Sympa.

Installation

Pré-requis

• Debian 8 Jessie, à jour.
• Avoir un serveur postfix installé et configuré

Installation de sympa

Initialement, je voulais utiliser Postgres comme base de données, il s’est avéré que l’installateur debian ou sympa échoue. De guerre lasse, je me suis rabattu sur MySQL qui de toutes façons est considéré comme une dépendance de Sympa et je suis passé par la configuration via db-config. Pour le serveur web, ayant déjà un apache2 sur ce serveur pour mailman, je suis resté sur cette configuration.

Avant toute chose, s’assurer que /etc/mailname correspond bien à votre DNS utilisé pour le mail. Sympa semble prendre cette valeur par défaut et semble ignorer une mise à jour de ce fichier postérieurement à son installation.

apt update
apt install sympa

A ce stade vous avez une première configuration de sympa avec MySQL initialisée pour vos données.

Ensuite, vérifier que les dépendances de Sympa sont bien à jour et complètes ; Installer les librairies dont vous avez besoin pour votre scénario.

sympa_wizard --check

Ensuite, vous pouvez soit éditer les fichiers de configuration /etc/sympa/sympa.conf et /etc/sympa/wwsympa.conf ou bien utiliser le script prévu à cet effet : sympa_wizard. Cela revient au même, le script prend en compte les valeurs du fichiers et complète le cas échéant avec vos nouvelles réponses. Ce sont surtout les premières questions qui sont importantes avec la définition des hôtes, url et surtout la définition des listmaster. Les emails définis comme listmaster pourront en effet administrer Sympa. Pensez également a bien activer le support de fastcgi pour éviter une erreur 500.

Ensuite, en m’inspirant des fichiers /etc/apache2/conf-available/sympa.conf /etc/apache2/conf-available/sympa.conf et /etc/apache2/conf-available/sympa-soap.conf fournis par Sympa, j’ai créé le fichier (simplifié) suivant dans /etc/apache2/sites-available/sympa.conf :

#
# Apache >> 2.4 configuration for Sympa
#

<IfModule mod_fcgid.c>
    Alias /static-sympa /var/lib/sympa/static_content
    <Directory /var/lib/sympa/static_content>
        Require all granted
    </Directory>

    ScriptAlias /wws /usr/lib/cgi-bin/sympa/wwsympa-wrapper.fcgi
    <Directory /usr/lib/cgi-bin/sympa>
        Require all granted
    </Directory>
</IfModule>

#
# Apache >> 2.4 configuration for Sympa (soap webservice)
#

<IfModule mod_fcgid.c>
    ScriptAlias /sympasoap /usr/lib/cgi-bin/sympa/sympa_soap_server-wrapper.fcgi
    <Directory /usr/lib/cgi-bin/sympa>
        Require all granted
    </Directory>
</IfModule>

<VirtualHost *>
    ServerName listes.domaine.fr
    ServerAdmin contact@cerenit.fr

    RewriteEngine On
    RewriteRule ^/$ /wws/lists [R=301,L]
</VirtualHost>

Puis, activation du site via :

a2ensite sympa
systemctl restart apache2

Ajustement de la configuration de Postfix

Dans /etc/postfix/master.cf, ajouter :

# Services Pour sympa
sympa   unix        -   n   n   -   -   pipe
    flags=R user=sympa argv=/usr/lib/sympa/bin/queue ${recipient}
sympabounce unix    -   n   n   -   -   pipe
    flags=R user=sympa argv=/usr/lib/sympa/bin/bouncequeue ${recipient}

Dans /etc/postfix/main.cf, ajouter :

#
## SYMPA
#

# Tranport vers les services sympa*
transport_maps = regexp:/etc/postfix/sympa_transport.cf
local_recipient_maps = regexp:/etc/postfix/sympa_transport.cf

# Un seul envoi/destinataire envoyé aux services sympa* à la fois
sympa_destination_recipient_limit = 1
sympabounce_destination_recipient_limit = 1

Et dans /etc/postfix/sympa_transport.cf :

/^.*-owner\@listes\.domaine\.fr$/ sympabounce:
/^.*\@listes\.domaine\.fr$/       sympa:

Il ne nous reste plus qu’à redémarrer Postfix et Sympa pour s’assurer que nos modifications ont bien été prises en compte :

systemctl restart postfix sympa

Première utilisation

Il ne vous reste plus qu’à aller sur http://listes.domaine.fr/wws/ et vous devriez avoir l’interface de Sympa.

Cliquer alors sur “1ère connection”, rentrer un des emails de listmaster pour obtenir votre mot de passe et pouvoir administrer Sympa en fonction de vos besoins.

Admin Sys

• htop explained visually : htop expliqué. Si vous avez d’autres questions sur les commandes shell : Explain Shell

HTML,JS,CSS

• Les sections HTML, CSS et JavaScript de MDN sont disponibles en français : " TL;DR : Les 1 749 pages de MDN pour les sections HTML/JS/CSS sont désormais disponibles, à jour, en français." ; MDN (ou plus longuement le « Mozilla Developer Network ») est un wiki, documentant les technologies web. Si la langue de Shakespeare vous rebutait, vous n’avez plus aucune raison maintenant. Impréssionnant travail en tous cas !

Machine learning

• Avec cette première série de 3 billets, Introduction au machine learning, Premiers tests avec le machine learning et Une affaire de logistique, Thibault Jouannic nous emmène dans le monde du machine learning de façon pédagogique et fun. Cela permet de dédramatiser tous ces termes barbares pour rendrer progressivement dans ce monde et commencer à l’appréhender. Un joli travail de vulgarisation !

(No)SQL

• RethinkDB joins The Linux Foundation : l’arrêt de la société (Octobre 2016) ne signifiera donc pas la fin du projet opensource associé. Il est peut être encore un peu tôt pour statuer sur la pérénité du projet, mais au moins, il y a une lueur au bout du tunnel. Pour rappel, RethinkDB est une base de données scalable, orientée temps réel et document (JSON). L’article permet de voir également les enjeux de licences/propriété intellectuelle.
• RethinkDB versus PostgreSQL: my personal experience : Un retour d’expérience sur RethinkDB vs Postgres avec Postgres qui gagne à la fin (comme toujours ! :-) ). Il semble néanmoins avoir un volume de données et un traffic que tout le nonde n’a pas.
• Is Postgresql good enough? : revue des différents cas d’utilisation des bases NoSQL et voir comment / dans quelle(s) mesure(s) on peut y répondre avec Postgres. L’idée est de se dire que plutôt d’avoir n outils (et la gestion de l’expertise qui va avec), autant en avoir moins, qui répondent au besoin même s’ils ne font pas aussi bien que l’outil de référence.
• PostgreSQL worst practices, version FOSDEM PGDay 2017 : revue des mauvaises pratiques Postgres pour vous faire prendre les bonnes.
• Zero Downtime Postgres Upgrades : Présentation d’une architecture Postgres multi-noeuds permettant la gestion du failover.

Opinions

• Modern Software Over-Engineering Mistakes : pour alimenter la réflexion sur la tendance à l’overengineering que nous pratiquons plus ou moins.
• Le hacker, ce héros : comment être un bon growth hacker - Oussama Ammar, Co-Founder chez TheFamily ; au delà du titre, toujorus la réflexion entre le hacker qui fait peut être du code “sâle” à court terme mais qui répond à un besoin vs l’ingénieur qui fait des cathédrales mais qui arrivent bien trop tard et le projet est mort entre temps faute d’avoir produit quoi que ce soit.

Sécurité

• Cross-Site Request Forgery is dead! : il est possible de sécuriser de plus en plus ses cookies pour tuer toute tentative de CSRF. Il est conseillé de lire préalablement Tough cookies pour avoir le petit rappel sur les cookies et leurs attributs.
• A new security header: Referrer Policy : un nouveau Header http, au state de recommandation du W3C, va faire son apparition et permet de définir des politiques sur la gestion du referer (le propager ou pas).

UX

• Dois-je utiliser ? : Une revue des écueils des carrousels, pop-in, un défilement inifini, etc avec exemples, des solutions, des alternatives et des argumentaires.