Utiliser GPG dans WSL2

Photo by Pixabay on Pexels.com

Pourquoi utiliser GPG ? Par exemple pour signer les commits GIT. Maintenant comment faire quand on est sous Windows 10 et qu’on souhaite utiliser le sous système Linux (WSL2)?

Sous GNU/Linux, l’installation et l’utilisation avec git est très simple. Avec WSL2,… il faut un peu d’huile de coude 🙂

Je vais tâcher de décrire dans cet article les différentes manipulations nécessaires pour:

  • Importer une clé GPG existante
  • Utiliser GPG pour signer mes commits dans WSL2

Importer une clé GPG existante

Export de la clé GPG

Identifier l’ ID de la clé

Lancez la commande suivante:

gpg --export ${ID} > public.key
gpg --export-secret-key ${ID} > private.key

Import

gpg --import public.key
gpg --import private.key

Vérification

Pour vérifier que la clé est bien configurée, vous pouvez lancer la commande suivante:

gpg --list-secret-keys --keyid-format LONG   alexandre@....
sec   rsa4096/CLE_ID 2019-12-20 [SC]
      ********************
uid                [  ultime ] Alexandre <alexandre@....>
ssb   rsa4096/SUB 2019-12-20 [E]

Si la clé n’est pas reconnue comme ultime ou comme de confiance, il faudra l’éditer:

gpg --edit-key CLE_ID
Please decide how far you trust this user to correctly verify other users' keys
(by looking at passports, checking fingerprints from different sources, etc.)
  1 = I don't know or won't say
  2 = I do NOT trust
  3 = I trust marginally
  4 = I trust fully
  5 = I trust ultimately
  m = back to the main menu
Your decision? 

Si vous ne voulez pas trop vous compliquer, je vous conseille de répondre 5.

Configuration GPG pour WSL2

Avant de configurer l’agent GPG, vous pouvez vous référer à cet article pour configurer GIT et GPG. La configuration est équivalente.

Ensuite, créez le fichier ~/.gnupg/gpg.conf avec le contenu suivant:

# Uncomment within config (or add this line)
# This tells gpg to use the gpg-agent
use-agent
# Set the default key
default-key CLE_ID

Puis créez le fichier ~/.gnupg/gpg-agent.conf avec le contenu ci-dessous:

default-cache-ttl 34560000
max-cache-ttl 34560000
pinentry-program /usr/bin/pinentry-curses

Le cache ici est défini en secondes. Il est mis ici à 400 jours.

Ce dernier fichier fait référence au programme pinentry. Vous pouvez vérifier sa présence grâce à la commande:

ls /usr/bin/pinentry-curses 

Si vous ne l’avez pas, vous pouvez l’installer grâce à la commande suivante:

sudo apt install pinentry-curses

Maintenant, on peut configurer l’environnement BASH en modifiant le fichier ~/.bashrc

# enable GPG signing
export GPG_TTY=$(tty)
if [ ! -f ~/.gnupg/S.gpg-agent ]; then
    eval $( gpg-agent --daemon --options ~/.gnupg/gpg-agent.conf )
fi
export GPG_AGENT_INFO=${HOME}/.gnupg/S.gpg-agent:0:1

Redémarrez ensuite WSL2 pour que ça soit pris en compte.

