QTH – Le blog de Fanch

SWL à mes heures perdues – Quick Troll Hosted

glory
walk-hoary

Home assistant supervised sur Raspberry Pi

Nov 5

Publié par Fanch dans Non classé | Aucun commentaire

Je vous détail dans cet article l’installation de Home-assistant supervised dans un container sur RaspberryPi.

Introduction

Home assistant peut être installé de 4 façon différentes :

  • Hassio OS : Vous utilisez leur système d’exploitation (basé sur alpine)
  • Container : Vous lancez home assistant dans un docker à partir d’un docker-compose
  • Supervised : Vous installez les services de gestion sur votre débian qui s’occuperont de configurer les containers
  • Core : Vous installez tout à la main (python)

J’ai choisis de m’appuyer sur leur manager supervised, les 2 grands interrêts que je vois sont que j’ai la main sur le container où tournera supervised, et qu’il me permet d’installer des add-ons facilement.

Cela signifie que Home-assistant tournera dans des containers dockers géré par supervised qui tournera dans un container LXC de mon Raspberry Pi.

Je pars du principe que vous avez déjà un Raspberry Pi fonctionnel avec une interface bridge (pour des raisons précisés ici).

Installation de LXC et création d’un container attaché au réseau

Installation LXC :

apt-get install lxc

Création du container qui accueillera supervised de Home-assistant :

lxc-create -t download -n homeassistant -- -d debian -r bookworm -a arm64

On édit la configuration du container pour qu’il soit attaché au bon réseau avec l’ip 10.35.7.10, pour cela, on édit le fichier /var/lib/lxc/homeassistant/config ainsi :

lxc.net.0.type = veth
lxc.net.0.link = br357
lxc.net.0.flags = up
lxc.net.0.ipv4.address = 10.35.7.10/24
lxc.net.0.ipv4.gateway = 10.35.7.254

On lance le container et on s’attache dessus :

lxc-start homeassistant

lxc-attach homeassistant

Installation de supervised

A partir d’ici, on est dans le shell du container « homeassistant » (voir commande lxc-attach) qui lancera supervised. On installe les dépendances :

apt install apparmor cifs-utils curl dbus jq libglib2.0-bin lsb-release network-manager nfs-common systemd-journal-remote systemd-resolved udisks2 wget -y

On installe docker :

curl -fsSL get.docker.com | sh

On installe os-agent :

wget https://github.com/home-assistant/os-agent/releases/download/1.6.0/os-agent_1.6.0_linux_aarch64.deb
apt install ./os-agent_1.6.0_linux_aarch64.deb

On Installe les dépendances pour supervised :

wget -O homeassistant-supervised.deb https://github.com/home-assistant/supervised-installer/releases/latest/download/homeassistant-supervised.deb
apt install ./homeassistant-supervised.deb

Répondez quemu-aarch64 quand il vous demandera l’architecture. Attendez quelques minutes qui supervised démarre les instances home-assistant.

Vous pouvez vous rendre sur la page http://10.35.7.85:8123 comme indiqué dans la console, il vous sera proposé de configurer Home-assistant à travers un assistant web.

Remarques

En utilisant Supervised de Home-assistant dans un container LXC, certaines technos ne seront pas compatibles. J’en ai relevé 3 et restent facultatives sans retirer des fonctionnalités à Home-assistant :

  • cgroup v1 (on est en v2)
  • NetworkManager
  • Apparmor

J’ai pu configurer NetworkManager, mais je ne pense pas que cela soit nécessaire. J’ai tout de même eu le problème de « homeassistant.components.hassio.handler.HassioAPIError: 'HomeAssistantCore.update' blocked from execution, no host internet connection« , alors que j’arrive à pinguer depuis le container et même depuis chaque docker…

J’ai réglé ce souci en bypassant ce check avec la commande suivante dans le container lxc :

ha jobs options --ignore-conditions internet_host

En faisant cela, vous aurez une autre alerte ce qui est normal : Ignored job conditions

Communiquer entre l’hôte et les containers LXC

Nov 4

Publié par Fanch dans GNU/Linux, Internet, Réseau | Aucun commentaire

