Voilà bien un outil pratique qui permet de tester vos rôles Ansible ! Ansible a pris tellement d’importance qu’il est indispensable de s’assurer de la validité et de l’idempotence des rôles. Molecule vous aide à tester vos rôles en enchainant des étapes pénibles comme la création de l’environnement de test, l’application des rôles, la vérification des résultats (que vous pouvez aussi exprimer à l’aide de Playbooks !), puis le test d’idempotence et enfin le grand nettoyage !

Cet article décrit la solution de containerisation Singularity qui propose une solution adapteé à l’usage des containers principalement sur les clusters de calcul (HPC). Par opposition à Docker, aucun démon n’est nécessaire, aucun privilège « root » n’est requis…

Recopiez le fichier *.crt et le fichier *.key « aux bons endroits » et voilà !

Attention, lors de la 2ème étape vous devrez donner le nom du serveur : indiquez bien le nom attendu par l’application cliente, sinon utilisez les extensions (voir le fichier openssl.cnf) qui permettent d’ajouter des subjectAltName.

Pour configurer les variables d’environnement avec un démon géré par systemd, créez le répertoire /etc/systemd/system/docker.service.d puis ajoutez le fichier proxy.conf contenant la définition des variables d’environnement. Par exemple :

[Service]
Environment="HTTP_PROXY=http://mon_proxy:3128"
Environment="HTTPS_PROXY=http://mon_proxy:3129"
Environment="NO_PROXY=localhost,127.0.0.1,172.17.0.1,172.30.1.1"

Puis exécutez les commandes suivantes :

# systemctl dameon-reload
# systemctl restart docker

et un petit test….

$ docker search ubuntu

Attention :

• si votre proxy utilise un certificat auto-signé, vous devrez rajouter l’option suivante dans la configuration du démon

--insecure-registry proxy:port

• si votre proxy utilise un certificat signé par une CA, exécutez les commandes suivantes :

$ sudo cp mon_cert.crt /etc/pki/ca-trust/source/anchors

$ sudo update-ca-trust extract

Quel est le problème ?

Vous savez bien que lors d’un changement de clés côté serveur, le client va devoir valider l’empreinte de la nouvelle clé, ce qui risque de surprendre l’utilisateur consciencieux qui va se croire victime d’une attaque Mitm !

Avec la nouvelle version de OpenSSH, plus de risque d’apeurer vos utilisateurs ou clients.

La solution :

• générez vos nouvelles clés sous /etc/ssh/, avec l’algorithme ecdsa sur 521 bits par exemple:

  # ssh-keygen -t ecdsa -b 521

• ajoutez les nouvelles directives HostKey après celles qui existent déjà
• demandez aux utilisateurs d’ajouter l’option « UpdateHostKeys yes » (ou « ask ») dans la configuration de leur client SSH ou bien d’ajouter cette option. Par exemple:

  $ ssh -o UpdateHostKeys=ask serveur

• lors de la connexion au serveur, le client SSH va aspirer toutes les clés du serveurs et mettre le fichier known_hosts à jour
• après un « certain temps », estimant que tous les utilisateurs ont aspiré les nouvelles clés, il ne reste plus qu’à l’administrateur qu’à supprimer les anciennes clés !

1. La commande pip :
   en ligne de commande, ajoutez les options suivantes :

   --proxy http://<login>:<user>@<proxy>:<port> --trusted-host pypi.python.org

   ou bien dans votre fichier pip.conf, ajoutez les paramètres suivants :

   [global]
   proxy = http://<user>:<password>@<proxy>:<port>
   trusted-host = pypi.python.org
   

2. La commande yum :
   dans le fichier /etc/yum.conf, ajoutez les paramètres suivants :

   proxy=http://<proxy>:<port>
   proxy_username=<user>
   proxy_password=<password>
   

3. La commande docker :
   il faut définir les variables d’environnement http_proxy et https_proxy avant de lancer le démon. Par exemple dans le fichier /etc/sysconfig/docker.