A la première utilisation de GPG ( par ex. lors d’un commit, vous aurez une interface Ncurses qui apparaîtra dans votre prompt WSL2. Vous aurez à renseigner le mot de passe de votre clé.

Installer Ubuntu 20.04 LTS sur un DELL Inspiron 13 5000

Les confinements se suivent et se ressemblent. Me voilà à installer Ubuntu sur un nouvel ordinateur.
A l’instar de l’ancien laptop que j’ai acheté pour mon aînée, j’ai acheté un DELL pour ma deuxième fille.
J’ai opté pour un DELL Inspiron 5301.


A l’instar de mon autre laptop, je j’ai pas pris de risques. J’ai opté pour un DELL qui est pleinement compatible avec Ubuntu. Oui j’aurai pu installer un ordinateur avec Ubuntu pré-installé, mais je n’ai pas eu le temps de faire un choix « serein ».


Configuration du BIOS

Voila les paramètres que j’ai appliqué:

Dans le menu "Storage" puis "SATA Operation": vous devez sélectionner AHCI au lieu de RAID.
Dans le menu "Change boot mode settings >UEFI Boot Mode" , vous devez désactiver le Secure Boot.

Une fois réalisé, vous pouvez redémarrer en appuyant sur la touche F12. Si vous n’arrivez pas à revenir sur le BIOS pour indiquer de booter sur votre clé USB, vous obtiendrez un écran d’erreur Windows dû à la configuration AHCI. Personnellement, en redémarrant une ou deux fois, j’ai obtenu un écran de démarrage avancé qui m’a permis de sélectionner le périphérique (ma clé USB) sur lequel démarrer.

Maintenant vous pouvez accéder à l’installeur Ubuntu et profiter.

Installation

J’ai eu plusieurs fois des popup « erreur rencontré ». Ce n’était pas bloquant. J’ai continué.

Tout s’est déroulé sans encombre. Le matériel est très bien reconnu.

Les seuls logiciels que j’ai installé sont pour l’instant : VLC, Minecraft ( obligatoire dans la famille ) et Chromium.

Améliorer le temps de démarrage de Debian 10

Mon PC Lenovo a un SSD. Le temps de démarrage est actuellement de 11 sec. Ça commence à faire pas mal… J’ai eu donc envie de me pencher sur l’optimisation du démarrage ( encore une fois) . Voici comment gagner (facilement) quelques secondes au démarrage.

Tout d’abord, vous devez analyser les services qui prennent du temps au démarrage. Vous pouvez le faire avec cette commande:

systemd-analyze plot > plot.svg

J’ai obtenu le graphique suivant:

Configuration GRUB

La première manipulation à réaliser est de désactiver le timeout de GRUB. Pour celà, vous pouvez modifier la variable GRUB_TIMEOUT dans le fichier /etc/default/grub:

GRUB_TIMEOUT=0

Ensuite, vous devez mettre à jour la configuration GRUB en exécutant cette commande:

sudo update-grub2

Au prochain reboot, vous ne verrez plus le menu GRUB.

Configuration NetworkManager

Dans mon cas, le service NetworkManager-wait-online.service prenait près de 9 secondes. Après avoir lu plusieurs billets et rapports de bug, je me suis aperçu que je pouvais le désactiver au boot. Vous pouvez le faire en lançant la commande suivante

sudo systemctl disable NetworkManager-wait-online.service

Configuration Apt

Un autre service qui prenait pas mal de temps était apt-daily.timer qui vérifiait au boot qu’il y avait des mises à jour de l’OS. Après quelques recherches, j’ ai vu qu’on pouvait soit le désactiver ( ce qui n’est pas recommandé pour les mises à jour de sécurité ) soit décaler la recherche. J’ai choisi cette solution. Vous devez donc exécuter la commande suivante:

sudo systemctl edit apt-daily.timer

Et renseigner le contenu suivant:

[Timer]
OnBootSec=15min
OnUnitActiveSec=1d
AccuracySec=1h
RandomizedDelaySec=30min

Ce service sera donc lancé 15 minutes après le boot. Ce qui est largement suffisant.

[EDIT] Vous pouvez appliquer la même configuration pour le service apt-daily-upgrade en exécutant la commande:

sudo systemctl edit apt-daily-upgrade.timer

Ensuite, vous pouvez recharger la configuration en exécutant cette commande:

sudo systemctl daemon-reload

Résultats

Après ces quelques manipulations qui peuvent prendre 5 minutes grand maximum, j’ai réussi à optimiser le boot en réduisant le démarrage à 5 secondes!

Vous pourrez trouver le détail ci-dessous:

Répéter avec JjazzLab tout seul dans son garage

Avec les contraintes liées au confinement, les répétitions se font de plus en plus rares. Pour ne pas perdre la main, il y a quelques logiciels qui permettent de jouer d’un instrument et d’ improviser tout en ayant une bande son en fond musical.

Il y a plusieurs logiciels payants/propriétaires sur différentes plateformes:

J’ai découvert ce dernier récemment en naviguant sur le site Linux Mao. Il a l’avantage d’être gratuit (le moteur est sous licence LGPL 3.0, pas le logiciel en tant que tel), de fonctionner sous GNU/LINUX, d’ offrir un son pas mal du tout et de permettre la configuration de la dynamique au fur et à mesure du morceau.

Je vais expliquer comment l’installer sur Debian.

Configuration Midi

Activation des périphériques virtuels MIDI

Créer un fichier /etc/modules.load.d/midi.conf avec le contenu suivant:

snd-virmidi

Ensuite créer le fichier /etc/modprobe.d/midi.conf avec le contenu suivant:

options snd-virmidi midi_devs=1

Logiquement à ce stade, lors du prochain reboot, vous aurez un périphérique virtuel MIDI activé. En attendant vous pouvez lancer la commande suivante

$ sudo modprobe snd-virmidi midi_devs=1

Synthétiser du MIDI

Pour faire fonctionner ce logiciel, il faut installer une banque de son ( au format SF2) et un logiciel permettant de l’utiliser pour synthétiser du MIDI.
La banque de son recommandée est disponible via ce lien. Téléchargez là et copiez la dans un répertoire accessible.

Pour le second, il vous faudra installer fluidsynth. Voic les quelques commandes à lancer:

$ sudo apt install fluid-synth qsynth

Petite vérification…

Avant d’ aller plus loin dans la configuration de fluidsynth, vous pouvez vous assurer que tout est OK en récupérant un fichier MIDI et en lançant la commande suivante:

$ fluidsynth -a pulseaudio -m alsa_seq -l -i /opt/JJazzLab-2.0-Linux/JJazzLab-SoundFont.sf2  MIDI_sample.mid

Normalement vous devriez avoir du son.

Configurer fluidsynth

Lancez qsynth et cliquez sur le bouton « configuration »

Vous trouverez ci-dessous la configuration que j’ai appliqué. Elle diffère légèrement de celle présentée dans la documentation.

Pensez à redémarrer fluidsynth après application de ces nouveaux paramètres.

Configurer aconnect

Disclaimer: La c’est la partie la plus obscure…

Il faut maintenant « brancher » la sortie du synthétiseur virtuel MIDI à fluidsynth pour que le son MIDI soit interprété par ce dernier à travers sa banque de son. Ce n’est pas intuitif, je vous avais prévenu …
Je ne vous parle pas de la pseudo interface graphique à aconnect. La ligne de console est plus parlante ( c’est pour dire ) .

Exécutez la commande suivante:

$ aconnect -lo                                            
client 14: 'Midi Through' [type=noyau]
    0 'Midi Through Port-0'
client 24: 'Virtual Raw MIDI 2-0' [type=noyau,card=2]
    0 'VirMIDI 2-0     '
client 128: 'FLUID Synth (JJLAB)' [type=utilisateur,pid=17838]
    0 'Synth input port (JJLAB:0)'

Dans mon cas, je vais avoir à connecter le client 24:0 au synthétiseur 128:0 grâce à la commande :

$ aconnect 24:0 128:0

Maintenant, si on relance la commande aconnect -lo on obtient le résultat suivant:

client 14: 'Midi Through' [type=noyau]
    0 'Midi Through Port-0'
client 24: 'Virtual Raw MIDI 2-0' [type=noyau,card=2]
    0 'VirMIDI 2-0     '
	Connexion À: 128:0
client 128: 'FLUID Synth (JJLAB)' [type=utilisateur,pid=17838]
    0 'Synth input port (JJLAB:0)'
	Connecté Depuis: 24:0

Attention, cette commande devra être lancée ( ainsi que fluidsynth) avant chaque démarrage de jjazzlab.

Installation de Jjazzlab

Téléchargez les binaires sur ce site, puis décompressez l’archive dans le répertoire /opt par ex.

Vous devez également installer java

$ sudo apt install openjdk-11-jdk

Ensuite, vous devez créer le fichier ~/.local/share/applications/jjazzlab.desktop avec le contenu suivant:

[Desktop Entry]
Type=Application
Name=JJazzLab
GenericName=JJazzLab
Icon=
Exec="/opt/JJazzLab-2.0-Linux/bin/jjazzlab"
Terminal=false
Categories=Audio;Music;Player;AudioVideo;

Maintenant vous pouvez directement démarrer JJazzlab via le menu.

Configuration

Une fois jjazzlab démarré, vous devez aller dans le menu « Tools>Options » et sélectionnez les valeurs suivantes:

Ouvrez un fichier example (ex. sunny )

Cliquez sur le menu décrit par un clavier

Puis configurez comme suit:

Maintenant vous pouvez télécharger les standards fournis sur le site et improviser dessus 🙂

Erreur 139 à l’exécution d’un container docker

Voici un rapide article sur un problème rencontré récemment. Lors de l’exécution d’un container docker, j’ai eu une erreur SIGSEGV 139. Un crash avec aucune log.

Bref que du bonheur 🙂



Avant d’aller plus loin voici mon environnement:

Après quelques recherches, je me suis rendu compte qu’on pouvait reproduire ce comportement en exécutant cette commande:

docker run -it gcc:4.8.5

Une des raisons trouvées serait un problème de compatibilité avec le noyau 4.8.5 (oui ça remonte…).
Une solution est d’activer l’émulation vsyscall.


Voici la configuration à effectuer:
Dans le fichier /etc/default/grub, ajouter la ligne suivante:

GRUB_CMDLINE_LINUX_DEFAULT="quiet vsyscall=emulate"

Puis lancer les commandes suivantes:

$ sudo update-grub 
$ sudo reboot

Maintenant le container devrait pouvoir s’exécuter correctement.

Installer Ubuntu 18.04 LTS sur un Dell Inspiron 14-3493

Suite aux premières annonces de distanciation sociale ( avant que le confinement soit effectif ) j’ai acheté en catastrophe un PC portable. Les critères étaient : 8Go de RAM, un disque SSD … et la compatibilité GNU/LINUX :).

