Flavien JOURDREN

Devstack est un projet dont le principe est de déployer rapidement un environnement de développement et de test du projet OpenStack. Devstack supporte Ubuntu 16.04 / 17.04, Fedora 24/25, CentOS / RHEL 7, ainsi que Debian et OpenSUSE. Dans cet article, nous installerons la version ocata d’OpenStack.

Devstack installe par défaut les modules :

- Keystone : Système d’identification.

- Nova : Module s’occupant de la virtualisation des machines.

- Cinder : Stockage.

- Neutron : Module réseau.

- Horizon : Interface web.

Attention : Devstack n’est pas fait pour être redémarré. Il ne peut donc pas être utilisé comme environnement de production.

Attention 2 : Au vue des modifications effectuées par le script Devstack, il ne doit être utilisé que sur une machine prévue à cet effet

Installation

Mise à jour des dépôts et des paquets déjà installés :

apt-get update

apt -y dist-upgrade

Installation de certains paquets nécessaire à l’exécution du script devstack :

apt install -y sudo vim vim-nox lynx zip binutils wget openssl ssl-cert ssh

apt install -y bridge-utils git python-pip

Mise à jour du gestionnaire de dépendance python :

pip install --upgrade pip

Installation de la dépendance python « os-testr » :

pip install -U os-testr

L'utilisateur « stack » et on vérifie que ses paramètres personnels sont corrects :

groupadd stack

useradd -g stack -s /bin/bash -d /home/stack -m stack

Configuration de « stack » :

echo "stack ALL=(ALL) NOPASSWD:ALL" > /etc/sudoers.d/50_stack_sh

chmod 440 /etc/sudoers.d/50_stack_sh

Clone du dépôt devstack dans /home/stack :

cd /home/stack

git clone https://git.openstack.org/openstack-dev/devstack

Changement de branche git pour sélectionner la version « ocata » d’OpenStack :

cd devstack

git checkout stable/ocata

Création du fichier de configuration « local.conf » :

echo '[[local|localrc]]' > local.conf

echo 'ADMIN_PASSWORD=stack' >> local.conf

echo 'DATABASE_PASSWORD=stack' >> local.conf

echo 'RABBIT_PASSWORD=stack' >> local.conf

echo 'SERVICE_PASSWORD=stack' >> local.conf

echo 'GIT_BASE=https://git.openstack.org' >> local.conf

echo 'USE_SCREEN=FALSE' >> local.conf

echo 'PIP_UPGRADE=True' >> local.conf

Changement de propriétaire du répertoire devstack :

chown -R stack.stack /home/stack/devstack

Enfin, on lance l’installation de devstack avec l'utilisateur « stack ». le script met environ 20 minutes pour effectuer les opérations d'installation :

su -l stack -c "cd devstack; ./stack.sh" 

En cas de problème lors de l’installation

En cas d’échec lors de l’installation, un script de nettoyage est intégré :

./clean.sh

Installation rapide

#!/bin/bash

apt-get update

apt -y dist-upgrade


apt install -y sudo vim vim-nox lynx zip binutils wget openssl ssl-cert ssh

apt install -y bridge-utils git python-pip


pip install --upgrade pip

pip install -U os-testr


groupadd stack

useradd -g stack -s /bin/bash -d /home/stack -m stack


echo "stack ALL=(ALL) NOPASSWD:ALL" > /etc/sudoers.d/50_stack_sh

chmod 440 /etc/sudoers.d/50_stack_sh


cd /home/stack


git clone https://git.openstack.org/openstack-dev/devstack

cd devstack


git checkout stable/ocata

echo '[[local|localrc]]' > local.conf

echo 'ADMIN_PASSWORD=stack' >> local.conf

echo 'DATABASE_PASSWORD=stack' >> local.conf

echo 'RABBIT_PASSWORD=stack' >> local.conf

echo 'SERVICE_PASSWORD=stack' >> local.conf

echo 'GIT_BASE=https://git.openstack.org' >> local.conf

echo 'USE_SCREEN=FALSE' >> local.conf

echo 'PIP_UPGRADE=True' >> local.conf


chown -R stack.stack /home/stack/devstack

su -l stack -c "cd devstack; ./stack.sh"

Accès à l’interface web

Une fois l’installation terminé, l’interface web Horizon est disponible via l’adresse : http://ipMachine.

Plus d’infos

https://docs.openstack.org/devstack/latest/

https://github.com/openstack-dev/devstack

https://gist.github.com/fjourdren/53637980e95b6779881e331cb3b6488b

https://lucasvidelaine.wordpress.com/installation-de-devstack/

Le principe est de découper l’application sous forme de ressource que les clients peuvent utiliser au travers de requêtes HTTP.

Cette architecture destinée aux systèmes distribués a été créé en 2000 par Roy Fielding dans sa thèse de doctorat.

L’intérêt d’une API REST est de rendre les ressources de l’applications utilisables par tous les composants de celle-ci. Cela permet de mettre en place des micro-services, de la portabilité, de donner accès à certaines fonctionnalités à des personnes extérieures…

Identification d’une ressource par l’URL

L’identification de chaque ressource doit se faire via une URL qui sera décomposée logiquement. Ainsi le nom d’une ressource doit comporter le « s » du pluriel pour indiquer que sans paramètres de filtrage, on affiche tous les éléments. Lorsque l’on filtre, on laisse le pluriel, en effet, on sous-entend que l’on cherche tous les éléments puis on renvoi seulement l’élément filtré.

Par exemple :

• http://exemple.com/books On récupère la liste de tous les livres.

• http://exemple.com/books/5 On récupère la liste des livres puis on filtre pour récupérer celui ayant l’identifiant 5.

On peut ensuite récupérer des ressources associés grâce à la même méthode :

• http://exemple.com/books/5/comments On récupère la liste des livres, on filtre celui ayant l’identifiant 5 puis on renvoi les commentaires lui étant associé.

• http://exemple.com/books/5/comments/6 On récupère la liste des livres, on filtre celui ayant l’identifiant 5, on renvoi les commentaires lui étant associé et on filtre celui ayant l’identifiant 6.

Utilisation des verbes http pour identifier une opération

Pour identifier l’action à effectuer sur une ressource, les verbes http disponibles sont les suivants :

• GET : Demande une représentation des ressources spécifiées.

• HEAD : Même chose que GET mais ne retourne que l’entête de la réponse.

• POST : Utilisé pour créer une ressource.

• PUT : Utilisé pour modifier une ressource.

• DELETE : Utilisé pour supprimer une ressource.

• CONNECT : Etablit un tunnel vers le serveur identifié par la ressource cible.

• OPTIONS : Utilisé pour décrire les options de communication vers une ressource visée.

• TRACE : Réalise un chemin aller/retour en suivant le chemin de la ressource visée.

• PATCH : Utilisé pour appliquer des modifications partielles à une ressource.

Par exemple pour créer un CRUD sur des livres :

• Créer : POST http://exemple.com/books

• Afficher : GET http://exemple.com/books/4

• Mettre à jour : PUT http://exemple.com/books/4

• Supprimer : DELETE http://exemple.com/books/4

La réponse représente la ressource

La réponse doit être compréhensible par tous les langages facilement dans le but qu’ils puissent reconstruire l’objet à l’arrivée. Le processus qui rend cela possible est la sérialisation et la déspécialisation des objets. Ainsi, les contenus peuvent être des objets, des tableaux et même des variables plus simples comme des booléens, des nombres, des chaines de caractère ou une valeur nulle.

Les formats de données les plus courants sont :

• JSON (JavaScript Object Notation)

• XML (Extensive Markup Language)

• YAML (Yet Another Markup Language)

• CSV (comma-separated values)

• INI

Exemple de représentation d’un objet en JSON :

{
    "name":"John",
    "age":30,
    "car":"Fiat"
}

Authentification pour accéder à une ressource

La limitation de l’accès à certaines ressources est essentielle dans une architecture d’API REST. L’une des problématiques est le fait que ce type d’architecture doit être basé sur des serveurs sans état, c’est-à-dire qu’il ne faut par exemple pas stocker les sessions sur les serveurs pour permettre au service d’être scalé facilement.

