Wine est un instrument merveilleux
pour tous ceux qui ne veulent plus de Windows, mais ne peuvent pas non
plus se passer entièrement d’une poignée d’applications dont les
équivalents sous OS libre sont décevants. Ainsi, pour les maniaques de
la copie audio parfaite, Exact Audio
Copy est largement
supérieur à
Rubyripper (moins
efficace et dont le développement a cessé) ou à
Morituri (sans aucune
souplesse en ce qui concerne les tags).
Cependant, Wine a un inconvénient majeur : il ouvre la machine aux
menaces spécifiques à Windows. Sur les forums, on lit souvent des
réponses à ce problème du type : « Mais comme on ne lance pas Wine en
root, on ne compromet pas sa machine. » Certes, mais on expose toutes
les données auxquelles l’utilisateur de l’application a accès, ce qui
est très suffisant pour faire peur…
Les méthodes de sécurisation les plus simples (comme winetricks sandbox,
qui supprime des lecteurs avec winecfg) n’étant pas très efficaces,
mieux vaut se tourner vers la virtualisation. Cependant, outre que cette
solution est lourde, EAC ne fonctionnera pas correctement sur un Wine de
machine virtuelle Virtualbox, à cause du pilote virtualisé du CD-ROM.
Sous FreeBSD, il suffit de faire tourner Wine dans une
jail.
Mais sous Linux, la mise en place de container
LXC était une
opération lourde, assez décourageante pour un besoin aussi basique.
La donne a cependant changé avec l’arrivée de
Docker : il devient en effet assez
facile de créer un container pour faire tourner une application
graphique sous Wine.
Voici comment je m’y suis pris.
Fichier Dockerfile pour créer le container :
:::text
FROM ubuntu:
ENV DEBIAN\_FRONTEND noninteractive
RUN apt-get update -y
RUN apt-get install -y python-software-properties software-properties-common
RUN add-apt-repository -y ppa:ubuntu-wine/ppa
RUN dpkg --add-architecture i386
RUN apt-get update -y
RUN apt-get install -y wine1.7 winetricks
RUN apt-get purge -y python-software-properties
RUN apt-get autoclean -y
\# Remplacer 1002 & 100 avec user & group id
RUN export uid=1002 gid=100 && \
mkdir -p /home/developer && \
echo "developer:x:${uid}:${gid}:Developer,,,:/home/developer:/bin/bash" >> /etc/passwd && \
echo "developer:x:${uid}:" >> /etc/group && \
echo "developer ALL=(ALL) NOPASSWD: ALL" > /etc/sudoers.d/developer && \
chmod 0440 /etc/sudoers.d/developer && \
chown ${uid}:${gid} -R /home/developer
USER utilisateur
ENV HOME /home/utilisateur
CMD /usr/bin/wine
Un petit coup de docker build utilisateur/wine.
Le container est construit. Reste qu’il ne faut pas y placer les
données, si on veut pouvoir le faire évoluer et se mettre à jour. Le
plus pratique pour pouvoir aussi échanger des fichiers entre l’hôte et
le container est de créer un dossier Wine sur l’hôte qu’on montera comme
home dans le container avec : -v emplacement-dossier-Wine:/home
Il faut créer à l’intérieur un dossier au nom de l’utilisateur : mkdir
utilisateur
Pour rediriger le container vers la sesson X de l’hôte : -e
DISPLAY=\$DISPLAY -v /tmp/.X11-unix:/tmp/.X11-unix
Ce qui donnera, pour ouvrir un shell dans le container :
docker run -ti --rm -e DISPLAY=$DISPLAY -v emplacement-dossier-Wine:/home -v /tmp/.X11-unix:/tmp/.X11-unix utilisateur/wine /bin/bash
Il faut ensuite créer un environnement wine pour 32 bits, ce qu’on peut
faire avec l’instruction dans le shell ouvert dans le container :
WINEARCH=win32 winecfg
On procède ensuite, toujours dans le shell à l’installation normale
d’une application wine. On l’essaie ensuite en la lançant depuis le
shell. Si tout marche correctement, on peut ensuite se fabriquer un
lanceur depuis l’hôte, de type :
docker run -ti --rm -e DISPLAY=$DISPLAY -v emplacement-dossier-Wine:/home -v /tmp/.X11-unix:/tmp/.X11-unix utilisateur/wine /bin/sh -c "cd /home/utilisateur/.wine/drive_c/Program\ Files/Programme/ && wine Prgramme.exe"
Le container se lance et se ferme en même temps que l’application. Voilà
notre vin en sécurité dans le bac à sable…