Aujourd’hui j’utilise un Raspberrry Pi comme routeur chez moi. Il me permet de me passer de la box internet et d’isoler les équipements de mon réseau avec des VLAN.

J’ai dans l’optique de rassembler différents services sur un seul hôte afin de réduire le nombre d’appareils, en commençant par Home-assistant et le système de routage/DHCP. Plus tard, ce sera d’autres service comme tvheadend qui permet de broadcaster la TNT reçue à mon domicile par une clé USB vers un serveur multimédia Jellyfin dans le cloud.

Quel hyperviseur sous Raspberry Pi ?

Pour cela, je me suis penché sur docker, mais cela ne me satisfait pas entièrement à cause des contraintes au niveau réseau qui sont souvent mal documenté ou géré par les mainteneurs des images. Proxmox était pour moi le candidat idéal, mais non supporté sur ARM64. Je me suis donc tourné vers LXC qui est la couche de conteneurisation utilisé par Proxmox. A noter que LXD convient également, il s’agit d’une implémentation plus évoluée de LXC, mais la direction de l’éditeur LXD me semble floue et incertaine et ne l’ai donc pas utilisé.

Un réseau simple

Un point important dans l’architecture est que je veux avoir accès aux différentes couches et d’une façon la plus naturelle possible, c’est à dire se rapprochant d’une architecture matérielle. Je trouve cela beaucoup plus facile à se le représenter et à l’exploiter, surtout si je dois y intervenir rarement.

Je veux par exemple, me connecter en SSH sur le RaspberryPi et rebondir en SSH sur différents containers. Et bien sachez que ce n’est pas possible naturellement sous docker ou LXC, il vous faudra créer une interface macvlan pour chaque container sur vôtre hôtes. Ça me parait beaucoup et ajoute une complexité à l’architecture que je ne veux pas.

Solution

La solution que j’ai trouvé est de se baser sur des interfaces bridges. Ainsi, les containers sont capables de communiquer avec l’extérieur mais surtout avec l’hôte.

Voici la configuration réseau du Raspberry Pi. Avec ceci, vous pourrez utiliser les liens habituels VETH avec LXC.

# /etc/network/interfaces.d/eth0
auto eth0
iface eth0 inet static
        address 192.168.0.1/24

# /etc/network/interfaces.d/br7
auto eth0.7
iface eth0.7 inet manual

auto br7
iface br7 inet static
        bridge_ports eth0.7
        bridge_fd 0
        bridge_maxwait 120
        address 10.35.7.1/24

Note : eth0.7 est une syntaxe qui vous permet d’avoir une interface qui ne communiquera qu’avec le traffic tagué VLAN 7. (Au même titre que eth0:1 vous permet d’avoir une nouvelle interface alias de eth0)

Tags: ,

Installation la dernière version Firefox sous Debian

Juin 25

Publié par Fanch dans Non classé | Aucun commentaire

Par défaut, sur les versions stables et testing, c’est Firefox-ESR qui est installé. Je vous explique ici comment installer à la place, la dernière version courante grâce aux dépôts officiels Debian.

Ici, nous nous appuierons sur le dépôts unstable de Debian en les passant à une priorité faible afin qu’il ne passe pas notre système en unstable. Puis nous installerons Firefox en précisant vouloir utiliser ce dépôt.

Lets go!…

Désinstallez firefox-esr

# apt remove firefox-esr*

Ajoutez les dépôts instables de chez Debian

# echo "deb http://deb.debian.org/debian/ unstable main contrib non-free" | tee /etc/apt/sources.list.d/debian-unstable.list

Passez cette source unstable en faible priorité

# cat <<EOF tee /etc/apt/preferences.d/99pin-unstable
Package: *
Pin: release a=stable
Pin-Priority: 900

Package: *
Pin: release a=unstable
Pin-Priority: 10
EOF

Installez Firefox

# apt update
# apt install -t unstable firefox firefox-l10n-fr

Tags: ,

GITLAB : npm ERR! 404 ‘@test/api@1.0.0’ is not in the npm registry.