N’ayant pas trop de temps pour chercher la bonne affaire ( technologique et financière ), j’ ai acheté un Dell Inspiron 14-3493.



Je n’ai pas pris trop de risques. Bien que livré avec Windows 10, ce modèle est déjà certifié compatible Ubuntu.
L’installation d’Ubuntu se passe très bien. C’est plié en moins de 30mn. Du coup, je ne la détaillerai pas dans cet article – si vous êtes intéressé, vous pouvez consulter cet article. Pour les pré-requis, c’est une autre paire de manches …

Voilà les différentes actions que j’ai réalisé au préalable

Redémarrer l’ordinateur et accéder au BIOS

Là, j’ai un peu galéré pour accéder au BIOS. La seule manipulation que j’ai trouvé et de lancer le menu « Démarrage avancé » puis sélectionner « Utiliser un périphérique ».

Vous pouvez donc sélectionner le disque dur. Au boot en appuyant sur la touche F12 et/ou F2, vous pouvez accéder au BIOS.

Configuration du BIOS

Voila les paramètres que j’ai appliqué:

Dans le menu "SATA Operation": vous devez sélectionner AHCI au lieu de RAID.
Dans le menu "Change boot mode settings >UEFI Boot Mode" , vous devez désactiver le Secure Boot.

Une fois réalisé, vous pouvez redémarrer en appuyant sur la touche F2 et/ou F12. Si vous n’arrivez pas à revenir sur le BIOS pour indiquer de booter sur votre clé USB, vous obtiendrez un écran d’erreur Windows dû à la configuration AHCI. Personnellement, en redémarrant une ou deux fois, j’ai obtenu un écran de démarrage avancé qui m’a permis de sélectionner le périphérique (ma clé USB) sur lequel démarrer.

