Exile on Keyboard St. - Blog sur Linux et Debian

Aller au contenu | Aller au menu | Aller à la recherche

mardi 5 septembre 2017

Refaire fonctionner Enigmail avec Icedove / Thunderbird sur Debian 8.9

Depuis la dernière mise à jour du paquet Icedove sur Debian 8.9, ce dernier m'a signalé que mon Add-On Enigmail était désactivé et qu'il fallait passer désormais par un autre Add-On dont j'ai oublié le nom. Ce jour là, j'ai laché l'affaire en me disant que je regarderai cela plus tard.

Ce matin, j'ai jeté un oeil, n'ai pas trouvé d'Add-On de remplacement pour Enigmail mais par contre en suivant la procédure suivante, j'ai rétabli ma configuration Mail+Encryption:

  • Installation de Thunderbird
  • Démarrage de Thunderbird + Migration des données issues d'Icedove (se fait tout seul)
  • Installation d'Enigmail afin de le réactiver (cette possibilité n'étant pas proposée)
  • Suppression du paquet iceowl-extension

Donc, je suis passé d'Icedove à Thunderbird (comma avant sur Debian quoi !) et ça fonctionne comme avant. Enfin presque ...

Maintenant, le déchiffrement des messages ne se fait pas de manière automatique et j'ai une erreur qui dit: GnuPG a rapporté une erreur de communication avec gpg-agent (un composant de GnuPG).

Capture-Alerte_Enigmail.png

Les solutions proposées dans le billet cité n'ont malheureusement pas fonctionné chez moi.

J'ai trouvé la solution dans le billet gnome-keyring gpg2 and enigmail clash.

Le script en question a été enregistré en .gpgrc et appelé dans .bashrc. Ensuite, j'appele Thunderbird de la façon suivante:

bash -i -c '/usr/bin/thunderbird %u'

Et j'ai bien:

env| grep GPG
GPG_AGENT_INFO=/tmp/gpg-63XK4k/S.gpg-agent:3002:1

C'est donc bien le gpg-agent qui est utilisé et non le Gnome Keyring.

Avec cette façon de faire, tout fonctionne, y compris le cache sur la saisie du mot de passe de ma clé privée !

Enfin, j'ai remarqué une aberration dans la configuration par défaut de Thunderbird, le moteur de recherche par défaut est Bing, moteur de recherche d'une célèbre (plus que son moteur en tous cas !) société américaine dont je ne citerai pas le nom. Je me demande bien ce qui a pû dicter ce choix malheureux dans un logiciel open source ...

Capture-Preferences_de_Thunderbird.png

mardi 15 août 2017

Utilisation des alias Bash en mode interactif ou non

Avec Bash, les alias sont définis dans le fichier .bashrc ou plus proprement dans le fichier .bash_aliases qui normalement est chargé depuis .bashrc comme suit:

# Alias definitions.
# You may want to put all your additions into a separate file like
# ~/.bash_aliases, instead of adding them here directly.
# See /usr/share/doc/bash-doc/examples in the bash-doc package.

if [ -f ~/.bash_aliases ]; then
    . ~/.bash_aliases
fi

Si j'ai défini:

alias ll='ls -l

Alias en mode interactif

La commande ll donnera le résultat suivant:

user@machine:~$ ll
total 60
drwxr-xr-x 2 user user  4096 juil. 23 17:03 bin
drwxr-xr-x 2 user user  4096 août   3 21:41 Bureau
drwxr-xr-x 6 user user  4096 juil.  9 18:00 Documents
drwxr-xr-x 2 user user  4096 avril 29 14:20 Enregistrements
drwxr-xr-x 4 user user  4096 juin  14 07:39 Images
drwxr-xr-x 2 user user  4096 nov.   9  2016 Modèles
drwxr-xr-x 2 user user  4096 nov.  23  2016 Musique
drwxr-xr-x 9 user user  4096 juin  13 08:51 Programs
drwxr-xr-x 2 user user  4096 nov.   9  2016 Public
drwxr-xr-x 8 user user  4096 juin   4 07:25 Sources
drwxr-xr-x 6 user user 12288 août   2 07:59 Téléchargements
drwxr-xr-x 7 user user  4096 juin   5 06:31 Vidéos
drwxr-xr-x 9 user user  4096 juin  30 19:32 VirtualBox VMs

Expansion des alias

C'est normal me direz-vous. En fait, l'alias ll qui a été défini est utilisable parce que je suis dans un Shell interactif et que par défaut Bash autorise l'expansion des alias dans un Shell interactif.

On peut s'en convaincre en désactivant cette option:

user@machine:~$ shopt -u expand_aliases
user@machine:~$ ll
bash: ll : commande introuvable
user@machine:~$ alias
alias l='ls -CF'
alias la='ls -A'
alias ll='ls -l'
alias ls='ls --color=auto'
alias rm='rm -i'

Les alias sont définis, ils existent mais ne sont pas utilisables pour autant !

Alias en mode non interactif

En mode non interactif, c'est à dire dans un script Shell lançé sans l'option -i, les choses sont différentes.