• Token de session stockée en base de données partagée

• Clé API

• JWT

• OAuth 2

Utilisation de l’URL pour donner plus de pouvoir sur la donnée

Les paramètres passés en URL peuvent être utile pour effectuer un traitement supplémentaire sur l’information, cette technique est le plus souvent utilisée sur les requêtes http GET. Par exemple, nous pouvons ajouter un élément « tri » qui permettra d’effectuer un ORDER BY sur les résultats. Nous pouvons aussi ajouter un système de page pour fragmenter les résultats si la ressource s’avère trop volumineuse.

http://exemple.com/books?filter=policier&tri=asc

http://exemple.com/books?filter=policier&tri=asc&page=4&elementPerPage=25

Plus d’infos

Traduction du chapitre 5 de la thèse de Roy Fielding :

http://opikanoba.org/tr/fielding/rest/

http://www.croes.org/gerald/blog/qu-est-ce-que-rest/447/

https://fr.wikipedia.org/wiki/Representational_state_transfer

https://developer.mozilla.org/fr/docs/HTTP/M%C3%A9thode

Le but de ce tutoriel sera de mettre en place le déploiement continu & automatique d’une application avec Jenkins sur une architecture Docker. Le déploiement continu & automatique est l’un des concepts clés du mouvement DevOps. Le but de la manœuvre est de favoriser l’industrialisation d’une application en permettant à un système : de tester l’application, de construire l’image du conteneur et de mettre celui-ci en production.

Prérequis :

• Docker
• Docker-compose

Fonctionnement

Notre système de déploiement utilisera 4 couches pour mettre en production l’application :

• Gogs : Plateforme d’hébergement privé de projet git (se présente sous la forme d’une interface web très proche de celle de GitHub). Gogs peut être remplacé par n’importe quel serveur git, en effet, nous l’utiliserons uniquement comme un dépôt.
• Jenkins : Jenkins utilisera un script appelé « Jenkins file » pour builder l’image du conteneur applicatif.
• Registre docker privé : Contiendra les images des conteneurs internes à notre système.
• WatchTower : Un worker va de manière régulière chercher à installer une image plus récente des conteneurs déployés.

Pour lancer un déploiement, il suffira de pousser du code sur gogs. Ce dernier enverra une alerte à Jenkins au travers d’un webhook. Jenkins va alors lancer un build de type « pipeline ». Il s’agit d’un script qui se découpe en plusieurs étapes (contenus dans le fichier Jenkinsfile). Nous créerons alors trois étapes, la première qui construira l’image docker du projet (à l’aide d’un fichier Dockerfile), la seconde lancera un conteneur temporaire avec l’image construite à l’étape précédente dans le but d’exécuter les tests unitaires et l’étape finale est de pousser l’image sur notre registre docker privé. L’étape finale est d’attendre que Watchtower détecte le changement sur l’image et remplace l’ancien conteneur par un conteneur mis à jour.

Mise en place de l'architecture Docker

Nous utiliserons un docker-compose pour mettre en place l’architecture dont nous aurons besoin.

Il nous faudra créer un Dockerfile (nous le placerons dans le fichier "/home/user/jenkins/Dockerfil"). Il aura pour but de créer une image d’un conteneur applicatif Jenkins modifié pour avoir accès à l’API Docker :

FROM jenkins
MAINTAINER Flavien JOURDREN <[email protected]>

USER root
RUN apt-get update -qq
RUN apt-get install -qqy apt-transport-https ca-certificates
RUN apt-key adv --keyserver hkp://p80.pool.sks-keyservers.net:80 --recv-keys 58118E89F3A912897C070ADBF76221572C52609D
RUN echo "deb https://apt.dockerproject.org/repo debian-jessie main" > /etc/apt/sources.list.d/docker.list
RUN apt-get update -qq
RUN apt-get install -qqy docker-engine

RUN usermod -aG docker jenkins

USER jenkins

Contenu du fichier docker-compose.yml :

version: '2'

services:

  mysql:
    image: mysql
    restart: always
    environment:
      - MYSQL_ROOT_PASSWORD=aCoolPassword
      - MYSQL_DATABASE=gogs
      - MYSQL_USER=root
      - MYSQL_PASSWORD=aCoolPassword
    volumes:
      - "/containersVolume/database:/var/lib/mysql"

  gogs:
    image: gogs/gogs
    restart: always
    links:
      - "mysql:db"
    ports:
      - "10022:22"
      - "10080:3000"
    volumes:
      - "/containersVolume/gogs:/data"

  jenkins:
    build: /home/user/jenkins
    restart: always
    ports:
      - "8080:8080"
      - "50000:50000"
    volumes:
      - "/containersVolume/jenkins:/var/jenkins_home"
      - "/var/run/docker.sock:/var/run/docker.sock"

  registry:
    image: registry
    restart: always
    ports:
      - "127.0.0.1:5000:5000"
    environment:
        REGISTRY_STORAGE_FILESYSTEM_ROOTDIRECTORY: /data
    volumes:
       - "/containersVolume/registry:/data"

  watchtower:
    image: v2tec/watchtower
    restart: always
    volumes:
      - "/var/run/docker.sock:/var/run/docker.sock"
    command: --interval 30 --cleanup

  application:
    image: localhost:5000/application
    restart: always

Exécution du fichier docker-compose.yml :

sudo docker-compose up -d --build

Configuration de Gogs

Gogs est un projet OpenSource développé en Go dont l’objectif est de créer un clone de github. L’intérêt est de pouvoir héberger des projets git sur un serveur interne à notre système. Par la suite, gogs nous permettra aussi de mettre en place des webhooks pour lancer des builds Jenkins automatiquement lors d’un push git.

Après l’installation de gogs, on crée ensuite le projet git privé qui contiendra les sources de l’application.

Configuration de Jenkins

Jenkins nécessitera au moins les plugins suivants : gogs, git, Docker et Docker Pipeline.

Pour récupérer le code source présent sur Gogs, nous devrons configurer des "credentials". Il s’agit d’un élément qui permet d’indiquer à Jenkins la façon de se connecter à un service externe, ici Jenkins se connectera avec notre compte gogs. Configuration du credential : Global credentials, Username with password.

On crée un projet jenkins de type Pipeline en ajoutant l’URL du projet git et en associant le credential.

Configuration du webhook

Le webhook va nous permettre de lancer un "build" Jenkins au moment où un push aura lieu sur le projet git. Pour ce faire il faut se rendre sur Gogs dans les paramètres du projet puis dans "webhook". Ensuite, il suffit d’insérer l’URL du hook Jenkins : http://<Jenkins server>:8080/<nom projet jenkins>-webhook/

Configuration de WatchTower

WatchTower est un projet OpenSource dont le but est de mettre à jour les images de conteneurs docker de manière automatique. Cela fonctionne avec un worker qui vérifie à intervalle réguliers’il existe une image plus récente dans le registre Docker associé.

L’ensemble des configurations possibles de Watchtower est disponible sur la page github : https://github.com/v2tec/watchtower

En réalité, l’intervalle de traitement et le nettoyage des images est déjà configuré, en effet nous l’avons déjà mis dans le docker-compose :

command: --interval 30 --cleanup

Création des fichiers Jenkinsfile et Dockerfile

Le fichier Jenkinsfile est le fichier exécuté par Jenkins lors de l’exécution du pipeline. Dans notre cas, il créera un conteneur qui servira à exécuter le Dockerfile de notre application, à effectuer des tests sur ce dernier et à pousser l’image sur le registre Docker.

Le Dockerfile permet d’automatiser la création d’image Docker. Il permet ainsi d’installer toutes les dépendances nécessaires au bon fonctionnement de l’application et à l’installation de cette dernière. De plus un Dockerfile peut hériter d’un autre Dockerfile ce qui permet de se baser sur des scripts déjà créés par la communauté.

Les fichier Jenkinsfile et Dockerfile seront poussés eux aussi sur le dépôt git et seront à la racine du projet.

L’exemple porte sur le déploiement d’une simple API en Javascript.

Jenkinsfile :