Jan 6

Publié par Fanch dans GNU/Linux | Aucun commentaire

Voici sur quoi je tombe en faisant un npm publish !

Si vous êtes sûr de votre procédure, et que vous utilisez un reverse-proxy NGINX devant votre gitlab, alors vérifiez cela :

Vous avez un slash à la fin de votre proxy_pass sous nginx ? Retirez-le !

Analyses

J’utilise un serveur GITLAB pour gérer le dépots des NPM (il sait aussi faire GO, PIP, Nugget, Docker…). C’est très pratique la pour CD-CI puisqu’on n’a pas à gérer des credentials, des hooks par rapport à un système de CI/CD dédié (jenkins).

Ce GITLAB est configuré en HTTP (son nginx est désactivé), et une autre machine fait reverse proxy HTTPS en frontale. La partie SSH+GIT est lié à une autre ip dédiée.

Après avoir vérifié et refait la procédure NPM avec GITLAB 20 fois, je finis par tester avec l’instance en ligne gitlab.com : pas de problème, ça fonctionne.

Je teste sur une autre instance gitlab auto-hébergée : pas de problème non plus !

Je compare les configs, aucune différence notable.

Analyse des logs gitlab entre un serveur qui fonctionne et un autre qui fonctionne pas, je m’aperçoit que l’URL a une partie différente : « %2f » sur l’un et « / » sur l’autre.

Je compare les configs NGINX, aucune différence notable.

Je suspecte tout de même le reverse proxy de modifier ma requête. Je lance donc un tcpdump pour le vérifier et constate que ma requête reçue par nginx :

PUT https://gitlab.qth.fr/api/v4/projects/8/packages/npm/@test%2fapi

est renvoyée avec une url modifiée :

PUT https://gitlab.qth.fr/api/v4/projects/8/packages/npm/@test/api

Du coup, effectivement, cette URL n’existe pas sous gitlab, et ce dernier renvoi un 404.

A noter que si vous n’avez pas l’autorisation ou que le scope (ici @test) est pas correcte, vous obtiendrez une erreur 400 de la part de GITLAB. (ou 403 si vous tentez d’écraser une version déjà présente), mais pas 404.

A savoir : gitlab redirige par defaut vos demandes vers le registry npmjs officiel si il ne connait pas le package. Cela peut etre assez pratique pour gérer plus globale le registry à utiliser sur un poste de dev ou un serveur puisqu'il n'y en a qu'un. (et non plus un par scope, avec son credential à prévoir).

Tags: , , , ,

Wildcard letsencrypt

Sep 22

Publié par Fanch dans Aide mémoire, GNU/Linux, Internet, Tutoriel | Aucun commentaire

Cet article vous présente comment générer un wildcard letsencrypt avec validation automatique par DNS.

Si vous l’avez déjà créé en manuel, comme moi la première fois, voyez la note « Vous avez déjà créé votre certificat en manuel ».

Voici l’environnement :

  • Un reverse-proxy qui fait terminaison SSL sous nginx 1.14
  • Un serveur DNS sous BIND9

Principe de fonctionnement

Pour valider un wildcard, letsencrypt va vérifier la présence d’une entrée TXT dans votre zone DNS au moment de la création/renouvellement du certificat.

Cette entrée TXT est ajoutée par la commande certbot car on lui aura autorisé la mise à d’un champ TXT précis via BIND. Cela peut être fait à la main de façon interactive (–manual), je ne vous le conseille pas.

Pour cela, nous allons créer une clé sur notre serveur BIND et configurer la zone pour qu’elle permette de mettre à jour une entrée TXT précise de la zone.

Cette clé sera donnée au client certbot sur notre reverse-proxy (dans un fichier credential) au moment de la création du certificat.

Configation de BIND

Sur le serveur BIND, créez une nouvelle clé, elle servira pour mettre à jour vos TXT de challenge letsencrypt. (ici certbot est le nom de la clé)

cd /etc/bind
dnssec-keygen -a HMAC-SHA512 -b 512 -n HOST certbot.