Première différence, le script .bash_aliases n'est pas chargé puisque .bashrc ne l'est pas. Ah bon ?

Il suffit de regarder le début du fichier .bashrc pour s'en convaincre:

user@machine:~$ more .bashrc 
# ~/.bashrc: executed by bash(1) for non-login shells.
# see /usr/share/doc/bash/examples/startup-files (in the package bash-doc)
# for examples

# If not running interactively, don't do anything
case $- in
    *i*) ;;
      *) return;;
esac

Vos alias habituels ne seront donc pas connus dans les scripts.

C'est en fait assez heureux si l'on considère les alias couramment définis sur les commandes rm et cp avec une demande de confirmation: dans un script mieux vaut ne pas avoir à répondre à des questions !

Deuxième différence, l'expansion des alias n'est pas activée par défaut dans un Shell non interactif.

Considérons le script suivant:

#!/bin/bash

alias ll='ls -l'
alias
ll
user@machine:~$ alias.sh
alias ll='ls -l'
/home/user/alias.sh: ligne 5: ll : commande introuvable

L'alias défini dans le script lui même n'est pas utilisable !!!

En revanche si j'ajoute en début de script la ligne suivante:

shopt -s expand_aliases

mon alias est connu depuis le script. On pensera donc à ajouter cette commande, avant ou après la définition des alias, dans les scripts les utilisant.

Et pour afficher toutes les options actives de Bash:

shopt -s

vendredi 9 juin 2017

Complétion bash et utilisateur root

La complétion bash nous facilite bien la vie au quotidien puisqu'elle nous aide dans la saisie des options et paramètres des lignes de commandes sans avoir besoin de consulter les man pages.

Mais est t'elle toujours activée ?

J'ai fait le test avec Debian Stretch mais les résultats sont les mêmes avec Debian Jessie.

Lorsque j'utilise un utilisateur non root, la complétion bash est activée que j'utilise un Shell de login (avec Ctrl Alt F1) ou un Shell normal.

Si je tappe apt-get suivi de la touche TAB:

debian@stretch:~$ apt-get 
autoclean        changelog        dist-upgrade     install          source
autoremove       check            download         purge            update
build-dep        clean            dselect-upgrade  remove           upgrade

bash me propose bien la complétion qui convient à la commande apt-get.

Si maintenant je me connecte avec root, j'obtiens le résultat suivant:

debian@stretch:~$ su
Mot de passe : 
root@stretch:/home/debian# apt-get 
.bash_history         .dmrc                 .local/               Téléchargements/
.bash_logout          Documents/            Modèles/              Vidéos/
.bashrc               .gnupg/               Musique/              .Xauthority
Bureau/               .ICEauthority         .profile              .xsession-errors
.config/              Images/               Public/               .xsession-errors.old

Avec l'utilisateur "normal", ici debian, cela fonctionne car le fichier .bashrc par défaut de l'utilisateur se termine comme ceci:

debian@stretch:~$ tail .bashrc 
# enable programmable completion features (you don't need to enable
# this, if it's already enabled in /etc/bash.bashrc and /etc/profile
# sources /etc/bash.bashrc).
if ! shopt -oq posix; then
  if [ -f /usr/share/bash-completion/bash_completion ]; then
    . /usr/share/bash-completion/bash_completion
  elif [ -f /etc/bash_completion ]; then
    . /etc/bash_completion
  fi
fi

ce qui n'est pas le cas pour l'utilisateur root:

root@stretch:/home/debian# cat /root/.bashrc 
# ~/.bashrc: executed by bash(1) for non-login shells.

# Note: PS1 and umask are already set in /etc/profile. You should not
# need this unless you want different defaults for root.
# PS1='${debian_chroot:+($debian_chroot)}\h:\w\$ '
# umask 022

# You may uncomment the following lines if you want `ls' to be colorized:
# export LS_OPTIONS='--color=auto'
# eval "`dircolors`"
# alias ls='ls $LS_OPTIONS'
# alias ll='ls $LS_OPTIONS -l'
# alias l='ls $LS_OPTIONS -lA'
#
# Some more alias to avoid making mistakes:
# alias rm='rm -i'
# alias cp='cp -i'
# alias mv='mv -i'

Cette section "enable bash completion in interactive shells" qui n'existe pas dans le fichier /root/.bashrc est bien présente dans le fichier /etc/bash.bashrc mais elle y est commentée:

root@stretch:/home/debian# tail -n 25 /etc/bash.bashrc  | head -n 8
# enable bash completion in interactive shells
#if ! shopt -oq posix; then
#  if [ -f /usr/share/bash-completion/bash_completion ]; then
#    . /usr/share/bash-completion/bash_completion
#  elif [ -f /etc/bash_completion ]; then
#    . /etc/bash_completion
#  fi
#fi

Il suffit donc de la ré-activer pour que la complétion fonctionne aussi pour root.

Une fois cela fait, la section dans le .bashrc utilisateur n'est plus nécessaire.

samedi 26 mars 2016

Configurer Solarized pour un terminal moins fatiguant pour la vue

