Olivier a écrit 889 commentaires

une boutique en ligne, y a souvent des photos, donc un peu de volume à envoyer

Passé un temps, cela se faisait de faire héberger les gros contenus statiques (les images) sur des serveurs à grosse bande passante, et les contenus dynamique en local. Ainsi, les besoins de bande passante pour sa connexion Free sont plus faibles.

Le problème, c'est les mécanismes anti-pub des machines clientes peuvent prendre ceci pour un hébergement de pub externes, et empêcher l'affichage des images.

Une solution propre serait ceci :
- le site web est hébergé sur la connexion Free, via http://www.le-site-de-commerce.com/
- les images sont hébergés sur un serveur externe à "grosse" bande passante, via http://images.le-site-de-commerce.com/ , où "images.le-site-de-commerce.com" renvoie sur l'adresse IP du dit serveur externe.

Les images sont à uploader sur le serveur externe qu'une seule fois, où via un mécanisme automatique simple d'utilisation, comme une synchronisation automatique FTP.

Les jeux Windows nécessitent DirectX, qui est un ensemble de "fonctionnalités" regroupant la vidéo (Direct3D), mais aussi le son, le réseau, les entrées, etc...

Même si Linux pourrait avoir une implémentation efficace de Direct3D, il n'en reste pas moins que les autres aspects de DirectX ne sont pas encore implémentés, et que cela représente sans doute pas mal de boulot.

Or, leur absence empêchera, vraisemblablement, le jeu de fonctionner correctement.

A moins d'utiliser ce qui existe déjà dans Wine ?

La très grande majorité des jeux propriétaires sous Windows ayant des protections anti-copie (basée sur l'utilisation du CDROM, ou sur une vérification via une connexion Internet), je me demande si les éditeurs de jeux voient réellement la plateforme Linux comme un moyen de faire de l'argent.

Déjà que sous Windows il existe toutes sortes de mécanismes de contournement des ces protections, sans même parler de patch/crack sur les binaires des jeux, les éditeurs de jeux risquent de voir dans les interfaces open-sources de Linux, un moyen supplémentaire de contourner leurs protection.

Bref, même si Linux propose un mécanisme natif pour Direct3D, le fait que les mécanismes anti-copie des jeux peuvent être potentiellement plus "fragiles" sous Linux, risque fort de ne pas être suffisant pour attirer les éditeurs de jeux proprios sous Linux.

J'ai eu un problème similaire il y a quelques années sur une Debian, avec une machine doté de 2 controleurs SCSI différents, et dont je voulais forcer un ordre précis de chargement de modules (afin d'avoir un certain ordre dans le montage des disques).

La solution a été de lister les modules, dans l'ordre de leur chargement, dans le /etc/initramfstools.d/modules , puis de regénerer le /initrd via la commande "initramfs-update -k all -u"

Au reboot suivant, les modules étaient chargés dans le bon ordre.

Voir à ce sujet : http://www.linuxquestions.org/questions/linux-general-1/modu(...)

Le problème ici, est que le module est chargé dans le initrd, et donc avant les mécanismes de /etc/modprobe.*, /etc/modules, udev, etc... Il faut donc configurer ceci dans le initrd, en passant par initramfs.

Tu définis la variable d'environnement LD_LIBRARY_PATH=<le chemin des libs que tu empaquetes avec ton soft> dans le shell qui va exécuter le programme que tu veux lancer.

Ainsi, lorsque le programme va vouloir charger des librairies, il va d'abord les chercher dans les répertoires indiqués dans LD_LIBRARY_PATH. Si il ne trouve pas les libs qui l'intéresse, il va les chercher dans les libraires du système (définit par /etc/ldconfig il me semble).

Tu peux même créer un "wrapper" qui fait le boulot à ta place.

Exemple d'un soft ("toto") que tu installes dans ton $HOME. L'exécutable à lancer est toto/bin/toto :

toto/
toto/bin/
toto/bin/toto
toto/lib/
toto/lib/toto.so

Tu te crées un "wrapper" toto/bin/toto.sh , qui fait cela :

#!/bin/sh
LD_LIBRARY_PATH=~/toto/lib/
exec ~/toto/bin/toto

Et tu lances ~/toto/bin/toto.sh

Ce que je demande, c'est qu'ils puissent tous évoluer indépendamment, qu'on puisse avoir une update du tableur seul, sans qu'on ait besoin de toucher au reste.