Cela va générer deux fichiers : Kcertbot.+NNN+YYYYY.key et Kcertbot.+NNN+YYYYY.key (les deux contiennent la clé, ils ne servent qu’à vous, et pourraient même être supprimés)

Collez les 4 lignes suivantes dans /etc/bind/named.conf en remplaçant XXXxXxXVOTRECLE== par votre clé contenu dans un des deux fichiers précédents.

key "certbot." {
  algorithm hmac-sha512;
  secret "XXXxXxXVOTRECLE==";
};

Ajoutez les lignes suivantes à votre configuration de zone DNS (sous debian : /etc/bind/named.conf.local) en remplaçant example.com par votre domaine.

zone "example.com" {
  [...]
  update-policy {
    grant certbot. name _acme-challenge.example.com. txt;
  };
};

Redémarrez bind avec

systemctl restart bind9

Configuration sur le reverse-proxy

Vous devez installer le paquet python3-certbot-dns-rfc2136 qui est une extension pour permettre à certbot de modifier votre zone DNS pour faire vérifier le challenge. Il en existe d’autres si vous avez des zones sur d’autres systèmes (OVH, gandi, cloudflare…)

apt install python3-certbot-dns-rfc2136

Créez un fichier qui contiendra les credentials pour certbot dans /etc/letsencrypt/dns-rfc2136-credentials-bind.ini et collez la configuration suivante en remplaçant IP_OR_DNS_OF_BIND et XXXxXxXVOTRECLE== votre hôte DNS et votre clé crée dans la section précédente.

dns_rfc2136_server = IP_OR_DNS_OF_BIND
dns_rfc2136_port = 53
dns_rfc2136_name = certbot.
dns_rfc2136_secret = XXXxXxXVOTRECLE==
dns_rfc2136_algorithm = HMAC-SHA512

Puis rendez le fichier non lisible par autre que root.

chmod 700 /etc/letsencrypt/dns-rfc2136-credentials-bind.ini

Création du certificat sur le reverse-proxy

certbot certonly --dns-rfc2136 --dns-rfc2136-credentials /etc/letsencrypt/dns-rfc2136-credentials-bind.ini -d *.example.com

Vous avez déjà créé votre certificat en manuel ?

Si vous avez déjà créé votre certificat de façon interactive (avec l’option –manual de certbot) donc sans l’avoir fait avec une clé bind, pas de pannique ! Vous devez tout de même suivre cet article jusqu’à l’étape de création de certificat que vous pouvez remplacer par un renouvellement de vos certificat (cerbot renew)

Voici ce que vous devez mettre dans votre fichier cat /etc/letsencrypt/renewal/example.com.conf

[...]
[renewalparams]
[...]
authenticator = dns-rfc2136
dns_rfc2136_credentials = /etc/letsencrypt/dns-rfc2136-credentials-bind.ini

Vous devriez pouvoir lancez votre certbot renew…

Remarques

Voici quelques infos à savoir sur letsencrypt que je n’ai eu que tard :

Le renouvellement (certbot renew) se fait uniquement sur les certificats expirant à J-30. (les certificats sont signés pour 90 jours).
Ne pas oublier de révoquer un certificat avant de la supprimer pour éviter les alertes d'e-mails d'expiration envoyées par letsencrypt (certbot revoke --cert-path /etc/letxencrypt/live/example.com/cert.pem)
Évitez de créer des certificat pour des domaines différents, le renouvellement échouera si un seul domaine ne fonctionne pas.

Syncthing

Mai 26

Publié par Fanch dans Non classé | Aucun commentaire

Synchroniser des répertoire n’importe où et avec n’importe quoi.

Syncthing est un logiciel qui vous permet de synchroniser un répertoire avec une autre instance de syncthing en peer to peer sans ouvrir de ports. Il tourne en tâche de fond, et permet beaucoup d’option pour couvrir un tas de cas d’utilisation. En voici quelques uns :

  • Avoir une sauvegarde de votre disque d:\ sur un nas avec rétention des données sur 30 jours
  • Avoir un mirroir de vos photos ou traces GPS de votre smartphone sur votre pc uniquement par le wifi
  • Partager des documents d’un événement avec 3 autres bénévoles d’une association en limitant la bande passante sortante
  • Partager en lecture seule votre bibliothèque de musique avec un ami