Maintenant vous pouvez accéder à l’installeur Ubuntu et profiter 🙂

Après l’installation

Je n’ai rien fait de particulier si ce n’est configurer le trackpad. Pour cela, j’ai installé gnome-tweaks. Mis à part ça, tout fonctionne très bien!

Vérifier les commit GIT avec GPG

Juste pour un pense bête, voici comment paramétrer GIT et GITHUB/GITLAB pour signer les commits avec GPG.

Configuration GPG

Exécutez la commande suivante :

gpg --full-generate-key

Sélectionnez une clé RSA (question 1) de 4096 bits (question 2).

Une fois cette commande effectuée, vous pouvez récupérer votre clé GPG avec cette commande:

gpg –list-secret-keys –keyid-format LONG

gpg --list-secret-keys --keyid-format LONG alexandre@....
/home/alexandre/.gnupg/pubring.kbx
----------------------------------
sec rsa4096/XXXXXXXXXX 2019-08-09 [SC]
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
uid [ ultime ] Alexandre Touret <mon.mail.github.ou.gitlab@monprovider.fr>
ssb rsa4096/XXXXXXXXXX 2019-08-09 [E]

Ensuite, il faut exécuter cette commande

gpg --armor --export XXXXXXXXXX

Configuration GIT

Indiquez la clé GPG à GIT

 git config --local user.signingkey 6F9D7D5FCE959337