Je suis du même avis que le commentaire ci-dessus : Avoir sur une même machine des versions inégales des différents composants pourraient apporter des problèmes d'incompatibilité. Par exemple, lors de l'exportation d'un composant "tableur" dans celui de "présentation".

Ceci étant, je pense qu'il est faisable d'avoir plusieurs installations différentes d'OpenOffice sur la même machine, afin par exemple de faire des procéder à des tests d'une nouvelle version. Tu peux par exemple compiler/installer la nouvelle version dans /opt/ ou dans /usr/local/openoffice/version xx/

Enfin, j'ajouterai que certaines distribution, comme Debian, propose des paquets indépendants pour les différents composants majeurs d'OpenOffice. Par exemple, il y a un paquet oocalc, indépendant de oowriter : http://packages.debian.org/squeeze/openoffice.org-calc . Par contre, il est évident que ce type de paquet est dépendant de paquets commun (openoffice*core).

Ce qui est pourri, c'est qu'une fois qu'une applet flash utilisant du son ait été lancé sur mon iceweasel, je suis obligé de tuer iceweasel pour que mplayer puisse lire une vidéo _avec_ du son.

Je ne sais pas quelle distrib tu utilises, mais chez moi j'ai :
- Debian Squeeze/Testing
- Iceweasel
- plugin flash proproi ("aptitude install flashplayer-nonfree")
- mplayer, vlc, ...
- KDE4 avec Phonon

Et je n'ai aucun problème pour écouter du son avec mplayer (qui balance tout sur ALSA),pendant qu'une vidéo youtube est lancée

Je te suggère de lancer iceweasel depuis un teminal, et de voir les messages qui sont affichés par flash lorsqu'il est exécuté.

Le système de fichier est peut-être corrompu. As-tu lancé un fsck pour vérifier/corriger les problèmes ?

Autre idée : Je ne sais pas pour xfs, mais pour ext, il y a un répertoire "lost+found" qui regroupe les fichiers "trouvés" par un fsck.ext qui ne correspondent plus à rien (typiquement, suite à un reboot violent de la machine). Peut-être que xfs a un tel mécanisme, et que ce répertoire est plein de ce type de fichiers ?

Ah oui, les http://www.pcengines.ch/alix3d3.htm et http://www.pcengines.ch/alix1d.htm

Merci pour l'info !

Oups, boulette de ma part.Je voulais parler du : BeagleBoard-xM

http://farm5.static.flickr.com/4068/4644432552_2fb4280336.jp(...)


# S-video (TV out)
# Stereo audio out/in

D'après les docs, le GuruPlug Server Plus est doté de connectique audio.

Est-ce que l'on pourrait l'utiliser pour en faire un serveur de son, relié à une chaine audio ? Stockage de musique sur un disque dur externe, ou lecture de podcast sur le web ?

Cordialement

Pour commencer, tu peux regarder la liste des process en cours d'utilisation. Pour cela, utilise la commande "top" (ctrl+C pour en sortir). La charge moyenne en temps réel s'affiche en haut à droite (valeur temps réel, et moyennées)

Ensuite, tu peux déterminer si d'une manière général, ce sont les applications graphiques qui sont l cause du ralentissement :
- bascule sur le mode console (ctrl + alt + f1)
- lance "top", et regarde la charge moyenne sur 1 minute
- bascule sur autre console (ctrl + alt + f2)
- tue X : sudo /etc/init.d/gdm stop
- revient sur lapremière console (ctrl + alt + f1)
- regarde la charge moyenne sur 1 minute

Si la charge décroit, c'est que le problème vient de X, ou d'une application graphique.

Redémarre X (sudo /etc/init.gdm start), et bascule en mode graphique si ce n'est pas fait (ctrl+alt+fx ou x est >=6)

Ça reste lourd, non? quel effet sur ta machine?
La première commande a pris 1 minute sur ma machine. Un fichier de 6Mo a été généré. J'ai dans les 1500 paquets Debian.

La seconde commande à dus prendre 2min. Je l'ai relancé plusieurs fois pour mettre au point les filtres, et comme l'arborescence des fichiers était dans le cache disque, cela ne prenait beaucoup moins de temps, et uniquement du temps CPU.

Bref, c'est très largement utilisable.

L'analyse des données, elle, prendra plus de temps. J'utilise "xxdiff" pour comparer les données, mais n'importe quel soft de diff, graphique ou non, peut servir.

A noter qu'une Debian créé plein de liens symboliques, par exemple /bin/csh -> /bin/sh, ce qui fait apparaître des différences inutiles entre les deux fichiers. Il doit être possible de demander à "find" de ne pas afficher les liens symboliques (pour ne pas les suivre, c'est facile, il y a le "-follow").