Sous Gnome, et avec de nombreux environnements graphiques sous Linux, le profile par défaut du terminal a un fond blanc avec un texte en noir.

Ce choix de couleurs qui était préconisé quand j'étais étudiant est au contraire très fatiguant à la longue pour la vue, à cause de la forte luminosité causée par le fond blanc. C'est pourquoi d'autres configurations de couleurs sont apparues, comme par exemple le thème darcula d'IntelliJ.

On va voir dans ce billet comment utiliser le thème solarized pour:

  • La commande ls en configurant un fichier .dircolors
  • Positionner les couleurs du thème Solarized dans notre terminal

Solarized, c'est quoi ?

D'après son créateur Ethan Schoonover:

Solarized is a sixteen color palette (eight monotones, eight accent colors) designed for use with terminal and gui applications

En gros c'est une palette de couleurs, pour moitié lumineuses et pour moitié foncées.

Etape 1: Modifier les couleurs de ls avec dircolors

wget --no-check-certificate https://raw.github.com/seebi/dircolors-solarized/master/dircolors.ansi-dark
mv dircolors.ansi-dark ~/.dircolors
eval `dircolors ~/.dircolors`

Ces dernières commandes créent un fichier ~/.dircolors pris en compte par la commande ls pour coloriser chaque fichier, répertoire ou type de fichier de manière particulière. Au prochain login du système, il n'y a rien de particulier à faire puisque le fichier .bashrc appelle généralement la commande dircolors avec le fichier ~/.dircolors.

Pour en savoir plus sur la commande dircolors, on pourra consulter la doc de lea-linux.

Etape 2: Pour Gnome - Modifier les couleurs utilisées par gnome-terminal

Pour modifier les couleurs utilisées dans le profile du terminal, et donc dans le terminal, on va utiliser un autre repository sur Github:

git clone https://github.com/sigurdga/gnome-terminal-colors-solarized.git
cd gnome-terminal-colors-solarized
./set_dark.sh

Le script nous demande alors de choisir le thème de couleur:

  • dark
  • dark_alternative
  • light

puis le profile utilisé. Quand on a installé Linux en Français, c'est:

  • Par défaut (Default)

Ensuite on confirme et les couleurs sont instantanément modifiées dans le terminal.

Si l'on souhaite conserver le profile "Par défaut" inchangé, on peut commencer par le cloner en l'appelant par exemple "Solarized". C'est alors ce dernier profile que l'on modifiera avec ./set_dark.sh.

Etape 2: Pour Mate - Modifier les couleurs utilisées par mate-terminal

Si vous n'utilisez plus Gnome mais Mate à la place, il faut procéder comme suit:

git clone https://github.com/cledoux/mate-terminal-colors-solarized.git
cd mate-terminal-colors-solarized.git
./install.sh 

Note: Sur Debian Jessie, j'ai dû me déconnecter de l'interface graphique afin que les modifications du profil du terminal soient prises en compte.

dimanche 17 mai 2015

Retrouvez les modifications faites dans vos fichiers de configuration sous Linux

On est tous amenés à modifier les fichiers de configuration de bash sour Linux.

Seulement voilà au bout de quelques temps et après beaucoup de changements comment savoir quelles sont les portions du fichier que l'on a changé ?

Les deux fichiers de configuration de bash, .profile et .bashrc sont installés sur le système par le package du même nom. La version initiale de ces fichiers, le "squelette", se trouve dans le répertoire /etc/skel:

ls -a /etc/skel/
.  ..  .bash_logout  .bashrc  .profile

Par conséquent, pour connaitre les modifications faites par exemple dans .profile il suffit de faire:

diff /etc/skel/.profile .profile 

Ce qui peut donner:

18a19,21
> JAVA_HOME=/usr/lib/jvm/java-7-openjdk-amd64/
> export JAVA_HOME
> 

Le fait que les fichiers squelette se trouvent dans /ets/skel est connu. Mais comment faire pour trouver à quel package Debian appartient un fichier ?

Il suffit pour cela d'utiliser la commande apt-file avec en premier argument le mot clé search comme ceci:

apt-file search .bashrc
adduser: /usr/share/doc/adduser/examples/adduser.local.conf.examples/bash.bashrc
adduser: /usr/share/doc/adduser/examples/adduser.local.conf.examples/skel/dot.bashrc
base-files: /usr/share/base-files/dot.bashrc
bash: /etc/bash.bashrc
bash: /etc/skel/.bashrc
drush: /usr/share/doc/drush/examples/example.bashrc
iselect: /usr/share/doc/iselect/examples/chdir/dot.bashrc
iselect: /usr/share/doc/iselect/examples/ilogin/dot.bashrc
qiime: /usr/lib/qiime/shell/.bashrc
sysprofile: /usr/share/doc/sysprofile/examples/etc/bash.bashrc

On retrouve bien le fichier /etc/skel/.bashrc installé par le paquet bash.

Le fichier .bashrc de l'utilisateur root se trouve ici: /usr/share/base-files/dot.bashrc

- page 1 de 2