Et indiquez que vous voulez signer tous vos commits

git config --local commit.gpgsign true

Si vous ne faites pas cette dernière commande, vous devrez ajouter l’option -S à chaque exécution de la commande git commit.

Exemple:

 git -a -S -m "Ajout javadoc"

Configuration GITHUB

Sur Github ( il y a la même chose sur gitlab), vous pouvez dans vos paramètres ajouter cette clé . De cette manière, vos prochains commits envoyés seront vérifiés.

 En espérant que ça serve à d’autres 🙂

Ansible pour les provisionner tous !

Si vous provisionnez vos VM VirtualBox avec Vagrant, vous avez sans doute eu l’idée d’automatiser le provisionning des machines virtuelles. Dans mon cas une VM GNU/Linux basée sur Debian 9.

Pour cela, soit vous faite tout manuellement et après les mises à jour deviennent fastidieuses, soit vous appliquez un script shell au démarrage de vagrant, soit vous utilisez Ansible.

Ansible est un outil opensource permettant d’automatiser le provisionning et la mise à jour des environnements à distance (via SSH). L’avantage par rapport à des outils tels que Puppet, est qu’il ne nécessite pas l’installation d’agent.

Je vais essayer de vous montrer comment mettre en place le provisionning via Ansible pour VirtualBox.

Configuration de Vagrant

Dans le fichier Vagrantfile, on active le provisionning via Ansible:

config.vm.provision "ansible_local" do |ansible|
ansible.playbook = "site.yml"
ansible.install_mode = "pip"
ansible.version = "2.7.10"
end

Cette configuration fait référence à un fichier « playbook » site.yml. C’est la configuration qui sera appliqué lors du provisionning . Que ça soit à la création ou pour les mises à jour.

Voici un exemple de contenu:

- name: VirtualBox
hosts: all
become: yes
become_user: "root"
become_method: "sudo"
roles:
- common
vars_files:
- vars/environment.yml

Ce fichier est la racine de notre configuration Ansible. On y référence les rôles appliqués et les fichiers d’ environnement. Voici un exemple de rôle:

- name: "Remove useless packages from the cache"
apt:
autoclean: yes
force_apt_get: yes

- name: "Remove dependencies that are no longer required"
apt:
autoremove: yes
force_apt_get: yes

- name: "Update and upgrade apt packages (may take a while)"
become: true
apt:
upgrade: dist
update_cache: yes
force_apt_get: yes

- name: "Install useful packages"
become: true
apt:
name:
- gcc
- g++
...
- zsh
- firewalld
state: present
update_cache: no

- name: ansible create directory example
file:
path: "{{ home }}/.m2"
state: directory
owner: "{{ username }}"
group: "{{ username }}"

- name: Install Maven settings.xml
copy:
src: settings.xml
dest: "{{ home }}/.m2/settings.xml"
owner: "{{ username }}"
group: "{{ username }}"