utiliser locate (ou sa base de données) pour lister les fichiers
puis utiliser dlocate (ou ses base de données) pour trouver le paquet d'origine

"locate" est le premier truc que je désactive sur une machine. Lorsqu'il se met à scanner les disques durs lors du démarrage du cron, cela m'irrite de voir mon disque s'allumer pour rien.

Je préfère utiliser une commande "find" lorsque je cherche un fichier, d'autant qu'à de très rares exceptions près, je sais déjà plus où moins où se trouve le fichier.

Et comment les enlever?
Il y a bien sûr des procédés lourds, par exemple vérifier la provenance de chaque fichier avec dpkg, mais ce serait trop long, je pense (?). Personne n'a une astuce géniale?

Une idée génial, je dirais non. Mais je vois bien un moyen d'arriver à trouver quels sont les fichiers qui sont "étranger" à système actuel :

- D'abord récupérer la liste des paquets installés:
dpkg -l|sed -e '/^[ir]/!d' -e 's/ */ /g' -e 's/^[^ ]* \([^ ]*\).*/\1/g'

- Pour chaque élément de cette liste, faire un "dpkg -L" (qui donne la liste des fichiers du paquet). Trier le résultat. On en obtient la liste des fichiers normalement installés :

(for I in `dpkg -l|sed -e '/^[ir]/!d' -e 's/ */ /g' -e 's/^[^ ]* \([^ ]*\).*/\1/g'`; do dpkg -L $I; done) | sort -u > liste_originelle.txt

- D'un autre coté, on demande la liste des fichiers & répertoire du disque, auquel on appliquera des filtres, afin de supprimer ce qui ne vient pas de la distribution (/home/, /tmp/, ...)

find /|sed -e '/\/home/d' -e '/\/tmp/d' -e '/\/var\/log/d' -e '/\/mnt/d' -e '/\/proc/d' -e '/\/dev/d' -e '/\/root/d' -e '/\/sys/d' | sort > /tmp/liste_actuelle.txt

- Après, il faut faire un "diff", et analyser le résultat à la main : Long et fastidieux... Je viens de regarder le résultat chez moi, c'est assez intéressant. J'ai trouvé des programmes écrits en python que j'avais compilé par le passé, et dont j'avais oublié l'existence.

- Il restera forcement des "choses" qui sont rajoutés par le système lors des scripts de post-installation, et qui n'apparaissent pas dans le "dpkg -L" :
- Par exemple, les gestionnaires de paquets Debian crées pleins de fichiers utiles dans /var/lib/, ou /var/cache/
- Autre exemple : Les paquets kernel ou initramfs créent en post-installation les /boot/vmlinuz*, qui sont primordiaux au boot de la machine