Voici son interface de gestion, il s’agit d’une simple page web. Cela signifie que vous pouvez l’installer n’importe où, un navigateur suffit pour le configurer.

https://syncthing.net/img/screenshot-dark.png
Interface de contrôle

Principe de fonctionnement

Syncthing fonctionne avec 2 niveaux d’association : association d’appareil (nous parlerons d’instance de syncthing) et association de dossier (nous parlerons de partage). Avant de partager quelque chose avec une autre instance, vous devez d’abord associer votre 2 instances.

L’identifiant d’instance

Il s’agit ‘est votre identifiant unique à votre instance. C’est grâce à elle que les autres instance vont vous trouver et demander de s’associer. L’association ne peux se faire que si les 2 personnes ont acceptées (l’un fait la demande en entrant l’identifiant, l’autre doit accepter via une notification sur l’interface de gestion).

Cet identifiant est un chaine de caractère, et peut être affiché sous forme de qrcode pour une facilité d’association avec un smartphone. Si vous êtes sur le même réseau, votre instance peut vous la proposer au moment d’associer une nouvelle instance.

L’identifiant de partage

Ils permettent d’identifier un partages parmi votre instance mais également parmi toutes les instances auxquels vous êtes associé. L’identifiant de partage devrait toujours être unique pour ne pas rentrer en conflit avec un partage d’une autre instance.

Le partage

Une fois que vous avez associé votre instance à une autre et défini un partage, vous pouvez choisir avec quelle instance vous souhaitez associer votre partage.

Réglages

Plusieurs options existent également pour contrôler et affiner comment est fait le partage :

  • Choisir ou non une rétention des fichiers sur une durée, un nombre de version ou même en appelant un script
  • Exclure des fichiers
  • Faire un partage qu’en envoi, en réception ou les deux
  • Limiter l’occupation disque

D’autres option existent au niveau de l’association avec un autre instance :

  • Limiter la bande-passante montante / descendante
  • Imposer une adresse ip fixe (réseau local uniquement par exemple)
  • Mode « appareil introducteur ». A éviter en général. Cela permet d’associer automatiquement d’autres instances sans les avoir validé ; on lui donne donc entière confiance.
  • Mode « Accepter automatiquement ». A éviter en génral. Cela permet de créer le partage (et le dossier donc) si une instance nous partage quelque chose.

Enfin, vous pouvez ouvrir l’interface de gestion sur votre réseau local en y paramétrant un mot de passe par exemple.

Sur syncthing mobile, vous pouvez également limiter l’execution de la synchronisation uniquement lorsque vous êtes en charge et sur certains wifis…

Terminal Windows

Fév 19

Publié par Fanch dans Non classé | Aucun commentaire

Il existe une multitude de gestionnaire de terminal sous Windows, j’utilisais jusqu’à présent ConEmu. Il me permettait de rassembler des terminaux de type Command Windows, Cygwin, powershell et Debian en WSL, Mono. Il fallait cependant le configurer pour qu’il découvre les différents terminaux de ma machine.

J’ai essayé Terminal Windows, il me semble très prometteur puisque j’ai pas eu grand chose à faire pour y être à l’aise.

Où le trouver ?

Il est en version preview. Vous le trouverez dans le Windows Store sous le nom de Windows Terminal.

Il est disponible aussi via chocolate si vous l’utilisez (l’APT/Ansible sous Windows) via un choco install microsoft-windows-terminal

Que propose t-il ?

  • Un terminal multi-onglets en couleur, réactif et rapide à se lancer
  • Un système de copier-coller commun aux containers WSL
  • La proposition de terminaux : Command, PowerShell, Wsl, AzureCloud shell…
  • Un code source ouvert et une une communauté sous github.

La configuration se fait avec un bête fichier JSON (Attention, il faut que votre système sache ouvrir les fichiers JSON, sinon ça ne fait rien quand on clique sur « Settings »).

Vous utilisez Oh My Zsh ?

