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:

>:~$ 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.


error_please_change_os.png


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 !

overview.png



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.

04/01/2016

Argparse (Note pour moi-même)

- Parce que je n'ai jamais réussi à apprendre par coeur les noms des méthodes de argparse,
- Parce que j'ai toujours pratiquement les mêmes cas d'utlisation,
- Parce que ces cas ne ressortent pas vraiment dans l'aide d'argparse,
Je note ces cas ici :

parser = argparse.ArgumentParser(description="What I do")
parser.add_argument("astFile", help="the path where to find source ast")
parser.add_argument("resultPath", help="the path where to write results")
args = parser.parse_args()

et

parser = argparse.ArgumentParser(description="What I do")
subparsers = parser.add_subparsers(title="commands", dest="action")
subparsers.add_parser("start", help="start everything")
subparsers.add_parser("stop", help="stop everything")
subparsers.add_parser("status", help="get status")
args = parser.parse_args()

14/07/2015

Postfix / Sasl via Courier / cannot connect to Courier authdaemond

Hello,

This small note just to remind me, what just happened as I upgrade a debian with an installed postfix using courier as SASL authentifiaction (for smtp)

1. First, the smtp daemon had no access to the courier socket.

Symptom :


tail /var/log/mail.info
SASL authentication failure: cannot connect to Courier authdaemond: Connection refused


Explanation :

For some reason, the smtp daemon is chrooted again. There maybe is a solution to allow him to access to courier socket even if it is chrooted, but I didn't find any (played some time with symbolic links but unsuccessfully. Tried to ask courier to put its socket in postfix chroot jail, but didn't work either)

So I choosed to unchroot it :

sudo emacs /etc/postfix/master.cf
smtp inet n - n - - smtpd


And then restart postfix of course.

2. Then, the smtp daemon had no right anymore to read the courier socket.

Symptom :

tail /var/log/mail.info
SASL authentication failure: cannot connect to Courier authdaemond: Permission denied


Explanation :
The rights on the socket folder went wrong. Be carefull, the rights on the socket itself where good.


ls -l /var/run/courier/authdaemon/socket
ls: cannot access /var/run/courier/authdaemon/socket: Permission denied

sudo ls -l /var/run/courier/authdaemon/socket
srwxrwxrwx 1 root root 0 Jul 14 21:31 /var/run/courier/authdaemon/socket

sudo ls -l /var/run/courier/
drwxr-x--- 2 daemon daemon 100 Jul 14 21:31 authdaemon


I choosed to add postfix in the daemon group :

sudo usermod -a -G daemon postfix