Il suffit de faire un dpkg -P ou un aptiture remove --purge pour supprimer toute trace du paquet, y compris les fichiers créés pour configuration (sauf peut-être les trucs dans /var, mais ça n'est pas critique).

Je fais toutes mes suppression de paquet par "aptitude purge".

Il n'empêche que pour les suppression de paquets de Kernel, en Debian squeeze/testing, il me laisse toujours des fichiers qui trainent dans /lib/module/<kernel version>/

PS: tu veux pas partager ton script?

Aucun problème


#!/bin/bash -norc

###############################################################################
# This program do maintenance package tasks
#
# This program is under licence GPL :
# http://www.gnu.org/licenses/gpl.html
#
# This program:
# - Remove orphan packages
# - Remove 'rc' packages (see "dpkg -l" result)
# - Some of 'rc' packages are not empty, so we could remove it let's user
# to delete it manually (package list supplied)
#
# Author: Olivier ALLARD-JACQUIN / http://olivieraj.free.fr/
# Version: 1.1
# Creation date: 2008/09/06 Last update: 2009/02/16
###############################################################################

TotalPackageCount() {

LANG=C dpkg -l | \
grep "^[ir][ic]" | \
wc -l
}

PackageCouldBePurgedCount() {

LANG=C dpkg -l | \
grep "^[r][c]" | \
wc -l
}

SelectEmptyPackageToPurge() {

for I in `LANG=C dpkg -l |grep "^[r][c]"|awk '{print $2}'`; do

if [ -n "`LANG=C dpkg -L $I | grep 'does not contain any files'`" ]; then

echo -ne "$I "
fi
done
}

SelectNonEmptyPackageToPurge() {

for I in `LANG=C dpkg -l |grep "^[r][c]"|awk '{print $2}'`; do

echo -ne "$I "
done
}

PurgeOrphanedPackage() {

local Result

echo "+ Looking for orphaned packages..."

IFS=$'\n'
local Orphaned=`deborphan`
unset IFS
if [ -n "$Orphaned" ]; then

echo " - Orphaned packages found ($Orphaned)"
echo -ne " Do you want me to purge orphaned packages ? [Y/n] "
read Result

if [ -z "$Result" ] || [ "$Result" == "Y" ] || [ "$Result" == "y" ]; then

echo " - Purging orphaned packages... "
aptitude purge $Orphaned
Result="$?"

if [ "$Result" == "0" ]; then

echo " - Purging orphaned packages... OK"
else

echo " - Purging orphaned packages... FAILED"
fi

else

echo " - Skipping orphaned packages purge !"
fi

else

echo " - No orphaned package found"
fi
}

PurgeRcPackage() {

local Result

echo "+ Looking for 'rc' packages..."

local Packages=`SelectEmptyPackageToPurge`
if [ -n "$Packages" ]; then

echo " - 'rc' packages found ($Packages)"
echo -ne " Do you want me to purge 'rc' packages ? [Y/n] "
read Result

if [ -z "$Result" ] || [ "$Result" == "Y" ] || [ "$Result" == "y" ]; then

echo " - Purging 'rc' packages... "
aptitude purge $Packages
Result="$?"

if [ "$Result" == "0" ]; then

echo " - Purging 'rc' packages... OK"
else

echo " - Purging orphaned packages... FAILED"
fi

else

echo " - Skipping 'rc' packages purge !"
fi

else

echo " - No 'rc' package could be deleted"

Result=`PackageCouldBePurgedCount`
if [ "$Result" != "0" ]; then

echo " - I've found $Result 'rc' packages, but they are not empty
- If you want, you could maunally purge those package, by using following command :
aptitude purge `SelectNonEmptyPackageToPurge`
- Skipping purge..."
fi
fi
}

MainProgram() {

echo "+ Total installed packages: `TotalPackageCount`"
echo "+ 'rc' packages could be removed: `PackageCouldBePurgedCount`"

PurgeOrphanedPackage
PurgeRcPackage

echo "+ Total installed packages: `TotalPackageCount`"
echo
}

# Main program
MainProgram


La mise en page DLFP casse toute l'indentation, mais le code reste lisible.

Si une action a été faite (purge d'un paquet, etc..), on peut relancer le script afin de voir si il n'y a pas d'autres actions à refaire (par exemple, un nouvel orphelin). Je dois l'améliorer pour intégrer cela dans une boucle, mais ce n'est pas une de mes priorité actuelle.

Comment argumenter cette position ?
La logique je dirais ?

As-tu mesuré l'impact performance d'utiliser un fichier plutôt qu'un device block ?
Pas dans le cas de VirtualBox et de la virtualisation, car cela dépend de trop de choses "parasites", dont entre autre l'OS virtualisé lui-même.

Par contre, j'ai déjà procédé à des tests de "dd" ("dd if=/dev/sda bs=1024 > /dev/null") en attaquant directement le disque dur, où un fichier qui se trouvait sur la même partition ("dd if=~/mon_fichier bs=1024 > /dev/null"), et j'ai effectivement noté des différences de performances. Pas très grosses, certes, mais existantes.

Parce que pour l'exploitation (sauvegarde, toussa) les fichiers c'est plus pratique quand même.
Indiscutablement.

Par contre, il faut voir que la solution d'avoir l'OS virtualisé directement sur la partition permet aussi de lancer celui-ci à part, sans virtualisation du tout. Cela ne sert pas forcément pour de l'exploitation, mais pour un particulier, cela peut-être une option utile.

Eh? t'as trop utilisé Windows, toi!

C'est quoi Windows ?

Plus sérieusement, je suis suis sur Debian Testing depuis 4 ans, et avant j'ai fait 6 ans de Mandrake/Mandriva, donc les problèmes de mises à jour successives / roling release, je connais...

Tu sais qu'il est possible de faire exactement la même chose sans tout réinstaller?

Il ne t'est sans doute jamais venu à l'esprit que de temps en temps, les paquets pouvaient laisser de petites erreurs un peu partout ? Tu n'as jamais lancé un "aptitude update" à la main, et lu les intéressantes lignes qui s'affichaient à l'écran ? Dommage, tu aurais eu l'occasion de voir des messages d'avertissement :
- Pas des trucs très problèmatiques, mais bon nombre de fichiers / répertoires qui ne sont pas purgés pour faute de répertoires non vides (exemple le plus souvent sur Debian Testing : Le /lib/modules/[version des kernels désinstallés]/).
- Plus récemment encore, j'ai eu des entrées dans /etc/udev/ qui étaient fausses, et qui dataient d'un vieux paquets (Debian) à propos d'imprimantes HP.

Le dernier truc en date : Je viens de lire que sous Ubuntu, Evolution vient de se débarrasser du dernier paquet bonobo. Je n'ai pas pu le vérifier (je suis Debian, et j'utilise KDE), mais je me demande si une mise à jour Ubuntu 9.xx -> 10.xx pense bien à supprimer tout ce qui traîne sur le disque à propos de bonobo. Si ce n'est pas le cas, il reste des paquets inutiles sur la machine. Chose que tu n'aurais pas si tu installais la même Ubuntu from scratch.

Mais le plus accessible reste Synaptic qui propose une liste des paquets obsolète, des paquets orphelins (il faut installer deborphan pour que ça marche),
Merci, mais je connais depuis un sacré bout de temps. Je me suis même fait un script à base de deboprhan et de dpkg,qui me purge les paquets obsolete et les paquets "rc" (synaptic est clairement trop long à démarrer)

Enfin, pour ton info deborphan n'est pas 100% efficace. J'ai souvent trouvé des paquets installés sur ma machine qui n'étaient plus utiles (hors paquet "rc"). J'ai donc dûs les supprimer à la main.

D'une manière générale, une Debian Testing prend en permanence du "poids" en terme de nouveaux paquets. Hors, une installation "from scratch" avec le même niveau de fonctionnalité ne possède pas le même nombre de paquets.

Plutôt que de faire des mises à jour majeur successives, je te conseille de réinstaller ton Ubuntu "from scratch".

Cela dit, j'espère que tu as un /home sur une partition à part, cela n'en sera que plus facile.

Une réinstallation complète permet de supprimer les fichiers & paquets devenus inutiles, et généralement, la machine marche mieux après cela.

Evidement, tu perds toutes les configuration que tu as mis en place (exemple : serveur apache, serveur SQL, etc..), mais rien ne t'empêche de faire un bon backup du /etc/ avant de faire la mise à jour.

Enfin, les migrations successives de GNOME ont pu plus ou moins corrompre ton ~/.gnome*/ Tu peux supprimer ces répertoires, et repartir sur un bureau "tout neuf". Mais bon, au passage tu perdras toutes tes personnalisation de GNOME et des applications qui y sont liées.

ou pas. Par exemple un windows XP virtualisé sur un linux avec beaucoup de ram voit ses performances disques décuplées (car linux fait du cache disque pour lui).

Tu te trompes de troll. Il ne s'agit pas de comparer les perfs d'un Windows natif avec un Windows virtualisé.

Il s'agit de comparer un Windows virtualisé dans un fichier d'image de disque, avec le même Windows virtualisé directement sur une partition.

Dans les deux cas, Linux assurera le cache disque, d'où de bonnes perfs. Mais dans le 2nd cas, Linux ne perdra pas de temps à passer par les inode pour savoir où écrire les données. D'où (encore) amélioration des performances.

Aucune idée, je n'ai jamais eu besoin de faire cela.

D'un autre coté, si on voit comment cela se passe avec l'USB (pour la version "non-free"), j'ai l'impression que VB contourne pas mal les drivers USB de Linux afin de parler directement avec les périphériques.

Si c'est ce qui se fait aussi avec le CDROM, j'imagine que cela doit marcher.

En même temps, si tu dédies une partition hôte à un unique fichier image, de facto il ne devrait pas y avoir de problème de fragmentation, si ?

Si la partition hôte est en NTFS, le fichier image de disque sera quand même fragmenté, parce qu'une partition NTFS réserve des zones d'adressages en plein milieu du disque. On appelle cela la MFT (Master File Table) Un outil de défragmentation pour Windows te le montrera.

Pire encore : Cet espace pré-alloué est tellement grand, plusieurs Go pour 100Go de disque, que lorsque tu veux remplir à 100% ce disque, de l'espace libre va être trouvé dans la MFT. Il s'ensuit donc une fragmentation plus importante encore.

Pour ce qui est de Linux, il y a un mécanisme assez similaire : Les super-bloc, et la zone réservée (lire "-m reserved-blocks-percentage" dans "man mkfs.ext3")

Enfin, dans le cas de l'utilisation d'une partition à la place d'un fichier, si gros et non-fragmenté soit-il, il reste que dans le 1er cas, VirtualBox accède directement au disque (en passant par le driver de l'hôte). Alors que dans le 2nd cas, il doit passer par la couche de lecture§écriture du système de fichier. C'est donc logiquement plus lent (une couche logicielle supplémentaire).

