optWare sur QNAP

J’utilise un QNAP TS259 comme serveur de fichiers dans mon réseau perso. La force et la faiblesse du système de QNAP c’est que beaucoup de choses sont restaurées dans leur état de base à chaque reboot à partir d'une mémoire flash. Ceci protège contre de fausses manips mais rend difficile toute configuration personnelle. Il existe des méthodes pour que ces modifs persistent d’un reboot à l’autre. Mais aucune n'est totalement efficace en cas de mise à jour du firmware.

optWare est un system de gestion de packages adapté aux systèmes Linux embarqués. Il peut être installé par l’intermédiaire d'un package standard (QPKG) de Qnap.Une fois le package optWare installé, on peut utiliser en ligne de commande ipkg pour accéder à plus d’un millier de logiciels compilés pour Intel ou ARM (suivant le type de QNAP) et qui fonctionnent entièrement dans /opt (binaire, config, librairies ect). Tout l’intérêt c’est que le contenu de /opt n’est modifié n’y au reboot n’y à l’occasion d’une mise à jour du firmware.

Le seul problème à résoudre est comment lancer à chaque boot du QNAP les daemons installés via ipkg de optWare (bind, openssh, ect) ? Heureusement QNAP propose un ‘hook’ nommé autorun.sh Dans sa procedure de boot le Qnap appelle ce script. A vous d'y faire ce qui vous arrange.

Voici la procédure pour le mettre en place de la manière la plus simple et la plus efficace possible.

1) A faire une seule fois

ATTENTION

1. suivant la configuration disque et le modèle de votre QNAP, ce qui chez moi s'appelle MD0_DATA peut, par exemple, s’appeler HDA_DATA chez vous. A vous de trouver l'équivalent et d’adapter ce qui suit. 
2. De même ce qui chez moi s’appelle /dev/sdx6 sur mon Qnap peut s’appeler /dev/mtdblock5 sur le votre.

Créer un répertoire

mkdir /share/MD0_DATA/.qpkg/autorun

Entrer dans ce répertoire

cd /share/MD0_DATA/.qpkg/autorun

Créer les 3 scripts shell : autorun.sh run.sh et restore_autorun.sh

Le script autorun.sh

#!/bin/sh 
RUN=/share/MD0_DATA/.qpkg/autorun/run.sh 
[ -x $RUN ] && $RUN

Le script run.sh

#!/bin/sh

RUNDIR="$( cd -P "$( dirname "$0" )" && pwd )"
echo "RUN: " `date` >> $RUNDIR/log.txt

#Start all optWare packages
for i in /opt/etc/init.d/S??* ;do              

     case "$i" in
        *.sh)
            # Source shell script for speed.
            (
                trap - INT QUIT TSTP
                set start 
                . $i
            )
            ;;
        *)
            # No sh extension, so fork subprocess.
            [ -f $i ] && $i start
            ;;
    esac
done

Le script restore_autorun.sh

#!/bin/sh
cd /
mount /dev/sdx6 /tmp/config
cp /share/MD0_DATA/.qpkg/autorun/autorun.sh  /tmp/config/autorun.sh
ls -l  /tmp/config
umount /tmp/config

Rendre les 3 scripts exécutables

chmod +x *.sh

2) A faire la première fois et après chaque changement de firmware

Exécuter cette commande depuis la ligne de commande du Qnap:

/share/MD0_DATA/.qpkg/autorun/restore_autorun.sh

Ceci va copier dans la mémoire flash (dans mon cas /dev/sdx6) le fichier autoruns.sh qui sera appeler à chaque boot.
Ce fichier a pour rôle d'appeler notre run.sh qui effectue le véritable travail.

Pourquoi ne pas tout mettre dans autorun.sh ?
- La place dans la mémoire flash est limité.
- L’accès à la mémoire flash n'est pas immédiat. Il faut d’abord la monter. Ce qui rend l’édition du fichier autoruns.sh pas pratique.

3) Adapter run.sh à vos besoins

Éditez directement le script "/share/HDA_DATA/.qpkg/autorun/run.sh" pour démarrer, initialiser ce qu’il vous plaira.
La version présenté ci-dessus démarre tous les daemons installés par optWare et qui ont un script de démarrage dans /opt/etc/init.d (Tous les packages de optWare ne mettent pas leut script de démarrage là : Lire la doc !)