node {

	def app
	currentBuild.result = "SUCCESS"

	try {
		stage('Clone repository') {
			checkout scm
		}

		stage('Build image') {
			app = docker.build("test")
		}

		stage('Test image'){
			app.inside {
				echo 'test'
			}
		}

		stage('Push image') {
			docker.withRegistry('https://127.0.0.1:5000') {
				app.push("latest")
			}
		}
	}
	catch (err) {
		currentBuild.result = "FAILURE"
		throw err
	}

}

Dockerfile :

FROM node
MAINTAINER Flavien JOURDREN <[email protected] >

ADD . /home/node/app
WORKDIR /home/node/app

RUN npm install

CMD npm run start
EXPOSE 3000

Ce que le Dockerfile fait :

• « FROM node » : Hérite de l’image « node » créée par la communauté du registre publique docker hub.
• « ADD . /home/node/app » : Ajoute les fichiers de l’application dans le répertoire /home/node/app du conteneur.
• « RUN npm install » : Installe les dépendances npm.
• « CMD npm run start » : Démarre l’application à chaque démarrage d’un conteneur de cette image.
• « EXPOSE 3000 » : Expose le port 3000 du conteneur.

Mise en place final et tests

1. Pousser le code source à déployer sur la branche « production » du dépôt git distant.
2. Vérifier sur l’interface web de jenkins que le build a bien était lancé au travers du webhook.
3. Une fois le build de l’application terminé, on vérifie que l’image a bien été poussée sur le docker registry en consommant son API (pour vérifier : http://ipRegistry:5000/v2/_catalog).
4. Démarrage des conteneurs avec docker-compose.
5. Vérifier que les conteneurs déployés fonctionnent bien.
6. Repousser une nouvelle version sur la branche « production ».
7. Cette fois-ci, WatchTower sera capable une fois la construction de l’image terminée et celle-ci mise à jour sur le registre docker, de détecter les modifications et de mettre à jour les conteneurs de cette image.
8. Tester les dernières modifications de l’application.

La répartition de charge est l’un des concepts essentiels à la mise en place d’architectures capables d’absorber une charge importante et résistantes aux pannes. Il s’agit d’un ensemble de techniques permettant de distribuer une charge de travail entre différents ordinateurs d'un groupe.

Les domaines d’utilisation de la répartition de charge sont de plus en plus nombreux en particulier avec l’avènement du cloud et des architectures de données décentralisées. Ainsi ces techniques sont utilisées dans : les supercalculateurs, les services http à forte audience, les bases de données nécessitant un accès permanent, le bigdata, l’entrainement des réseaux neuronaux, etc...

L’ensemble des serveurs de traitements (appelés serveurs réels) et des répartiteurs de charges est appelé « serveur virtuel » (ou une ferme de serveurs).

La répartition de charge utilise des algorithmes dans le but de définir le serveur réel qui sera chargé de traiter la requête.

Couche 2 du modèle OSI : Il s’agit de la couche liaison du modèle OSI, il se base uniquement sur les adresses MAC pour appliquer son algorithme de répartition. Certaines solutions utilisant cette méthode sont capables de faire du routage à la volée. Utilisé par des équipements réseaux.

Couche 4 du modèle OSI : Il s’agit de la couche transport du modèle OSI, il se base uniquement sur l’adresse IP pour appliquer son algorithme de répartition. Exemple de logiciel utilisant cette méthode : HaProxy.

Couche 7 du modèle OSI : C’est la couche applicative du modèle OSI, l’algorithme de répartition pourra ainsi se baser sur des données de l’application. Exemple de logiciel utilisant cette méthode : Nginx.

Les sticky sessions

Certaines applications nécessitent des « sticky sessions », c’est-à-dire que les utilisateurs devront d’avoir toujours le même serveur de traitement dans le but de garder leur fichier de session accessible.

Pour faire ceci il y a deux méthodes, soit on utilise un algorithme de répartition par hachage source qui se basera sur une constante du client pour obtenir un serveur de traitement, soit on applique un algorithme plus classique mais on envoie au client un token qui indiquera lors des prochaines requêtes sur quel serveur est disponible la session, ainsi les requêtes suivantes seront automatiquement redirigées vers le bon serveur.

Certains services mettent en place des clusters capables de partager les données, ainsi, tous les serveurs du pool peuvent avoir accès aux fichiers de session et la problématique des sessions est descendue plus bas dans l’architecture du service.

Haute disponibilité

Le principe de la haute disponibilité est de mettre en place un « failover », lorsqu’un serveur est hors ligne et que le répartiteur de charge essaye de le contacter sans succès, la requête sera attribuée à un autre serveur réel.

La pondération

La pondération consiste à attribuer à chaque serveur réel un poids dans le but de lui donner plus ou moins de tâche à effectuer. L’utilité est de pouvoir avoir des modèles de serveurs différents mais de faire en sorte que chaque un d’entre eux soit utilisé selon sa capacité. Cette technique est compatible avec tous les algorithmes de répartition de charge.

Quelques projets de répartition de charge

Traefik est un répartiteur de charge développé spécifiquement pour les architectures modernes basées sur docker. Le principe est de rendre la répartition de charge automatique seulement en indiquant à quoi sert chaque conteneur.

Kong est un projet se basant sur nginx, ce qui lui permet d’avoir de très bonnes performances. Ce projet est construit pour la gestion centralisée d’un ensemble d’APIs (par exemple pour une architecture en micro-services).

ProxySQL est un projet qui a pour but de gérer la répartition de charge et la réplication des données entre plusieurs serveurs SQL.

Jenkins est un outil d’intégration continue Open Source développé en Java.

Ajout des dépôts pour installer Java 8

Ajout des dépôts :

echo "deb http://ppa.launchpad.net/webupd8team/java/ubuntu xenial main" | tee /etc/apt/sources.list.d/webupd8team-java.list

echo "deb-src http://ppa.launchpad.net/webupd8team/java/ubuntu xenial main" | tee -a /etc/apt/sources.list.d/webupd8team-java.list

Ajout du certificat de vérification des paquets :

apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys EEA14886

Mise à jour des dépôts :

apt-get update

Installation de Java 8

Installer le paquet de java 8 et accepter ses conditions d’utilisations :

apt-get install oracle-java8-installer

Installation de Jenkins

Nous utiliserons wget pour télécharger le .war de jenkins :

apt-get install wget

wget mirrors.jenkins.io/war-stable/latest/jenkins.war

Démarrer Jenkins

Démarrer Jenkins sur le port 8080 :

java -jar jenkins.war --httpPort=8080

Jenkins est alors disponible via un navigateur. Lorsque Jenkins est lancé grâce à cette commande, la console qui l’exécute devra forcément rester ouverte. Pour contrer ce problème, on utilisera « screen » pour faire fonctionner Jenkins en arrière-plan.

Jenkins en arrière-plan

Le logiciel « screen » permet de faire fonctionner des applications en arrière-plan.

Installation de screen :

apt-get install screen

Faire fonctionner Jenkins avec screen :

screen -dmS jenkins java -jar jenkins.war --httpPort=8080

A la suite de cette commande, Jenkins démarrera en arrière-plan et Jenkins deviendra de nouveau accessible sur le navigateur mais ne nécessitera pas de laisser une console ouverte.

Plus d'infos sur screen : https://doc.ubuntu-fr.org/screen

Cet article traitera de la procédure de mise en place d’un serveur MySQL Master-Master (et Master-Slave) avec un système de load balancing utilisant l’algorithme round robin (grâce à HaProxy).
Dans l’exemple nous aurons trois serveurs, un gérera la répartition de charge (qui se nommera SRV-LBSQL et aura l’adresse IP 10.0.0.100) et deux serveurs MySQL connectés l’un avec l’autre (ayant respectivement pour nom SRV-MYSQL01 et SRV-MYSQL02 et les adresses IPs 10.0.0.1 et 10.0.0.2). Chaque serveur MySQL traitera à tour de rôle une requête SQL. Les serveurs de base de données répliqueront les informations l’un à l’autre grâce à une technique de double relation Master-Slave.

Installation des services MySQL
Pour installer les deux serveurs, il suffit d’installer le paquet MySQL. Pour cela utiliser la commande :

apt-get install mysql-server

Configuration des serveurs MySQL
Préparation
Pour se connecter sur les bases de données, il faut avoir le paquet « mysql-client » installer sur la machine de connexion, puis on tape la commande :

mysql -u root –p MotDePasse –h localhost

On crée la base de données « bdd » sur les deux serveurs grâce à la requête :

CREATE DATABASE bdd;

Puis on crée une table de test sur le serveur 1 :

CREATE TABLE test (
    ID INT NOT NUL AUTO_INCREMENT,
    Test VARCHAR(100) NOT NULL,
    PRIMARY KEY (ID)
);

On crée un dump de la base et on l’envoi au serveur 2 :

mysqldump -u root -p bdd > bdd.sql
scp bdd.sql [email protected]:/root/

Sur le serveur 2 on exécute le dump sur la base de données :

mysql -u root -p bdd < bdd.sql

On modifie ensuite le fichier /etc/mysql/my.cnf des deux serveurs.

On met ces valeurs sur le serveur 1 :

bind-address=10.0.0.1
server-id = 1
log_bin = /var/log/mysql/mysql-bin.log
expire_logs_days = 10
max_binlog_size = 100M
binlog_do_db = bdd

Et on met ces valeurs sur le serveur 2 :

bind-address=10.0.0.2
server-id = 2
log_bin = /var/log/mysql/mysql-bin.log
expire_logs_days = 10
max_binlog_size = 100M
binlog_do_db = bdd

bind-address contient l’adresse IP du serveur, server-id doit contenir un id unique et binlog_do_db contient le nom de la base de données qui sera synchronisé. Log_bin, expire_logs_days et max_binlog_size sont eux des paramètres permettant de gérer des fichiers contenant l’ensemble des modifications de la base de données et qui serviront à la redondance.

Finalement on redémarre les services mysql des deux serveurs :

service mysql restart

La relation Master-Slave
La relation Master-Slave (ou relation Maitre-Esclave) est une relation dans laquelle chaque un des deux serveurs aura son rôle. Ainsi le serveur maitre recevra les requêtes de modification des données et de lecture et le serveur esclave répondra aux demandes de lecture et copiera les données présentes sur le serveur Maitre. Cette architecture permet de sauvegarder les données à deux endroits pour éviter leurs pertes.

Configuration du serveur maitre
Sur le serveur maitre, on ajoute la permission de se connecter au serveur maitre depuis le serveur esclave avec l’utilisateur ‘replicationuser’ :

GRANT REPLICATION SLAVE *.* TO ‘replicationuser’@’10.0.0.2’ IDENTIFIED BY ‘motDePasse’;

On prépare la base de données :

USE bdd;
FLUSH TABLES WITH READ LOCK;

Enfin on utilise la commande suivante :

SHOW MASTER STATUS;

Cette dernière va nous permettre de récupérer la « position » et le « File » qui permettront à notre esclave de se connecter.

Configuration de l’esclave
Sur le serveur esclave, on configure les informations pour lui permettre de se connecter au maitre :

CHANGE MASTER TO MASTER_HOST=’10.0.0.1’, MASTER_USER=’ replicationuser’, MASTER_PASSWORD=’ motDePasse’, MASTER_LOG=‘mysql-bin.000005’, MASTER_LOG_POS=107;

Enfin on démarre l’esclave :

START SLAVE;

Test
Il est possible de voir l’état de la connexion avec le master en exécutant sur l’esclave la commande suivante :

SHOW SLAVE STATUS;

Vous pouvez vous servir de cette commande pour vérifier que l’esclave arrive bien à contacter son maitre. Vous pouvez aussi insérer une donnée sur le maitre et vérifier qu’elle a bien été répliquée sur l’esclave.

La relation Master-Master
Dans la relation Master-Master (ou Maitre-Maitre), les deux serveurs peuvent lire et écrire dans la base de données et réplique les modifications de l’autre serveur. Pour mettre en place cette relation, il suffit de créer une relation Maitre-Esclave mais dans le sens opposé à celui créé dans la partie précédente.

Configuration du serveur maitre
Sur le serveur maitre, on ajoute la permission de se connecter au serveur maitre depuis le serveur esclave avec l’utilisateur ‘replicationuser’ :

GRANT REPLICATION SLAVE *.* TO ‘replicationuser’@’10.0.0.1’ IDENTIFIED BY ‘motDePasse’;

On applique les nouvelles permissions :

FLUSH PRIVILEGES;

On prépare la base de données :

USE bdd;
FLUSH TABLES WITH READ LOCK;

Enfin on utilise la commande suivante :

SHOW MASTER STATUS;

Cette dernière va nous permettre de récupérer la « position » et le « File » qui permettront à notre esclave de se connecter.

Configuration de l’esclave
Sur le serveur esclave, on configure les informations pour lui permettre de se connecter au maitre :

CHANGE MASTER TO MASTER_HOST=’10.0.0.2’, MASTER_USER=’ replicationuser’, MASTER_PASSWORD=’ motDePasse’, MASTER_LOG=‘mysql-bin.000005’, MASTER_LOG_POS=1678;

Enfin on démarre l’esclave :

START SLAVE;

Test
Il est possible de voir l’état de la connexion avec le master en exécutant sur l’esclave la commande suivante :

SHOW SLAVE STATUS;

Vous pouvez vous servir de cette commande pour vérifier que l’esclave arrive bien à contacter son maitre. Pour tester la réplication, on se connecte au serveur 2 et on y insère une valeur. Puis on se connecte au serveur 1 et on vérifie que la donnée a bien été répliquée.

Load Balancing HaProxy
HaProxy va nous permettre de partager le flux de requête SQL sur les deux serveurs grâce à la méthode du round robin (la requête 1 va sur le serveur 1 ; la 2 sur le serveur 2 ; la 3 sur le serveur 1 etc…). HaProxy permet de faire cela grâce à sa capacité à analyser et rediriger la couche Transport du modèle OSI (couche 4).

Installation
Pour installer haProxy :

apt-get install haproxy;

Si le paquet n’est pas trouvé, ajouter les dépôts :

echo deb http://httpredir.debian.org/debian wheezy-backports main | \
tee /etc/apt/sources.list.d/backports.list
curl https://haproxy.debian.net/bernat.debian.org.gpg | \
apt-key add –
echo deb http://haproxy.debian.net wheezy-backports-1.4 main | \
tee /etc/apt/sources.list.d/haproxy.list
apt-get update
apt-get install haproxy -t wheezy-backports\*

Configuration
On modifie ensuite la configuration du fichier « /etc/haproxy/haproxy.cfg » pour mettre en place le load balancing :

global
log /dev/log local0
log /dev/log local1 notice
chroot /var/lib/haproxy
stats socket /run/haproxy/admin.sock mode 660 level admin
stats timeout 30s
user haproxy
group haproxy
daemon
# Default SSL material locations
ca-base /etc/ssl/certs
crt-base /etc/ssl/private
# Default ciphers to use on SSL-enabled listening sockets.
# For more information, see ciphers(1SSL). This list is from:
# https://hynek.me/articles/hardening-your-web-servers-ssl-ciphers/
ssl-default-bind-ciphers ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AESGCM:RSA+AES:RSA+3DES:!aNULL:!MD5:!D$
ssl-default-bind-options no-sslv3
defaults
log global
# mode http
# option httplog
option dontlognull
timeout connect 5000
timeout client 50000
timeout server 50000
errorfile 400 /etc/haproxy/errors/400.http errorfile 403 /etc/haproxy/errors/403.http errorfile 408 /etc/haproxy/errors/408.http errorfile 500 /etc/haproxy/errors/500.http errorfile 502 /etc/haproxy/errors/502.http errorfile 503 /etc/haproxy/errors/503.http errorfile 504 /etc/haproxy/errors/504.http
listen mysql-cluster
bind *:3306
mode tcp
option mysql-check user haproxy_check
balance roundrobin
server SRV-MYSQL01 10.0.0.1:3306 check
server SRV-MYSQL02 10.0.0.2:3306 check

On redémarre le service haproxy :

service haproxy restart

Nous allons maintenant créer l’utilisateur « haproxy_check » sur les deux serveurs MySQL qui permettra à HaProxy de connaitre l’état du serveur SQL (pour le failover). Pour cela nous utiliserons la commande :

INSERT INTO mysql.user (Host,User) values (‘10.0.0.100′,’haproxy_check’);
FLUSH PRIVILEGES;

Puis nous créons sur les deux serveurs MySQL l’utilisateur avec lequel nous nous connecterons finalement, il devra pouvoir se connecter depuis le l’adresse du load balancer :

GRANT ALL PRIVILEGES ON *.* TO ‘haproxy_root’@’10.0.0.100’ IDENTIFIED BY ‘MotDePasse’ WITH GRANT OPTION;
FLUSH PRIVILEGES;

Test
Il n’y a plus qu’à tester le load balancing en se connectant et en se déconnectant plusieurs fois au serveur HaProxy.
Renvoi « 1 » :

mysql -u haproxy_root –pMotDePasse –h 10.0.0.100
SELECT @@server_id;

Renvoi « 2 » :

mysql -u haproxy_root –pMotDePasse –h 10.0.0.100
SELECT @@server_id;

Renvoi « 1 » :

mysql -u haproxy_root –pMotDePasse –h 10.0.0.100
SELECT @@server_id;

Vagrant est une solution Open Source créée pour la configuration automatique de machine virtuelle et de conteneur. Vagrant permet par exemple de configurer la quantité de ram, la quantité de CPU, les paramètres réseaux et le nom d’hôte. Il peut ensuite automatiquement exécuter des scripts de gestion de configuration (Ansible, chef, Puppet, etc…). Ces scripts vont permettre l’installation et la configuration des paquets via le protocole SSH. La première version est sortie le 8 mars 2010 et était développée par Mitchell Hashimoto et John Bender en Ruby.
Vagrant est par défaut compatible avec les services de virtualisations suivants :

• Virtual box
• Hyper-V
• Docker
• VMWare
• Amazon EC2

Il est possible d’ajouter des providers grâce à des plugins.
Installation

Pour installer Vagrant, il faut se rendre sur le site officiel (https://www.vagrantup.com/downloads.html), télécharger l’exécutable de votre système et l’exécuter. Le but est d’avoir accès à la commande « Vagrant » via la console (sur Windows il faudra donc ajouter Vagrant à votre « global path »).
Les commandes
Pour utiliser Vagrant il faut obligatoirement créer un « projet », ces derniers sont appelés « boxs ». Une liste de box partagé par la communauté est accessible sur le site http://www.vagrantbox.es/.

# lister les boxs présentent sur le système
vagrant box list
# ajouter une box
vagrant box add nom_de_ma_box url_de_la_box
# supprimer une box
vagrant box remove nom_de_ma_box
# finalisation du projet vagrant
vagrant package
# initialisation du projet vagrant
vagrant init nom_de_la_box
# Lancer la machine virtuelle
vagrant up
# Pour tester si la machine fonctionne, on se connecte en SSH
vagrant ssh

Configuration des machines virtuelles
La configuration du projet Vagrant se fait dans le fichier « vagrantfile ».
Voici quelques exemples de configurations :

nodes = [
    { :hostname => 'ex5web', :ip => '192.168.0.42', :box => 'precise32' },
    { :hostname => 'ex5db', :ip => '192.168.0.43', :box => 'precise32', :ram => 512 }
]
Vagrant.configure("2") do |config|
    nodes.each do |node|
    config.vm.define node[:hostname] do |nodeconfig|
        nodeconfig.vm.box = "precise32"
        nodeconfig.vm.hostname = node[:hostname] + ".box"
        nodeconfig.vm.network :private_network, ip: node[:ip]
        memory = node[:ram] ? node[:ram] : 256;
        nodeconfig.vm.provider :virtualbox do |vb|
        vb.customize [
            "modifyvm", :id,
            "--cpuexecutioncap", "50",
            "--memory", memory.to_s,
        ]
    end
    end
    end
    config.vm.provision "ansible" do |ansible|
        ansible.playbook = "playbook.yml"
    end
end

La partie « nodes » permet de configurer un tableau de machine à créer avec des variables personnalisées, ici, on configure leurs noms d’hôtes, leurs IPs, la RAM et l’image à utiliser.

nodes = [
    { :hostname => 'ex5web', :ip => '192.168.0.42', :box => 'precise32' },
    { :hostname => 'ex5db', :ip => '192.168.0.43', :box => 'precise32', :ram => 512 }
]

La partie centrale, « vagrant.configure » applique les paramètres du tableau de node indiqué auparavant et créait chaque machine avec les bons paramètres associés.

Vagrant.configure("2") do |config|
    nodes.each do |node|
        config.vm.define node[:hostname] do |nodeconfig|
        nodeconfig.vm.box = "precise32"
        nodeconfig.vm.hostname = node[:hostname] + ".box"
        nodeconfig.vm.network :private_network, ip: node[:ip]
        memory = node[:ram] ? node[:ram] : 256;
        nodeconfig.vm.provider :virtualbox do |vb|
            vb.customize [
                "modifyvm", :id,
                "--cpuexecutioncap", "50",
                "--memory", memory.to_s,
            ]
        end
    end
end

La partie « ansible » permet de configurer le playbook ansible à utiliser sur les machines précédemment créées.

config.vm.provision "ansible" do |ansible|
    ansible.playbook = "playbook.yml"
end

Gestion de configuration
Le principe de la gestion de configuration est d’avoir un script exécuté via SSH sur les machines virtuelles à la fin de la création de ces dernières par Vagrant. Dans cet exemple nous utiliserons Ansible comme gestionnaire de configuration. Pour plus d’info sur Ansible (voir l’article de présentation d’Ansible).

Vagrant.configure("2") do |config|
    #
    # Run Ansible from the Vagrant Host
    #
    config.vm.provision "ansible" do |ansible|
        ansible.playbook = "playbook.yml"
    end
end

La ligne « config.vm.provision "ansible" do |ansible| » indique que cette partie va utiliser le module Ansible de Vagrant.
La ligne « ansible.playbook = "playbook.yml" » indique à Vagrant quel script Ansible exécuté.

Conclusion
Vagrant permet de créer facilement un grand nombre de machines virtuelles et de conteneurs. Il compléte les gestionnaires de configuration qui eux, s’arrêtent à la configuration des services sur la machine et ne gère absolument pas la création des machines virtuelles. De plus la communauté est active et partage énormément de ressources.

Plus d’infos
https://www.vagrantup.com
https://www.synbioz.com/blog/vagrant_et_la_virtualisation_pour_faciliter_le_developpement
https://www.sitepoint.com/getting-started-vagrant-windows/
https://fr.wikipedia.org/wiki/Vagrant

Depuis quelques temps je m'intéresse à la blockchain Ethereum en particulier à la fonctionnalité de "Smart contract". Il s'agit d'un script qui est déployé sur la blockchain et que les mineurs exécutent en échange d'une somme d'argent variable en fonction du contenu du script. Mais pour tester ces smart contracts, il faut installer un réseau Ethereum privé. Ce tutoriel nécessite une compréhension minimal de la blockchain Ethereum et des systèmes de "Proof of work".

Le réseau sera constitué de trois éléments:

1. Ethereum core (il s'agit de la partie qui enregistre l'ensemble des informations de la blockchain et gère le protocole d'Ethereum).
2. Ethereum console (console pour lancer des commandes sur le réseau privé et notamment le démarrage des mineurs chargés d'exécuter les smart contracts et de valider les transactions).
3. Wallet client (le porte feuille qui permet de gérer les contrats et les Ethers).

Étape 1: Compilation de geth.

Geth est le programme contenant Ethereum core et Ethereum console. Tout d'abord, télécharger les sources depuis ici, puis installer golang et build-essential grâce à la commande :

sudo apt-get install -y build-essential golang

Pour build geth, il suffit de taper la commande :

make geth

Le programme qui a était compilé se situe dans "build/bin/geth".

Étape 2: Démarrage de Ethereum core.

Ethereum core est la base du réseau privé. A son démarrage, un fichier .ipc est généré, il s'agit d'un fichier contenant toutes les informations sur notre réseau, il va servir à relier Ethereum core à Ethereum console et au wallet client. Le démarrage se fait grâce à la commande :

./geth --dev --port 1250 --maxpeers 0 --datadir "data"

Étape 3: La console Ethereum.

Cette console s'attache à Ethereum core dans le but de contrôler le réseau. Pour démarrer la console Ethereum, taper la commande suivante dans une console linux tout en gardant Ethereum core en exécution.

./geth --dev attach ipc:data/geth.ipc

Puis créer les comptes qui serviront à tester les contrats dans la console Ethereum dorénavant ouverte.

personal.newAccount('choose-a-password');

Enfin on démarre un mineur qui nous servira à valider les transactions :

miner.start();

Arrêter le mineur :

miner.stop();

Étape 4: Installation du wallet en mode réseau privé.

Le wallet Ethereum se télécharge ici, il s'agit du client wallet classique d'Ethereum que nous démarrerons via une commande pour lui indiquer de se connecter sur notre réseau privé. Une fois l'installation terminée, lancer Ethereum core si il n'est pas déjà démarré pour permettre au wallet de se synchroniser dessus, puis ouvrir une nouvelle console linux tout en gardant Ethereum core et Ethereum console en exécution et taper la commande :

ethereumwallet --rpc go-ethereum/build/bin/data/geth.ipc

Étape 5: Commandes à exécuter à chaque démarrage du réseau privé.

./geth --dev --port 1250 --maxpeers 0 --datadir "data"

./geth --dev attach ipc:data/geth.ipc
miner.start();

ethereumwallet --rpc go-ethereum/build/bin/data/geth.ipc

Ansible est une solution open source de gestion de configuration qui se présente sous la forme d’un script qui effectue des actions définies par l’utilisateur via le protocole SSH sur une ou plusieurs machines. Elle permet d’automatiser des tâches comme des installations sur un grand nombre de machines tout en personnalisant les configurations.
Le logiciel possède de nombreuses extensions qui permettent de ne pratiquement jamais avoir recours à l’utilisation de commandes linux brutes dans les scripts. Tous ces modules permettent aussi à ansible de tester si il est nécessaire d’exécuter une tâche en fonction de l’état de la machine, ainsi si l’on indique de démarrer un processus mais qu’il est déjà démarré sur le serveur, ansible ne perdra pas de temps et passera à l’action suivante.
Cette solution permet par exemple d’installer automatiquement les services nécessaires à un serveur, passer du code en production automatiquement, etc…
Installation
L’installation d’ansible se fait via le gestionnaire de paquet :

sudo apt-get install ansible 

Puis il suffit de créer un dossier avec les fichiers et répertoires nécessaires à votre script.
Fonctionnement
Ansible s’articule autour de deux systèmes principaux les playbooks (composés des tâches ou « tasks ») et les hôtes (« hosts »). Les playbooks contiennent la liste des actions à effectuer et le fichier hôte contient la liste des serveurs regroupés par groupe.
Exemple d’un playbook :

—
– hosts: webservers
  sudo: yes
  tasks:
  – name: install packages
    apt: name="{{ item }}" update_cache="yes" state="present"
    with_items:
      – "git"
      – "nginx"
      – "php7.0"
      – "php7.0-mysql"
      – "php7.0-curl"
      – "php7.0-json"
      – "php7.0-cgi"
  – name: install php on nginx
    template: « src=nginx.conf dest=/etc/nginx/sites-available/default.conf »
    notify:
      – restart php7-fpm
      – restart nginx
      – name: Create symlink
    file: src=/etc/nginx/sites-available/default.conf dest=/etc/nginx/sites-enabled/default.conf state=link
…

Exemple de fichier « hosts » :

[servers_group1]
192.168.1.200
[servers_group2]
192.168.1.201

Autour de ces deux fichiers principaux, les créateurs d’Ansible ont ajouté d’autres fichiers permettant d’améliorer les scripts. Ainsi il a été ajouté les variables, les rôles, les templates, les événements, etc…
Les variables rendent la gestion de la configuration très simple.
Les rôles permettent de créer l’équivalent des fonctions en programmation.
Les templates sont des fichiers de configuration modifiés, lors de son appel, les variables nécessaires seront insérées dans le fichier final.
Les événements permettent d’effectuer des actions seulement lorsqu’une notification est envoyée par le fichier tâche, par exemple cela permet de redémarrer un service après avoir modifié sa configuration.
Exemple de la structure d’un script Ansible avec une organisation par rôle :

Bien entendu il s’agit d’un système de script, les exemples donnés plus haut ne peuvent donc pas représenter toutes les possibilités. Dans de prochains articles, je détaillerai le fonctionnement d’autres cas plus concrets.

Conclusion
Selon moi, Ansible est un outil incontournable dans la mise en production d’un service et dans la gestion d’un parc de serveur. De plus la solution possède son propre système de partage du contenu à la communauté nommé « Galaxy ». Néanmoins, Ansible peut être relativement difficile à prendre en main en particulier à cause de l’architecture des fichiers qui peut varier en fonction de l’utilisation des rôles et du manque de documentation sur certains points (comme la modification de la connexion SSH depuis une version récente).
Plus d’infos
http://docs.ansible.com/ansible

Le Remote est le système de sauvegarde réseau de Git. Ainsi, le site Github n’est ni plus ni moins qu’un gestionnaire de Remote avec une interface Web. La connexion se fera au travers du protocole SSH.

Installation de Git sur le serveur

sudo apt-get install git

Création de l’utilisateur Git

L’utilisateur « git » nous permettra d’interagir avec le dépôt distant.

sudo adduser –system –shell /bin/bash –group –disabled-password –home /var/git/ git

On change ensuite le propriétaire du répertoire « /var/git« , en effet il est créé au moment de l’installation de git et il est le répertoire home de l’utilisateur git.

sudo chown git:git /var/git

Configuration de l’accès SSH pour cet utilisateur
On génère la clé SSH de l’utilisateur git.

ssh-keygen -t rsa

Sélectionner le répertoire d’enregistrement par défaut des clés. Le fichier « id_rsa » contient la clé privé et le fichier « id_rsa.pub » contient la clé publique. Changer les droits d’accès à la clé privé et la clé publique.

sudo chmod 755 ~/.ssh
sudo chmod 600 ~/.ssh/id_rsa
sudo chmod 644 ~/.ssh/id_rsa.pub

Ensuite, on copie la clé publique vers un nouveau fichier « authorized_keys » et on modifie son droit d’accès.

cp ~/.ssh/id_rsa.pub /var/git/.ssh/authorized_keys
sudo chmod 644 ~/.ssh/authorized_keys

Test
Pour tester la connexion SSH, il suffit de se connecter sur l’utilisateur git avec un client SSH. Pour moi avec le client SSH via la commande :

ssh [email protected]

Création du dépôt

sudo mkdir /var/git/mon-depot.git
sudo cd /var/git/mon-depot.git
sudo git init –bare
sudo chown -R git:git /var/git/mon-depot.git

Ici, on créait le répertoire qui contiendra le projet, on initialise le projet git (l’argument –bare permet d’indiquer que le dépôt est vide) et on change le propriétaire du projet.

Clone et commit sur le Remote

git clone [email protected]:mon-depot.git

Un message vous indiquant que le dépôt cloné est vide s’affiche.

Aujourd’hui, les fournisseurs de boites mail ont tous des anti-spams. Certains se contentent de déplacer le mail dans un dossier « spam » mais d’autre supprime purement et simplement le mail. Pour contrer ce problème, les serveurs d’envois doivent montrer patte blanche.

Prérequis :

• Un serveur VPS linux avec accès à internet
• Un nom de domaine

Ici, nous utiliserons un VPS debian 7 et un domaine OVH.

Installation de postfix et de mailutils

Postfix sera notre serveur d’envoi de mail.

Installer Postfix :

Installation de postfix :

sudo apt-get install postfix

Pendant l’installation, on nous demande quel type de configuration on souhaite mettre en place. Choisir « Internet Site » qui est une configuration basique sans redirection vers d’autres serveurs. Puis il nous est demandé le nom de domaine du serveur.

Installer & Utilisation de mailutils :

Installation de mailutils :

sudo apt-get install mailutils

Ce paquet permet d’envoyer des mails via commande. Pour envoyer un mail :

echo "Contenu du mail" | mail -s "sujet du mail" [email protected]

Configuration :

Tout d’abord il est nécessaire de dire au VPS sur quel domaine il se trouve, pour cela taper la commande

sudo echo "domaine.com" > /etc/hostname

Redémarrer le service en tapant la commande :

sudo service hostname.sh start

Pour vérifier la prise en compte de la configuration taper la commande :

hostname

SPF

Qu’est ce que SPF ?

SMTP ne possède pas de dispositif permettant de s’assurer de l’identité de l’expéditeur. SPF (Sender policy frameword) vise donc a réduire les usurpations d’identités, en publiant dans le DNS un enregistrement de type TXT qui indique les adresses IP autorisés à utiliser le serveur SMTP. SPF est donc un système de vérification de l’expéditeur. Développer pour réduire les SPAM, il permet de vérifier qu’une adresse mail n’est pas usurpée.

Mise en place de SPF

La mise en place de SPF se fait dans le gestionnaire du nom de domaine. Pour OVH, il faut se rendre dans la partie « Zone DNS », cliquer sur le bouton « Ajouter une entrée », sélectionner le champs DNS de type SPF et entrer dans le champs « a » le nom de domaine. Une nouvelle entrée est alors ajouté ayant pour valeur :

v=spf1 a a:domaine.com -all

---

DKIM

Qu’est ce que DKIM?

DKIM (DomainKeys Identified Mail) est une norme d’authentification fiable du nom de domaine de l’expéditeur d’un courrier électronique. Elle constitue une protection efficace contre le spam et l’hameçonnage. DKIM utilise une signature cryptographique pour vérifier l’authenticité du domaine expéditeur.

Le serveur d’envoi dispose d’une paire de clef RSA et utilise la clef privée pour signer les emails sortants. La clef publique est diffusée via DNS à qui-veut vérifier la signature d’un email venant de ce serveur d’envoi. Le destinataire d’un email signé via DKIM ne verra pas la différence avec un email classique.

Mise en place de DKIM

Tous d’abord, il faut installer le paquet OpenDKIM grâce à la commande :

sudo apt-get install opendkim opendkim-tools

Ensuite, nous allons indiquer quel port utilisera OpenDKIM à postfix. Taper la commande :

sudo vi /etc/postfix/main.cf

et ajouter les lignes :

milter_default_action = accept

milter_protocol = 2

smtpd_milters = inet:localhost:12345

non_smtpd_milters = inet:localhost:12345

Pour indiquer le port que devra utiliser OpenDKIM, on ouvre le fichier « /etc/default/opendkim » et y remplacer le contenu par cette ligne :

SOCKET="inet:12345@localhost"

Celle-ci permet d’indiquer à OpenDKIM quel port il doit utiliser.

Créer le dossier « opendkim » à l’aide de la commande « mkdir /etc/opendkim », ce dossier contiendra certains fichiers de configuration et les clefs d’OpenDkim.

Puis il faut indiquer les hôtes de confiance dans le fichier « sudo vi /etc/opendkim/TrustedHosts » pour cela, ajouter la ligne :

*.domaine.com

Nous allons maintenant indiquer à OpenDKIM quel fichier clef doit être utilisé pour notre domaine, pour cela ouvrir le fichier « /etc/opendkim/KeyTable » à l’aide de la commande « sudo vi /etc/opendkim/KeyTable » et y ajouter la ligne : « mail._domainkey.domaine.com domaine.com:mail:/etc/opendkim/keys/domaine.com/mail.private ».

Nous allons assurer la liaison de chaque adresse e-mail vers son domaine correspondant, pour cela il faut ouvrir le fichier « sudo vi /etc/opendkim/SigningTable » et y entrer la ligne :

*@domaine.com mail._domainkey.domaine.com

mail._domainkey.domaine.com sera l’enregistrement DNS de DKIM.

Le dernier fichier d’open à modifier est « /etc/opendkim.conf ». Celui-ci va nous permettre de modifier les paramètres globaux de opendkim. Pour commencer, indiquer votre nom de domaine dans le champ « Domain », ensuite vérifier que le mode est bien sur « sv », le champ selector doit contenir le nom du sous domaine DNS DKIM (pour nous « mail._domainkey »), puis modifier le champ KeyFIle en :

/etc/opendkim/keys/domaine.com/private.private

Enfin, il faut indiquer à opendkim où se trouve les fichier créer précédemment à l’aide des lignes suivantes :

# Our KeyTable and SigningTable
KeyTable refile:/etc/opendkim/KeyTable
SigningTable refile:/etc/opendkim/SigningTable

# Trusted Hosts
ExternalIgnoreList /etc/opendkim/TrustedHosts
InternalHosts /etc/opendkim/TrustedHosts

Génération des clef DKIM

Nous allons maintenant générer la paire de clef DKIM grâce aux commandes suivantes :

cd /etc/opendkim/keys
mkdir domaine.com
cd domaine.com
opendkim-genkey -s mail -d domaine.com
chown opendkim:opendkim mail.private
cat /etc/opendkim/keys/domaine.com/mail.txt

Les données affichées sont celles qui devront être enregistrés dans l’enregistrement DNS DKIM.

Une fois les configuration terminé, redémarrer les service Opendkim et Postfix à l’aide des commandes :

/etc/init.d/opendkim restart
/etc/init.d/postfix restart

 

Enregistrement du champ DNS

Sur le panel d’administration d’OVH, se rendre dans la zone DNS et cliquer sur le bouton « Ajouter une entrée ». Sélectionner TXT et copier le contenu entre les guillemets dans le champ valeur. Ensuite, copier le nom du sous-domaine dans le champ sous-domaine d’OVH, pour nous « mail._domainkey ». Ces informations sont disponibles dans le fichier « /etc/opendkim/keys/domaine.com/mail.txt ».

---

MX

Qu’est ce que MX ?

MX (Mail eXchanger) permet de rediriger des emails en direction de votre serveur vers un autre domaine. Il s’agit donc d’un système pour la réception des emails. Néanmoins, il est conseillé de le mettre en place car il permet d’augmenter la note de confiance des anti-spams.

Mise en place de MX

Se rendre dans la zone DNS cliquer sur « ajouter un entrée », sélectionner MX, saisir la priorité 1 (priorité la plus haute) et l’adresse cible (notre nom de domaine). Vérifier sur la liste des champs DNS que cette ligne a bien était ajouté: type :

1 votredomaine.me.

---

Reverse DNS

Qu’est ce que le reverse DNS ?

Le reverse DNS (ou rDNS) est un système qui permet de transformer une adresse IP en nom de domaine. Il est nécessaire de le configurer sur notre serveur SMTP car certaines messageries mail bloques les messages envoyés depuis des serveurs sans rDNS (comme AOL).

Mise en place de reverse DNS

Installer DNSutils qui va nous permettre de tester le reverse DNS :

sudo apt-get install dnsutils

Pour mettre en place le reverse DNS il faut indiquer au VPS à quel domaine il appartient. Cela se fait dans l’interface administrateur OVH de notre VPS. Aller dans le menu « IP » en bas de la page, cliquer sur « Gérer mes IP », la liste des adresses IP du VPS nous est donné (une IPv4 et une IPv6). Cliquer sur les roues d’entées à droite de chaque IP, sélectionner le menu « modifier le reverse » et entrer le nom de domaine.

Pour tester le reverse DNS, retourner sur le VPS et taper la commande.

dig -x votreIP +short

Si votre nom de domaine s’affiche, alors la configuration fonctionne.

---

Tester le serveur SMTP

Avant de tester le serveur SMTP, nous allons le redémarrer à l’aide de la commande :

sudo /etc/init.d/postfix restart

Pour tester la note de confiance de notre serveur SMTP, il existe le site https://www.mail-tester.com

Le test créer une adresse temporaire à laquelle envoyer un Email via notre serveur SMTP. Il permet par exemple de vérifier les systèmes d’authentifications du nom de domaine (DKIM et SPF), si l’email passe spam assassin, la composition HTML de l’email, la présence du serveur sur liste noire mais aussi la présence de lien brisé dans le message. Au final le serveur testé est noté sur 10. Gmail obtient une note de 8/10. Attention ! les notes peuvent être variable en fonction du contenu du message, pour tester, il est donc conseillé d’envoyer un message relativement long comportant  un vrai message.

Mon serveur SMTP obtient une note de 10/10 au lieu de 1.7/10 avant la mise en place de SPF, DKIM, ReverseDNS et MX.

Sources

http://lea-linux.org/documentations/DKIM_SPF_Postfix

https://www.skyminds.net/serveur-dedie-ajouter-lauthentification-spf-sender-id-et-dkim-a-postfix-et-bind9-avec-opendkim/

Ce système permet de changer la langue du site à partir d’un menu. Il utilise les sessions pour stocker la langue lors d’un changement. Puis un middleware modifie la langue par celle stocké dans la session grâce à la fonctionnalité « setLocal » de Laravel et à la traduction de Blade.

Création du menu :

CSS :

.flag {
    width: 21px;
    height: 14px;
}

HTML :

<!– locale translation –>
<li class="dropdown">
    <a data-toggle="dropdown" class="dropdown-toggle" href="#"><img class="flag" src="{{ url(‘images/lang/’.Session::get(‘locale’).’.png’) }}" alt="{{ Session::get(‘locale’) }}"/><b class="caret"></b></a>
    <ul class="dropdown-menu flagMenu">
        <li><a href="{{ url(‘lang/en’) }}"><img class="flag" src="{{ url('images/lang/en.png') }}" alt="en"/></a></li>
        <li><a href="{{ url(‘lang/fr’) }}"><img class="flag" src="{{ url('images/lang/fr.png') }}" alt="fr"/></a></li>
    </ul>
</li>

Création de la route qui met en session la nouvel langue :

Route::get('/lang/{locale}', function ($locale) {
    Session::set('locale', $locale);

    if($_SERVER['HTTP_REFERER'])
        return redirect($_SERVER['HTTP_REFERER']);
    else
        return redirect('/');
});

Création du middleware :

Ajouter ce middleware sur toutes les routes à partir du fichier Kernel.php.

<?php

namespace App\Http\Middleware;

use Closure;
use Session;
use App;

class UserLocal
{
    /**
    * Handle an incoming request.
    *
    * @param  \Illuminate\Http\Request  $request
    * @param  \Closure  $next
    * @return mixed
    */
    public function handle($request, Closure $next)
    {

        if(!Session::has('locale'))
        {
            Session::put('locale', App::getLocale());
        }

        App::setLocale(Session::get('locale'));

        return $next($request);
    }
}

 

Utilisation des traductions :

Pour traduire son site grâce à ce système, on utilise ensuite le système de traduction intégré à Blade (https://laravel.com/docs/5.4/localization).

{{ trans('app.search') }}

 

Améliorations possibles :

- Utiliser les cookies au lieu des sessions.

- Détection du pays de l’utilisateur.

Git est un logiciel libre de versioning; chaque projet est un dépôt. Cet outil permet le travail collaboratif sur un même code. Il est notamment utilisé par la plateforme open source GitHub.

Vocabulaire :
Dépôt : Il s’agit d’un endroit où l’on va stocker les versions du code. Les dépôts peuvent être comparés à des projets.

Validation ou commit : Il s’agit d’une version du projet à un instant t.

Push : Permet l’envoi d’un ou de plusieurs commits à un dépôt.

Pull : Permet le téléchargement des commits sur un dépôt.

Fork : Le fork permet à toute personne ayant accès au dépôt contenant le projet de le cloner et d’y effectuer ses propres modifications.

Tree : Contient un commit, il décrit l’arborescence des sources, un objet arbre pointe vers plusieurs commits parents.

Branche : Chaque commit connaissant ses parents, il est alors possible de faire travailler deux équipes sur deux branches différents (la branche principal est master). Cela permet de créer deux versions du projet en parallèle. Il est ensuite possible de fusionner les deux branches pour mettre en commun le travail de chacun. Exemple : une branche dev et une branche production (master). Une fois que un commit de la branche dev est validé, les deux branches sont fusionnées et la branche principale possède donc les nouvelles fonctionnalités.

Merge : Il s'agit de la fusion de deux branches.

Stash : Est un espace de stockage local qui contient des modifications qui ne sont pas encore commit. Utile par exemple lors d'un changement de branche avec des modifications en attente.

Rebase : Permet de réécrire une partie de l'historique des commits.

cherry-pick : Permet d'ajouter un commit à une autre branche sans avoir à fusionner toute la branche du commit.

Commandes impératives :

Initialiser un projet git :

git init

Lister les globals de configuration :

git config –list

Configuration du pseudo :

git config –global user.name "votre_nom"

Configuration du mail :

git config –global user.email "[email protected]"

Statut des fichiers modifiés :

git status

Premier commit :

git add .
git commit –m "initial commit"

Commits suivants :

git add chemin_vers_mon_fichier
git commit -m "message du commit"

Modifier le commit précédent :

git commit --amend

Voir l'historique des commits :

git log

Voir l'historique des commits (sur une ligne) :

git log --oneline

Voir les branches sous la formes d'un schéma :

git lg

Voir les différences par rapport au dernier commit :

git diff

Faire revenir un fichier à un ancien commit :

git checkout <commit> <fichier>

Revenir à un commit précédent (en ajoutant les fichiers modifiés au staging) :

git reset <commit>

Revenir à un commit précédent (en supprimant les fichiers du staging) :

git reset <commit> --hard

Créer un commit inverse à celui indiqué :

git revert <commit>

Rebase d'une branche :

git checkout <commit>
git rebase master

Rebase intéractif :

git rebase -i <commit>

Le rebase intéractif fonctionne avec un système de scipt. Lors de l'exécution de la commande, une nouvelle fenêtre est ouverte et il est alors possible d'effectuer ces actions sur chaque commit :

• pick : Utilise le commit
• rework : Permet de modifier le message du commit.
• edit : Permet de modifier le message du commit et son contenu.
• squash : Fusionne le commit au précédent.
• fixup : Comme squash mais permet de modifier le message du nouveau commit.
• exec : Permet d'exécuter une commande shell.

Supprimer un fichier du répertoire de travail et de l’index :

git rm nom_du_fichier

Lister les branches :

git branch

Créer une branche :

git branch nom_de_ma_branch

Changer de branche :

git checkout nom_de_ma_branch

Suppression d’une branche :

git branch -d correctif

Ajout des modifications de la branche dev à la branche master :

git checkout master
git merge dev

Cherry-pick un commit sur la branche master :

Le cherry-pick permet de fusionner un commit d'une branche 1 sur une branche 2. Cela permet de faire avancer la branche 1 avec un commit de la branche 2 sans pour autant récupérer tous les commit de la branche 2.

git checkout master
git cherry-pick c90fd66

Mise en place d'un stash :

git stash

Mise en stash même des fichiers non traqué :

git stash -u

Liste des stashs :

git stash list

Voir les modifications d'un stash :

git stash show stash@{0} [-p]

Appliquer un stash :

git stash apply stash@{0}

Supprimer un stash :

git stash drop stash@{0}

Appliquer un stash en le supprimant :

git stash pop stash@{0}

Lister les dépôts distants déjà configurés :

git remote -v

Ajout d’un dépôt distant :

git remote add nomDuRemote https://github.com/user/repo.git

Suppression d’un dépôt distant :

git remote rm nomDuDepot

Récupération des modifications de la branche courante sur un dépôt distant sans merge (création d’une nouvelle branche) :

git fetch VotreRemote

Récupération des modifications de la branche courante sur un dépôt distant :

git pull VotreRemote

Envoyer ses commits vers le dépôt distant :

git push VotreRemote Branche

Cloner un dépôt distant :

git clone git://github.com/user/repo.git

Documentation supplémentaire :

https://git-scm.com/book/fr/v1/Les-bases-de-Git-Travailler-avec-des-d%C3%A9p%C3%B4ts-distants

https://git-scm.com/documentation