Je répond à sa place, car je m'e suis déjà posé la question.

Peut-être pour les problèmes de performances, et de fragmentation ?
Car dans ce cas, il y a un double niveau de fragmentation à gérer :
- la fragmentation du fichier du disque virtuel, dont est responsable l'OS guest
- la fragmentation à l"intérieur de l'OS virtualisé, responsabilité de l'OS virtualisé

Avec un OS virtualisé installé dans une "vrai" partition, on élimine un niveau de fragmentation.

Déjà, toute solution de virtualisation qui repose sur des fichiers pour les disques virtuels me fait gentillement rigoler.

Faux : Il est possible, pas très simple certes, mais possible, d'avoir l'OS virtualisé sur une vrai partition du disque dur. Le "secret", c'est le paramètre "-rawdisk" lorsque l'on crée le nouvel OS virtualisé (oui, il faut utiliser la ligne de commande).

L'explication ici pour un guest Windows :
http://www.sysprobs.com/access-physical-disk-virtualbox-desk(...)

Sinon, il y a https://encrypted.google.com/search?q=VBoxManage+internalcom(...)

La commande à taper est du type :
VBoxManage internalcommands createrawvmdk -filename ... -rawdisk ...

Sous Linux, on a le choix:
- soit on crée une nouvelle virtualisation en lui donnant accès au /dev/sda . Il y a un risque, car l'OS virtualisé a accès à tout le disque, et donc potentiellement au, par exemple, /dev/sda2 où serait le guest . Par contre, il y a un avantage : On peut démarrer l'OS virtualisé soit via VirtualBox, soit en bootant la "vrai" machine avec son GRUB dessus (sur le /dev/sda1 par exemple).