- name: "Install Maven"
raw: "curl -sL \"http://mirror.ibcp.fr/pub/apache/maven/maven-3/{{ maven_version }}/binaries/apache-maven-{{ maven_version }}-bin.tar.gz\" -o /opt/apache-maven.tar.gz && tar -zxf /opt/apache-maven.tar.gz -C /opt"
become: true
become_user: root
become_method: sudo

- name: "Change Maven Rights"
file:
path: /opt/*
state: touch
modification_time: "preserve"
access_time: "preserve"
owner: "{{ username }}"
group: "{{ username }}"

Les variables d’environnement permettent de variabiliser certains champs de vos rôles. On peut trouver par exemple les versions de certains outils déployés

maven_version: 3.5.4
username: vagrant
home: /home/vagrant
docker_compose_version: 1.22.0

Il y a une quantité impressionnante de modules Ansible que l’on peut utiliser. Que ça soit pour lancer des commandes shell ou lancer des services. Contrairement à la création d’un script shell qui pourrait faire les mêmes actions à la création, on peut facilement gérer la mise à jour de la VM car Ansible détecte les modifications lors de son exécution.

Configuration spécifique pour VirtualBox

Pour VirtualBox, j’ai ajouté deux fichiers de configuration supplémentaires à la racine:

ansible.cfg
[defaults]
hostfile = hosts
hosts
[local]
localhost ansible_connection=local

Provisionning

A la création

le provisionning peut se faire au lancement de vagrant via la commande:

vagrant up

Pour faire une mise à jour

Directement dans la box, vous pouvez lancer les commandes suivantes :

sudo mount -t vboxsf vagrant /vagrant

Puis, vous pouvez lancer les commandes suivantes dans la box:

su -
cd /vagrant
export ANSIBLE_CONFIG=/vagrant
ansible-playbook site.yml

 

Gérer plusieurs clés et plusieurs repo GIT

En attendant d’avoir plus d’imagination, voici un rapide tuto pour gérer plusieurs référentiels GIT avec des clés SSH différentes.

Imaginons que vous deviez vous connecter sur différents serveurs GIT (ex. github et gitlab) avec des emails différents et donc des clés RSA différentes ( oui je sais ce cas n’arrive pas souvent ). Le tout sous Windows et GNU/LINUX. Sous GNU/LINUX ont peut le gérer différemment via la commande ssh-add.

Pour pouvoir gérer ceci de manière simple, j’ai fait la manipulation suivante :

Dans le répertoire ~/.ssh. J’ai crée les différentes clés avec la doc fournie par GITHUB. Puis, j’ai crée le fichier ~/.ssh/config avec le contenu suivant:

 

Host monhost1.fr
HostName monhost1.fr
User git
IdentityFile ~/.ssh/id_rsa

Host monhost2.fr
HostName monhost2.fr
User git
IdentityFile ~/.ssh/nouvellecle_rsa

 

Et voila !

Après avoir fait les différentes configurations coté serveur ( c.-a-d. ajout des clés publiques ), je peux interagir avec les différents serveurs ( pull, push ).

En espérant que ça puisse servir à d’autres

 

Activer l’ equalizer sur Debian 9

Et oui, il y a un equalizer dans debian….Pulse Audio dispose d’un equalizer. Bon ce n’est encore très user friendly, mais ça fonctionne!

Installation de l’equalizer

#apt-get install pulseaudio-equalizer

Activation

Ajouter les lignes suivantes dans le fichier /etc/pulse/default.pa

load-module module-equalizer-sink
load-module module-dbus-protocol

Relancer le démon pulseaudio

# pulseaudio -k && pulseaudio -D

A ce stade, vous devriez avoir dans le panneau de configuration la référence à l’equalizer

Sélection_001

Lancement

En ligne de commande ( je vous disais que ce n’était pas trop user-friendly), lancer la commande

$ qpaeq &

On obtient cette interface:

qpaeq_002

Arrivé à ce niveau, je suis quand même un peu déçu/ Il n’y a pas une vrai intégration dans debian ( pas de lanceur pour l’equalizer ) et il n’y a pas de presets configurés ( #souvienstoiwinamp)

J’ai essayé de poster mon soucis sur IRC, mais je n’ai pas encore eu de réponse. Je pense soumettre un bug dans les prochains jours.