HG + SSH

Dans le cas où on utilise Mercurial dans un mode client/serveur il faut choisir un protocole de communication entre les clients et le serveur. Cette page récapitule les options possibles.

Si on ne veut pas installer des applications supplémentaires (Rhodecode, hgweb, hg-ssh ect…) la seule solution efficace est ssh. Mais c’est aussi la solution la moins documentée !

Le principe de fonctionnement de hg + ssh est le suivant :
Le hg coté client va utiliser ssh pour exécuter les commandes hg coté serveur et communiquer avec.

Le problème c’est que des commande comme celle-ci on n’a pas envie de les taper ni de rentrer le mot de passe à chaque fois.

“C:\Program Files\TortoiseHg\TortoisePlink.exe” -ssh -2 -i “C:\Documents and Settings\All Users\Documents\ssh\hg\id_rsa.ppk" hg@mon.domaine.com “hg -R /home/hg/repo1 serve –stdio”

Pour automatiser il faut :

• Utiliser un client graphique. Il s’occupera de construire la commande et de l’exécuter.  Le meilleur des clients graphiques est TortoiseHg
• Utiliser ssh avec une paire de clefs publique/privée pour éviter de taper le mot de passe à chaque commande.

1) Installation de Mercurial

On partira du principe que le serveur est sous Unix et le client sous Windows.

* L’installation de TortoiseHg sur le poste Windows n’est pas un problème. Il inclut tout : Mercurial, l'interface graphique et même le client ssh : TortoisePlink.exe (mais on peut en utiliser un autre).
* L'installation de Mercurial sur le serveur Unix est basique. Il suffit d'installer le package correspondant à son Unix ou à sa distribution Linux. (Il faut avoir python 2.6+ deja installé).


2) La paire de clefs publique/privée

Il faut ensuite créer la paire de clefs, déposer la clef publique sur le serveur Unix et expliquer à TortoisePlink ou trouver la clef privée. Attention la clef privée doit être au format ppk. Ce format de clef est propre à PuTTY, et TortoisePlink est basé sur le Plink de PuTTY.

Pour générer cette paire de clefs il faut utiliser puttygen, qui ne fait pas partie de TortoiseHg mais de de PuTTY.  Voir cette page sur comment générer cette paire de clefs avec puttygen.

Important : Pour simplifier ne pas attribuer de passphrase à la clef privée.

Par la suite on supposera que les noms de fichiers pour la paire de clefs sont:
   Publique : hg_rsa.pub
   Privée : hg_rsa.ppk

Déposer la clef publique sur le serveur Unix dans le répertoire de l’utilisateur dédié à hg. En principe on crée un utilisateur nommé ‘hg’ et les repository sont stockés dans son home directory.  Donc on dépose la clef publique hg_rsa.pub dans le répertoire /home/hg/.ssh  du serveur.

Ensuite il faut ajouter cette clef publique à la fin du fichier /home/hg/.ssh/authorized_keys
   cat hg_rsa.pub >> authorized_keys
On peut ensuite supprimer le fichier hg_rsa.pub coté serveur
   rm hg_rsa.pub



3) Mercurial.ini
Il faut maintenant expliquer à Hg comment utiliser ces clefs.
Dans le fichier %USERPROFILE%\Mercurial.ini ajouter dans la section [ui] la ligne

ssh = "C:\Program Files\TortoiseHg\TortoisePlink.exe" -ssh -2 -i "C:\Documents and Settings\Path\To\hg_rsa.ppk"

4) Init + Clone
Coté serveur, en utilisant le user dédié à hg, créer un repository vide:

cd /home/hg
hg init PremierTest

Coté client créer le repertoire PremierTest
Click bouton droit sur ce répertoire puis dans le menu contextuel sélectionner TortoiseHg > Clone ..

Remplacer le contenu du champ « Source » par   
   ssh://hg@mon.serveur.com//home/hg/PremierTest
ou  
   ssh://hg@mon.serveur.com/PremierTest
(en supposant que votre utilisateur soit hg)

ATTENTION : 
  Ne pas oublier le nom du user coté Unix (ici hg)
  Respecter la case du path coté Unix.  
  C'est bien un double / ou un simple / entre le nom du serveur et le path

Quand le path commence par un double / cela signifie qu'il est absolu.
Quand il commence par un simple / cela signifie qu'il est relatif au home directory du user (ici 'hg')

