01/07/2016
Rechargement Navigo depuis Ubuntu (2016/06)
Bonjour,
J'ai beaucoup luté ce soir pour recharger mon navigo depuis ma Ubuntu.
Voici quelques pistes pour ceux qui auraient à faire ça un jour (moi inclus).
Première étape : installation des drivers.
Source1 : http://blog.freepeople.fr/bazar/recharger-le-passe-navigo-sous-linux/
Source2 : http://www.blogouillage.net/2012/11/rechargement-du-passe-navigo-sous-linux.html
Il s'avère que dans mon cas, les packetages suivants ont été nécessaires :
* pcscd
* libpcsclite1
* pcsc-tools : peut-être, mais sans certitude, car je ne sais pas quelle partie aurait été utilisée et je ne m'en suis pas servi directement
Le résultat est immédiat:
Parti comme ça, on se dit que ça va bien se passer.
Seconde étape : Maquiller son user-agent pour ne pas que le site détecte un OS Linux
Source1 : http://blog.freepeople.fr/bazar/recharger-le-passe-navigo-sous-linux/
Source2 : http://www.useragentstring.com/Chrome41.0.2227.1_id_19830.php
Le site navigo.fr vérifie le user-agent qu'il reçoit de votre Browser, et si cela ne correspond pas à ce qu'il connaît (c'est à dire windows / mac pour l'OS), il refuse carrément d'envoyer l'applet. Plutôt que de risquer que cela échoue, ils préfèrent ne pas tenter.
On appréciera en particulier la remarque finale qui sous-entend que vous allez changer de système (pour passer à un système payant) et revenir ensuite sur le site de navigo pour terminer votre opération.
Du coup, il faut envoyer un user-agent correspondant à l'un des cas connus.
La source 1 indique d'utiliser le plug-in de Firefo "user agent switcher" pour cette fin, c'est ce que j'ai fait. Par contre les informations qu'il donne sur le user-agent sont un peu anciennes.
La source 2 m'a permis de trouver les derniers users-agents. Le site navigo.fr est assez sympa pour nous corriger quand on lui donne une version qu'il n'aime pas.
Par exemple quand je lui ai fourni le user-agent de chrome 37.0.2062.124, il m'a gentiment répondu
Note : Je suis resté sur un OS Mac, en me disant qu'il y avait moins de chance que les effets de bords soient graves sur un Mac->Debian que sur un Windows->Debian. Après tout, on est en boite noire, on n'a aucune idée de ce que le site peut faire de cette info, si ça se trouve l'applet java chargée n'est pas la même en fonction des user-agent, et il y a plus de chance que l'applet développée pour Mac fonctionne sur une Debian, que l'applet développée pour Windows.
Au final, j'ai utilisé la conf suivante :
Les résultats sont très engageants : le site accepte d'envoyer l'applet, l'applet voie le lecteur de carte et la carte, on peut même consulter le contenu de sa carte via le site.
Yohoo !
Non pas Yohoo.
Troisième étape : La conf de java
Source1 : https://doc.ubuntu-fr.org/java
Source2 : https://www.java.com/fr/download/help/linux_install.xml
Source3 : http://stackoverflow.com/questions/14491322/how-to-add-java-plugin-for-firefox-on-linux
Source4 : http://www.cyberciti.biz/faq/linux-unix-set-java_home-path-variable/
Il s'avère que pour recharger un navigo, il ne suffit pas que l'applet voie le lecteur de carte Navigo et la carte Navigo, il faut aussi qu'elle puisse opérer un paiement par carte-bleue auprès d'une banque.
Or il s'avère qu'OpenJDK 7 (installé par défaut, de même que IceTea-7 sur ma Ubuntu) est (ou du moins semble) incompatible avec l'applet de Navigo. Le symptôme est le suivant : au moment où l'on devrait saisir les informations de paiement, on reçoit le message :
Il m'a donc fallu installer le jdk d'Oracle.
Logiquement, rendu à ce point, on devrait être amené à utiliser update-alternatives, pour choisir laquelle des versions de java est utilisée par défaut :
Mais je n'ai pas eu à le faire car j'ai préalablement désinstallé OpenJDK, ce que je regrette a posteriori.
Le mois prochain peut-être j'essaierais de le réinstaller et de faire fonctionner les deux en alternés.
Une fois java installé , il est reconnu par le système :
Enfin, j'ai mis les JAVA_HOME dans mes exports, en recourant à un
et en ajoutant les lignes suivantes au bashrc :
La conséquence directe de tout ça est un java à la sauce Oracle qui fonctionne en ligne de commande:
Quatrième étape : faire en sorte que firefox voie ce nouveau java
Source1: https://www.java.com/fr/download/help/linux_install.xml
Pour OpenJDK, on pouvait compter sur iced-tea pour faire le lien Firefox java, mais pour Oracle-jdk il faut le faire à la main via un lien symbolique.
Comme cela change d'une version à l'autre et d'une distro à l'autre, il vaut mieux ne pas faire confiance aux chemins qu'on peut trouver dans les tutoriaux ou dans les forums et retrouver soi-même sa librairie libnpjp2.so :
Ce qui m'a permit d'écrire :
Suite à ça, la vérification de la version de java sur le site d'Oracle (https://www.java.com/en/download/installed.jsp) fonctionne depuis Firefox
Et là on pourrait croire qu'on a fini
Cinquième étape : faire en sorte que le java d'oracle trouve le lecteur de carte
Source1 : https://doc.ubuntu-fr.org/smartcards
Source2 : http://www.blogouillage.net/2012/11/rechargement-du-passe-navigo-sous-linux.html
Et non, ce n'est pas fini, car, surprise, en changeant de JDK, on a perdu le lecteur de cartes. Pourquoi, comment .... je ne sais pas, internet fourmille de détails sur un bug connu d'emplacement des libs... mais j'ai eu beau essayer de faire des liens symboliques dans tous les répertoires possibles et imaginables vers la lib de libpcsclite1, rien n'y fit.
Pour tester, je suis passé par le petit programme de la source 1 qui teste libpcsc.
Les commandes suivantes permettent respectivement de compiler le code fourni par cette source, et d'exécuter le "binaire"
produit
et cela donne, en première approche :
Je n'ai donc pas réussi, par le biais d'un lien symbolique à faire fonctionner le PCSC avec le Jdk de Oracle.
En revanche, en précisant à java où trouver la librairie, ça fonctionne :
Ok, logiquement avec tout ça on doit être bon là.
Sixième étape : faire en sorte que l'applet java s'initialise avec les bons paramètres
Source1 : http://stackoverflow.com/questions/28327620/difference-between-java-options-java-tool-options-and-java-opts
Non, on est toujours pas bons, parce que quoi que je mette dans mes exports, je n'arrivais pas à faire en sorte que cette option soit passée à l'applet Navigo.
Jusqu'à ce que je tombe sur cette question stackOverFlow très détaillée, qui m'indique pourquoi il ne faut utiliser ni JAVA_OPTS, ni _JAVA_OPTIONS (comme le disent la plupart des forums), mais bel et bien JAVA_TOOL_OPTIONS.
Du coup, j'ai mis dans mon bashrc (comme précédemment) la ligne suivante :
(attention à penser à le "sourcer" comme plus haut, de manière à ce que l'export soit valide tout de suite)
Attention aussi à démarrer Firefox depuis la console de manière à ce qu'il tienne compte de ce source.
J'ai enfin pu acheter mon ticket. Et voilà comment j'ai perdu la moitié de ma nuit pour éviter de faire 10' de queue demain matin.
Bon après, si j'ai de la chance, le mois prochain ça devrait être plus rapide.
Yohoo !!
---------
Pour la petite anecdote, les mois précédents (depuis plusieurs années en fait), j'utilisais un machine Windows pour recharger mon badge. Mais :
1. Trois fois sur quatre je passais plusieurs heures à réinstaller des drivers et des versions de Java
2. Aujourd'hui, elle ne boote plus, parce qu'elle a décidé, de son propre chef, de changer d'OS au profit de Windows 10.
Ce que j'espère finalement, c'est que, malgré ce démarrage un peu rugueux, Ubuntu m'apportera la robustesse qui fait défaut à Windows.
---------
Ah, et sinon, le prochain candidat en entretien qui me cite la portabilité comme atout de Java sur d'autres langage ferait bien d'avoir lu ce post auparavant.
J'ai beaucoup luté ce soir pour recharger mon navigo depuis ma Ubuntu.
Voici quelques pistes pour ceux qui auraient à faire ça un jour (moi inclus).
Première étape : installation des drivers.
Source1 : http://blog.freepeople.fr/bazar/recharger-le-passe-navigo-sous-linux/
Source2 : http://www.blogouillage.net/2012/11/rechargement-du-passe-navigo-sous-linux.html
Il s'avère que dans mon cas, les packetages suivants ont été nécessaires :
* pcscd
* libpcsclite1
* pcsc-tools : peut-être, mais sans certitude, car je ne sais pas quelle partie aurait été utilisée et je ne m'en suis pas servi directement
Le résultat est immédiat:
>:~$ pcsc_scan
PC/SC device scanner
V 1.4.22 (c) 2001-2011, Ludovic Rousseau
Compiled with PC/SC lite version: 1.8.10
Using reader plug'n play mechanism
Scanning present readers...
0: Alcor Micro AU9520 00 00
Fri Jul 1 01:27:33 2016
Reader 0: Alcor Micro AU9520 00 00
Card state: Card inserted,
...
Parti comme ça, on se dit que ça va bien se passer.
Seconde étape : Maquiller son user-agent pour ne pas que le site détecte un OS Linux
Source1 : http://blog.freepeople.fr/bazar/recharger-le-passe-navigo-sous-linux/
Source2 : http://www.useragentstring.com/Chrome41.0.2227.1_id_19830.php
Le site navigo.fr vérifie le user-agent qu'il reçoit de votre Browser, et si cela ne correspond pas à ce qu'il connaît (c'est à dire windows / mac pour l'OS), il refuse carrément d'envoyer l'applet. Plutôt que de risquer que cela échoue, ils préfèrent ne pas tenter.
On appréciera en particulier la remarque finale qui sous-entend que vous allez changer de système (pour passer à un système payant) et revenir ensuite sur le site de navigo pour terminer votre opération.
Du coup, il faut envoyer un user-agent correspondant à l'un des cas connus.
La source 1 indique d'utiliser le plug-in de Firefo "user agent switcher" pour cette fin, c'est ce que j'ai fait. Par contre les informations qu'il donne sur le user-agent sont un peu anciennes.
La source 2 m'a permis de trouver les derniers users-agents. Le site navigo.fr est assez sympa pour nous corriger quand on lui donne une version qu'il n'aime pas.
Par exemple quand je lui ai fourni le user-agent de chrome 37.0.2062.124, il m'a gentiment répondu
Votre navigateur Internet ou sa version Google Chrome 37.0 n'est pas compatible avec le service de rechargement/lecture de passe.
Le service de rechargement/lecture de passe est optimisé pour les versions de Google Chrome 40.0 et ultérieures :
Note : Je suis resté sur un OS Mac, en me disant qu'il y avait moins de chance que les effets de bords soient graves sur un Mac->Debian que sur un Windows->Debian. Après tout, on est en boite noire, on n'a aucune idée de ce que le site peut faire de cette info, si ça se trouve l'applet java chargée n'est pas la même en fonction des user-agent, et il y a plus de chance que l'applet développée pour Mac fonctionne sur une Debian, que l'applet développée pour Windows.
Au final, j'ai utilisé la conf suivante :
Description : Mac
User Agent : Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2227.1 Safari/537.36
App Code Name : Mozilla
App Name : Netscape
App Version : 5.0 (X11)
Platform : Macintosh Intel Mac OS X 10_6_8
Les résultats sont très engageants : le site accepte d'envoyer l'applet, l'applet voie le lecteur de carte et la carte, on peut même consulter le contenu de sa carte via le site.
Yohoo !
Non pas Yohoo.
Troisième étape : La conf de java
Source1 : https://doc.ubuntu-fr.org/java
Source2 : https://www.java.com/fr/download/help/linux_install.xml
Source3 : http://stackoverflow.com/questions/14491322/how-to-add-java-plugin-for-firefox-on-linux
Source4 : http://www.cyberciti.biz/faq/linux-unix-set-java_home-path-variable/
Il s'avère que pour recharger un navigo, il ne suffit pas que l'applet voie le lecteur de carte Navigo et la carte Navigo, il faut aussi qu'elle puisse opérer un paiement par carte-bleue auprès d'une banque.
Or il s'avère qu'OpenJDK 7 (installé par défaut, de même que IceTea-7 sur ma Ubuntu) est (ou du moins semble) incompatible avec l'applet de Navigo. Le symptôme est le suivant : au moment où l'on devrait saisir les informations de paiement, on reçoit le message :
Paiement refusé !
Il m'a donc fallu installer le jdk d'Oracle.
cd /usr/local/
sudo mkdir java
sudo mv /home/pouet/Downloads/jdk-8u91-linux-x64.tar.gz ./java/
cd java
sudo tar zxvf jdk-8u91-linux-x64.tar.gz
sudo update-alternatives --install /usr/local/java java
sudo update-alternatives --install /usr/bin/java java /usr/local/java/jdk1.8.0_91/bin/java
sudo update-alternatives --install /usr/bin/java java /usr/local/java/jdk1.8.0_91/bin/java 1
Logiquement, rendu à ce point, on devrait être amené à utiliser update-alternatives, pour choisir laquelle des versions de java est utilisée par défaut :
sudo update-alternatives --config java
sudo update-alternatives --config javac
sudo update-alternatives --config javaws
Mais je n'ai pas eu à le faire car j'ai préalablement désinstallé OpenJDK, ce que je regrette a posteriori.
Le mois prochain peut-être j'essaierais de le réinstaller et de faire fonctionner les deux en alternés.
Une fois java installé , il est reconnu par le système :
>:~$ which java
/usr/bin/java
>:~$ ls -l /usr/bin/java
lrwxrwxrwx 1 root root 22 juil. 1 00:00 /usr/bin/java -> /etc/alternatives/java
>:~$ update-alternatives --config java
There is only one alternative in link group java (providing /usr/bin/java): /usr/local/java/jdk1.8.0_91/bin/java
Enfin, j'ai mis les JAVA_HOME dans mes exports, en recourant à un
sudo emacs /etc/bash.bashrc
source /etc/bash.bashrc
et en ajoutant les lignes suivantes au bashrc :
export JAVA_HOME=/usr/local/java/jdk1.8.0_91/bin/java
La conséquence directe de tout ça est un java à la sauce Oracle qui fonctionne en ligne de commande:
>:~$ java -version
java version "1.8.0_91"
Java(TM) SE Runtime Environment (build 1.8.0_91-b14)
Java HotSpot(TM) 64-Bit Server VM (build 25.91-b14, mixed mode)
Quatrième étape : faire en sorte que firefox voie ce nouveau java
Source1: https://www.java.com/fr/download/help/linux_install.xml
Pour OpenJDK, on pouvait compter sur iced-tea pour faire le lien Firefox java, mais pour Oracle-jdk il faut le faire à la main via un lien symbolique.
Comme cela change d'une version à l'autre et d'une distro à l'autre, il vaut mieux ne pas faire confiance aux chemins qu'on peut trouver dans les tutoriaux ou dans les forums et retrouver soi-même sa librairie libnpjp2.so :
sudo updatedb
sudo locate libnpjp2.so
Ce qui m'a permit d'écrire :
ln -s /usr/local/java/jdk1.8.0_91/jre/lib/amd64/libnpjp2.so /usr/lib/firefox-addons/plugins/libnpjp2.so
Suite à ça, la vérification de la version de java sur le site d'Oracle (https://www.java.com/en/download/installed.jsp) fonctionne depuis Firefox
Et là on pourrait croire qu'on a fini
Cinquième étape : faire en sorte que le java d'oracle trouve le lecteur de carte
Source1 : https://doc.ubuntu-fr.org/smartcards
Source2 : http://www.blogouillage.net/2012/11/rechargement-du-passe-navigo-sous-linux.html
Et non, ce n'est pas fini, car, surprise, en changeant de JDK, on a perdu le lecteur de cartes. Pourquoi, comment .... je ne sais pas, internet fourmille de détails sur un bug connu d'emplacement des libs... mais j'ai eu beau essayer de faire des liens symboliques dans tous les répertoires possibles et imaginables vers la lib de libpcsclite1, rien n'y fit.
Pour tester, je suis passé par le petit programme de la source 1 qui teste libpcsc.
Les commandes suivantes permettent respectivement de compiler le code fourni par cette source, et d'exécuter le "binaire"
produit
> javac TestSmartCardIO.java
> java TestSmartCardIO
et cela donne, en première approche :
Terminals count: 0
Terminals: []
java.lang.IndexOutOfBoundsException: Index: 0
at java.util.Collections$EmptyList.get(Collections.java:4454)
at TestSmartCardIO.main(TestSmartCardIO.java:25)
Je n'ai donc pas réussi, par le biais d'un lien symbolique à faire fonctionner le PCSC avec le Jdk de Oracle.
En revanche, en précisant à java où trouver la librairie, ça fonctionne :
>:~$ java -Dsun.security.smartcardio.library=/lib/x86_64-linux-gnu/libpcsclite.so.1 TestSmartCardIO
Picked up JAVA_TOOL_OPTIONS:
Terminals count: 1
Terminals: [PC/SC terminal Alcor Micro AU9520 00 00]
Card: PC/SC card in Alcor Micro AU9520 00 00, protocol T=0, state OK
...
Ok, logiquement avec tout ça on doit être bon là.
Sixième étape : faire en sorte que l'applet java s'initialise avec les bons paramètres
Source1 : http://stackoverflow.com/questions/28327620/difference-between-java-options-java-tool-options-and-java-opts
Non, on est toujours pas bons, parce que quoi que je mette dans mes exports, je n'arrivais pas à faire en sorte que cette option soit passée à l'applet Navigo.
Jusqu'à ce que je tombe sur cette question stackOverFlow très détaillée, qui m'indique pourquoi il ne faut utiliser ni JAVA_OPTS, ni _JAVA_OPTIONS (comme le disent la plupart des forums), mais bel et bien JAVA_TOOL_OPTIONS.
Du coup, j'ai mis dans mon bashrc (comme précédemment) la ligne suivante :
export JAVA_TOOL_OPTIONS="-Dsun.security.smartcardio.library=/lib/x86_64-linux-gnu/libpcsclite.so.1"
(attention à penser à le "sourcer" comme plus haut, de manière à ce que l'export soit valide tout de suite)
Attention aussi à démarrer Firefox depuis la console de manière à ce qu'il tienne compte de ce source.
J'ai enfin pu acheter mon ticket. Et voilà comment j'ai perdu la moitié de ma nuit pour éviter de faire 10' de queue demain matin.
Bon après, si j'ai de la chance, le mois prochain ça devrait être plus rapide.
Yohoo !!
---------
Pour la petite anecdote, les mois précédents (depuis plusieurs années en fait), j'utilisais un machine Windows pour recharger mon badge. Mais :
1. Trois fois sur quatre je passais plusieurs heures à réinstaller des drivers et des versions de Java
2. Aujourd'hui, elle ne boote plus, parce qu'elle a décidé, de son propre chef, de changer d'OS au profit de Windows 10.
Ce que j'espère finalement, c'est que, malgré ce démarrage un peu rugueux, Ubuntu m'apportera la robustesse qui fait défaut à Windows.
---------
Ah, et sinon, le prochain candidat en entretien qui me cite la portabilité comme atout de Java sur d'autres langage ferait bien d'avoir lu ce post auparavant.
01:51 | Lien permanent | Commentaires (0)