J’utilise Oh-my-zsh sous WSL (il existe aussi Oh-My-Posh pour PowerShell) qui rend la console plus agréable.

Pour installer zsh, il faut faut déjà git et zsh, puis rentrez cette commande dans votre shell :

sh -c "$(curl -fsSL https://raw.github.com/ohmyzsh/ohmyzsh/master/tools/install.sh)"

Installez la police Delugia.Nerd.Font.ttf de chez adam7/delugia-code.

Remplacez le thème par défaut par agnoster avec la commande :

sed -i 's/ZSH_THEME="robbyrussell"/ZSH_THEME="agnoster"/g' ~/.zshrc

Puis ajouter ceci dans la la section « profiles » -> « defaults » :

"fontFace" : "Delugia Nerd Font"

Relancer un shell.

Liseuse non surveillée

Déc 20

Publié par Fanch dans Non classé | 6 commentaires

Pour cette fin d’année (2019), j’ai voulu me prendre une liseuse que je puisse garder avec moi lors de moment divagantes. J’ai cherché un modèle promouvant le libre, et surtout non rattaché à des compte cloud dans tout les sens. Bref je voulais une liseuse, pas un tablette connectée déguisée.

Je suis d’abord tombé sur Booken qui me semble être le plus rapprochant aujourd’hui (Français en plus). Malheureusement un autre critère qu’est le style de tablette m’a fait penché vers Kobo. En effet bien que provenant de rakuten, il existe pour cette dernière, la Clara HD à 100€ chez darty, un hack pour ne pas avoir de compte et être maitre du système (un accès root via telnet).

Image associée
Kobo Clara HD (sortie en 2017 – oui les liseuse n’évoluent pas vraiment)

Bypass de la connexion

A l’allumage, la liseuse vous propose de vous connecter. Dites non. La liseuse passera alors en disque USB. Il vous suffira de lancer sur ce disque monté :

sqlite3 .kobo/KoboReader.sqlite
INSERT INTO user(UserID,UserKey) VALUES('1','');
CTRL+D pour quitter

La tablette va alors basculer en anonymous au bout de quelques secondes. Vous pouvez à présent l’utiliser comme liseuse non connecter en plaçant vos epub sur le disque monté.

Gestion de vos ebooks

Je vous conseille d’utiliser le logiciel libre calibre pour gérer vos livres avec la tablette. Il s’agit d’une référence libre pour gérer vos e-books (propriétaires ou non) sur vos liseuses (propriétaires ou non) à travers la connexion USB.

Résultat de recherche d'images pour "calibre"

Ansible avec AWX

Oct 26

Publié par Fanch dans GNU/Linux, Tutoriel | 1 commentaire

AWX est un frontend pour piloter Ansible. Il s’agit de la version opensource de Tower qui lui, est stabilisé avec mise à disposition d’un support.

A propos de cet article

Je vous donne ici les instructions pour installer Ansible et AWX sur une debian buster 64 bits.

Pour information, j’ai utilisé un container LXC (Proxmox 6). L’utilisation de docker dans un container « non-privilégié » est possible en ajoutant les lignes suivantes dans la config /etc/pve/lxc/XXXXX.conf :

unprivileged: 1
lxc.apparmor.profile: unconfined
lxc.cgroup.devices.allow: a
lxc.cap.drop:

Toutes les commandes si dessous se font en root.

Ansible

Prérequis

Installons le nécessaire pour ajouter une clé et l’usage de https dans les dépôts.

apt update
apt dist-upgrade
apt -y install gnupg2 apt-transport-https

Installation

Ajoutons le dépôt de chez launchpad et installons ansible. La version installée devrait correspondre sensible à la 2.8.6 (au 2019-10-25)

echo "deb http://ppa.launchpad.net/ansible/ansible/ubuntu bionic main" | tee /etc/apt/sources.list.d/ansible.list
apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 93C4A3FD7BB9C367
apt update
apt install -y ansible
ansible --version

AWX

Pre-requis

On ajoute le dépot et on install docker-ce. La version installée devrait correspondre sensible à la 19.03.4 (au 2019-10-25) 