- soit on donne à la virtualisation accès à une partition bien définie, par exemple /dev/sda1. L'OS vitualisé verra alors cette partition en temps que disque dur, et créera son MBR à l'intérieur. Le concept est assez intéressant, surtout que l'OS virtualisé peut avoir accès aux données de l'OS virtualisé, via un montage en loopback (évidement, il ne faut pas que l'OS virtualisé soit lancé en même temps !).

Personnellement, j'ai testé la 2nd solution chez un ami. Cela marche très bien. Lorsque la virtualisatio est arrêté, il a un accès complet à la partition "C:" qui est créé dans /dev/sda2 . Lorsque la virtualisation est lancée, il accès à ces données via le partage de fichiers de l'OS virtualisé.

Si le wifi de ton client filtre un peu trop les connexions sortantes de son réseau, et que tu n'utilises pas le port 443 de ta connexion internet, tu peux planquer un serveur SSH derrière le port 443.

Depuis ton laptop, tu te connectes en SSH sur le serveur, et tu demandes un tunnel du port 3306 du serveur sur le port 3306 du localhost de ton portable.

En clair, cela donne cela :

ssh -oPort=443 -L 3306:localhost:3306 user@adresse_ip_serveur

Tu n'as plus qu'à connecter ton appli sur ton port localhost:3306, qui va te renvoyer directement sur le serveur MySQL de ton serveur.

Afin, de sécuriser la chose, tu peux :
- faire que le login de ton "user@adresse_ip_serveur" tombe sur un faux-shell (/usr/local/bin/fake_shell). Quelque chose du type (code en C) :


#include <stdio.h>
#include <unistd.h>

int main (int argc, char* argv[]) {
printf("Le tunnel SSH actif\n\
Vous pouvez lancer les connexions aux tunnels.\n\
Vous pouvez arrêter cette connexion en tapant plusieurs fois Ctrl+C\n");
sleep(-1);
return 0;
}


Que tu compiles comme cela :
gcc -Wall -o /usr/local/bin/fake_shell fake_shell.c

- et enfin, mettre en place une paire de clé publique/privée, protégées par un mot de passe, qui fera que seul cette clé peut se connecter au serveur SSH.

J'ai écrit un article pour Linux+DVD, et fait une conférence sur le sujet. Tu trouveras les transparents de la conférence ici : http://olivieraj.free.fr/fr/linux/information/prise_en_main_(...)