Un path relatif est moins dépendant des variations de l'organisation sur le disque du serveur et est donc préférable car plus stable.

Puis cliquer sur le bouton "Clone".

A partir de là il ne sera plus nécessaire de faire référence à ssh ou au nom du serveur. TortoiseHg a tout enregistré et générera les commandes ssh adéquates.

5) Apprendre !

Voici un très bon tutoriel (plein d'humour) sur Mercurial. Il ne présente que l'utilisation de la ligne de commande (hg). Mais la conversion en clicks sur l'interface graphique de TortoiseHg est facile.

Reverse avec apktool

Si, pour vous instruire sur Android, vous avez regardé le contenu d’un fichier apk (qui est en fait un fichier zip) vous avez constaté que les fichiers texte, comme les xml, sont illisibles. Heureusement il y a apktool !

Apktool est une application open source, écrite en java, qui permet de faire du reverse engineering sur des applications Android (apk).

Attention son téléchargent se fait en deux temps :

1. Le fichier java apktool.jar, le même quelle que soit la plateforme Win/Mac/Linux.
   Le nom de l’archive qui contient ce fichier est de la forme apktool<x.y.z>.tar.bz2
2. Un script et  un binaire (dépendant de la plateforme) pour lancer l’exécution du jar.
   Le nom de l’archive qui contient ce fichier est de la forme apktool-install-<plateforme>-r<xx>-brut1.tar.bz2

On copy l’ensemble de ces fichiers dans le même répertoire. L’idéal est d'avoir ce répertoire dans le PATH
Sous Windows on a donc : apktool.jar + apktool.bat + aapt.exe

USAGE 
Ouvrir une console (boite dos) et taper ( sans oublier le 'd' )

apktool  d  \path\to\application.apk

Un répertoire avec le nom de l’application a été créé dans le repertoire courant. Il contient les fichiers en clair. Il ne vous reste plus qu'a explorer !...
(Pour plus de détails sur les paramètres taper juste : apktool)

Où est le code java ?
Les fichiers java sont présentés sous forme de fichiers "smali". Il s'agit du code assembleur utilisé par la machine virtuelle Dalvik.

Application utile:
Il existe des sites web qui vous proposent de créer enligne votre application Android (et iPhone). Les applications ainsi générées nécessitent des droits très surprenant sans rapport avec les besoins réel de l'application. Que contient le fichier .apk à la fin ? Grâce à apktools vous allez découvrir tout ce qui est ajouté (en cachette) à votre application (pub, appel de numéro, liens vers d'autre sites, player étrange, ect) et tout ce qui en fait n'est pas dans votre application mais sur des serveurs.
Donc, grâce à apktool, j'ai appris qu'il ne fallait surtout pas utiliser ces services : trop gratuits pour être honnêtes  !!
Pour aller plus loin...

Bug du SDK r12 d'Android

Quand on utilise le SDK r12 pour Android et que l’on tente d’exécuter un programme Android depuis Eclipse on obtient cette erreur : 

[2011-07-10 21:00:51 - Emulator] invalid command-line parameter: Files\Android\android-sdk\tools/emulator-arm.exe.

[2011-07-10 21:00:51 - Emulator] Hint: use '@foo' to launch a virtual device named 'foo'.

Le Paramètre invalide Files\Android\android-sdk\tools/emulator-arm.exe est en fait la deuxième partie de C:\Program Files\Android\... coupé par l'espace. Le problème vient donc de l’espace dans le path du SDK: C:\Program Files\Android\android-sdk

Solution :

1) Ouvrir une boite dos et taper la commande 

dir /x \ 

pour déterminer le chemin au format dos du répertoire « \Program Files » 

>dir /x \ 

Répertoire de C:\

17/01/2011  22:45       0    AUTOEXEC.BAT

17/01/2011  22:45       0    CONFIG.SYS 
24/01/2011  10:44    <REP>   DOCUME~1     Documents and Settings
10/07/2011  10:54    <REP>   PROGRA~1     Program Files 
17/06/2011  02:07    <REP>                WINDOWS

Ici le nom dos est “PROGRA~1”

2) Dans Eclipse cliquer dans le menu sur : Window > Preferences > Android

Dans le champ SDK Location remplacer \Program Files\ par \PROGRA~1\