echo "deb [arch=amd64] https://download.docker.com/linux/debian buster stable" | tee /etc/apt/sources.list.d/docker-ce.list
apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 7EA0A9C3F273FCD8
apt update
apt install -y docker-ce
docker --version

Je désactive l’IPV6 afin d’être sûr que AWX écoutera sur l’interface IPV4 (et je ne m’en sert pas entre mes VM).

cat <<EOF > /etc/sysctl.conf
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.all.autoconf = 0
net.ipv6.conf.default.disable_ipv6 = 1
net.ipv6.conf.default.autoconf = 0
EOF
sysctl -p

Installons un générateur de mot de passe et docker-compose (Ce sera celui des dépôt debian officiels)

apt -y git pwgen docker-compose

AWX

Récupérons AWX

cd ~
git clone --depth 50 https://github.com/ansible/awx.git

Configurons quelques valeurs

cd awx/installer
sed -i "s|docker_compose_dir=.*$|docker_compose_dir=/var/lib/awx|g" inventory
sed -i "s|^#project_data_dir=.*$|project_data_dir=/var/awx_projects|g" inventory
sed -i "s|^postgres_data_dir=.*$|postgres_data_dir=/var/pgdocker|g" inventory
sed -i "s|^secret_key=.*$|secret_key=$(pwgen -N 1 -s 30)|g" inventory
sed -i "s|^pg_admin_password=.*$|pg_admin_password=$(pwgen -N 1 -s 30)|g" inventory
sed -i "s|^pg_password=.*$|pg_password=$(pwgen -N 1 -s 30)|g" inventory
sed -i "s|^rabbitmq_password=.*$|rabbitmq_password=$(pwgen -N 1 -s 30)|g" inventory

Lonçons la création des containers AWX

ansible-playbook -i inventory install.yml

Note : Pour ma part, j’ai du relancer cette commande 2 fois car j’ai eu un timeout, je n’ai pas noté si il venais de mon système trop lent ou de ma connexion internet.

Comptez 24Go pour AWX, il va occuper pas mal d’espace docker (/var/lib/docker) pour ses 5 VM :

root@ansible:/var/lib/awx# docker-compose ps
     Name                   Command               State                               Ports
 awx_memcached   docker-entrypoint.sh memcached   Up      11211/tcp
 awx_postgres    docker-entrypoint.sh postgres    Up      5432/tcp
 awx_rabbitmq    docker-entrypoint.sh /bin/ …   Up      15671/tcp, 15672/tcp, 25672/tcp, 4369/tcp, 5671/tcp, 5672/tcp
 awx_task        /tini -- /bin/sh -c /usr/b …   Up      8052/tcp
 awx_web         /tini -- /bin/sh -c /usr/b …   Up      0.0.0.0:80->8052/tcp

Voilà, à partir de là, vous pouvez vous y connecter avec votre navigateur sur le port 80 et les identifiants à changer de suite : admin / password

Pour les mises à jour

Les mises à de Ansible se feront par le gestionnaire de paquet Debian.

Pour AWX, il faudra lancer ces commandes :

cd /var/lib/awx
docker-compose stop
docker-compose pull
docker-compose up --force-recreate -d

Créer et monter un volume qcow2

Jan 3

Publié par Fanch dans Aide mémoire, GNU/Linux, Tutoriel | Aucun commentaire

Pour quoi faire ?
Cela peut être utile si vous avez un système de fichier NTFS dans lequel vous souhaitez sauvegarder des données sans perdre les droits UNIX qui vont avec, pour le chiffrer, le transférer, monter une VM…
Création de l’image (ici 1.1G, format qcow2)
qemu-img create -f qcow2 datas.qcow2 1100M
Création du device et attachement du fichier
modprobe nbd max_part=8
qemu-nbd –connect=/dev/nbd0 datas.qcow2
Création de la partition et formatage ext4
cfdisk /dev/nbd0
mkfs.ext4 /dev/nbd0p1
Montage du la partition
mount /dev/nbd0p1 datas
Je n'aime pas les boîtes noires.