Comment pallier absence libmysqlclient.so sur poste client ?

Bonjour,

Comment peut-on pallier automatiquement l'absence d'une lib.so (libmysqlclient.so.xxx par exemple) nécessaire au fonctionnement d'un exécutable compilé en Lazarus sur un poste client soit qui [le poste] ne dispose pas de la bonne version de libmysql, soit (cas plus rare) sur lequel la lib n'est pas (plus) installée ?

Cordialement. Gilles

PS : le problème n'est pas d'installer une libmysqlclient.so et son lien symbolique dans /usr/lib comme le fait un développeur mais de pouvoir réparer automatiquement un problème de modification de dépendance (de cible du lien ou même de suppression) par un autre logiciel par exemple. Je n'ai actuellement qu'une solution : mettre mon application en SUID... Je n'ai pas trouvé de méthode satisfaisante...

Une solution qui peut marcher est de fournir ton logiciel avec la bibliothèque en question et de le lancer par un script qui modifier la variable d'environnement LD_LIBRARY_PATH puis lancer le véritable programme lazarus.

Pour plus d'info : http://pwet.fr/man/linux/administration_systeme/ld_so

Mais la vraie bonne méthode c'est de faire un vrai paquet d'installation avec une dépendance sur la libmysqlclient.

Bonjour,

Ce que je ne maitrise pas... c'est la dépendance sous Linux par les paquets...

Un paquet installe un programme A et une dépendance (mysqlclient) avec un lien symbolique libmysqlclient.so qui est en réalité un client mysql version 4.
Vous voulez maintenant installer votre propre paquet qui fera référence également à libmysqlclient.so mais nécessite un client mysql5.
Alors 2 questions :

1. Quid du conflit ? J'ai essayé à partir de Synaptic d'installer libmysql5 et libmysql5.1... Automatiquement pour installer le second, il impose la désinstallation du premier... Alors je suppose que c'est identique pour un mysql4 et un mysql5... J'imagine d'ici la réponse : un client mysql5 pilotera une base en mysql4 : pas pour moi :oops: --> j'utilise dans mes tables le password encryption et ce dernier est différent entre une version mysql4 et une 5... et évidemment j'ai plusieurs prog. Lazarus qui attaquent des bases récentes et des vieillies.
2. En supposant que je désinstalle le programme A par le gestionnaire de paquets, sa dépendance client mysql va-t-elle rester à coup sûr ou va-t-il effacer les fichiers relatifs cette dépendance (mysql) ?

Actuellement j'utilise Zeos que j'ai un peu bricolé pour "résoudre" le problème : le client par défaut recherché n'est pas libmysqlclient.so ou libmysqlclient.so.15 mais un nom de mon choix. Dans le dossier de mon programme est fourni un dossier qui contient le bon fichier libmysql... Au démarrage, le programme vérifie si le lien symbolique (nom modifié) existe et si tel n'est pas le cas, il créé le lien dans /usr/lib... Voila pourquoi le programme a le bit SUID activé...

Cordialement. Gilles

Le bit SUID revient à exécuter ton programme en tant que root. A moins que tu sois absolument sûr de ton code c'est très dangereux.

Si tu as vraiment besoin d'un version spécifique de la libmysql tu peux essayer la solution que je t'ai donné avec LD_LIBRARY_PATH ça doit pouvoir marcher.

J'ai même pris le temps de te faire le petit script :

Code:

---

1 2 3 4 5 6 7 8 9

#!/bin/bash # à remplacer par le nom du prog PROGNAME=hello   DIR=`dirname $0` export LD_LIBRARY_PATH=$DIR   $DIR/$PROGNAME

---

Tu places le script modifié, ton programme lazarus et ta bibliothèque dans un même dossier et je pense que ça doit marcher.

Merci beaucoup. je teste.

Pour le SUID, notamment en Lazarus... vous m'inquiétez :

Vous essayez de basculer en mode root.
Si OK vous lancez votre fonction qui exige les droits du root.
Si Erreur--> Arrêt du programme
Si pas erreur --> Vous rebasculez immédiatement dans l'ancien mode.
Si Erreur --> Arrêt du programme
Si pas Erreur... Vous contrôlez que vous êtes bien revenu dans l'ancien mode...
Si pas le cas --> Arrêt du programme.

En conclusion, vous êtes en mode root pendant qqs lignes avec les sécurités que je pensais nécessaires. C'est pas le cas* ?

* C'est le seul moyen que j'ai trouvé en Lazarus/Linux pour faire beeper le haut-parleur d'un PC. On ne va pas mettre en péril la sécurité pour beeper ! Mais bon, j'utilisais également le SUID pour mes "dépendances"...

Cordialement. Gilles

Le bit SUID permet de lancer un exécutable avec les droits du propriétaire de celui-ci.

Si ton exécutable appartient à root ton programme a les droits de root durant toute sa durée d'exécution. Si par exemple ton programme permet d'ouvrir un fichier texte alors l'utilisateur de ce programme peut ouvrir tous les fichiers y compris ceux d'un autre utilisateur ou même des fichiers de config du système. Si ton prog permet d'effacer un fichier alors tous les fichiers peuvent être effacé. Etc...

Si tu veux continuer à faire des beep je te conseille plutôt de créer un mini programme qui ne fait que ça et qui aura le bit SUID. Quand ton gros programme veut émettre un beep il n'a qu'a lancer le mini programme dédié. De cette façon tu limites considérablement les risques.

Cependant, la méthode reste peu recommandable en cas de bug dans ton mini programme tu peux ouvrir une brèche dans la sécurité du système.

OK.

Merci par le code. Il fonctionne. J'ai regardé rapidement s'il y avait moyen de modifier la LD_LIBRARY_PATH à partir du programme à partir des units unix...
Pour l'instant, je n'ai pas trouvé...

Encore merci. Cordialement. Gilles

LD_LIBRARY_PATH est une variable d'environnement. En C on peut en changer la valeur par setenv. Je n'ai pas trouver l'équivalent dans la doc freepascal.

De toutes façons changer cette variable dans ton programme ne marcherait pas. Le chargement des bibliothèques dynamiques a lieu avant le début de ton programme.

Bonjour,

Merci pour toutes ces infos. J'expérimente autre chose qui semble-t-il fonctionne pour l'instant... mais dont je ne mesure pas encore exactement la pertinence.

Code:

---

1 2 3 4 5 6 7 8 9

procedure TForm1.FormCreate(Sender: TObject); begin HandleMysql:=THandle(dlopen(pchar(IncludeTrailingPathDelimiter(ExtractFilePath(Application.ExeName))+'libmysqlclient.so.15'),RTLD_NOW)); end;   procedure TForm1.FormDestroy(Sender: TObject); begin dlclose(HandleMysql); end;

---

J'ai passé l'exécutable sur un poste kUbuntu qui ne connaît pas mysql avec simplement le fichier libmysqlclient.so.15. La connexion se réalise bien. Maintenant, est-ce que la suite SQL fonctionne correctement ?... Y-a-t-il une conséquence sur les temps d'accès [normalement non avec RTLD_NOW] ?... Je regarde...

Cordialement. Gilles.

La méthode à base de dlopen est à mon avis inutilement compliquée pour ce que tu veux faire. Mais bon ça marche aussi.