CDE encapsule tous les fichiers nécessaires à l'exécution du binaire : Code, Données, Environnement. Ainsi, lors de l'exécution de la commande $ cde a.out sur la machine A, CDE va exécuter a.out, surveiller ses accès (bibliothèques dynamiques, fichiers de configuration, polices, etc.), copier ces fichiers dans un sous-répertoire et créer un fichier a.out.cde. L'ensemble des fichiers de ce sous-répertoire peut être transféré sur une machine B. Lors de l'exécution de a.out.cde, l'environnement est changé (comme avec chroot) et ce sont les bibliothèques fournies dans le sous-répertoire qui sont utilisées. Le binaire ainsi encapsulé est exécutable sur une autre machine à deux conditions : premièrement, que les deux machines soient de la même architecture (par exemple x86) ; deuxièmement, qu'elles utilisent la même version majeure du noyau (par exemple 2.6).
Parmi les utilisations possibles (de nombreux autres exemples sont donnés sur la page du projet) :
- Laisser en téléchargement des binaires qui s'exécuteront chez tous les utilisateurs sans qu'ils aient à installer des dépendances, à compiler, ou à installer une machine virtuelle ;
- Permettre l'exécution de programmes binaires anciens sur des machines récentes, ou le contraire ;
- Soumettre un rapport de bug exécutable permettant sa reproduction chez les développeurs.
Aller plus loin
- Page du projet (150 clics)
- Dépôt github (252 clics)
- Vidéo de démonstration (48 clics)
# Avantage par rapport à un simple ldd ?
Posté par Xaapyks . Évalué à -10.
pour les fichiers en relation... dans les commentaires de la vidéo, il semble qu'il inclue /etc/passwd...
J'trouve vraiment pas ça utile... et evidemment ca ne marche pas si on produit sur du x86_64 et le fait tourner sur du x86 32 bits.
Donc pour moi ça a aucun intéret.
Faut être en doctorat pour faire ce genre de truc inutile ?
[^] # Re: Avantage par rapport à un simple ldd ?
Posté par Kangs . Évalué à 7.
Je ne pense pas qu'avec ldd tu puisses connaitre les lib chargées par le programme dynamiquement (dlopen) comme pour les plugins.
Pour strace il faut être certain d'avoir chargé tous les composants...
[^] # Re: Avantage par rapport à un simple ldd ?
Posté par Xaapyks . Évalué à 1.
Et en effet en utilisant strace ca signifie qu'il faut avoir parcouru tout le code ? C'est inutilisable en pratique.
[^] # Re: Avantage par rapport à un simple ldd ?
Posté par claudex . Évalué à 2.
Pas pour vu que justement tu ne sais pas forcément quelles sont les bibliothèques qui sont chargées chez l'utilisateur.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Avantage par rapport à un simple ldd ?
Posté par Kangs . Évalué à 1.
Oui, parmi les trois cas d'utilisations possibles cités, c'est celui qui me semble le plus crédible.
J'ai du mal à trouver d'autre cas.
[^] # Re: Avantage par rapport à un simple ldd ?
Posté par JGO . Évalué à 7.
Deuxième cas (me concerne tout particulièrement). Il exista un jour un logiciel de CAO très bien nommé qcad. https://linuxfr.org/2009/01/15/24874.html Il n'est plus libre, la version dont j'avais besoin n'est plus supportée, et après les années elle ne s'exécute plus sur ma machine (notamment, les libpng et libjpeg ont changé de version majeure). Avec cde, je vais pouvoir ressortir mon vieux disque sur avec une version qui marchait, exécuter cde pour récupérer les vieilles dépendances de bibliothèques, et exécuter ce programme sur ma machine moderne.
[^] # Re: Avantage par rapport à un simple ldd ?
Posté par M . Évalué à 8.
Mais tu n'obtiens pas tout les fichiers
pour les fichiers en relation... dans les commentaires de la vidéo, il semble qu'il inclue /etc/passwd...
C'est sur que s'il récupère tout les fichiers qui sont ouvert, c'est mal barré. Une requête dns et on embarque resolv.conf ?
On embarque aussi ta conf du jeu ?
De plus le système de strace est foireux : pour être sur que tout les fichiers sont detectés il faut exécuter tout les chemin de l'appli.
Par exemple un jeu a plusieurs niveau, et ben il va falloir jouer tout les niveau si l'appli charge les sons/image de manière lazy.
Et puis CDE c'est déja pris comme nom...
[^] # Re: Avantage par rapport à un simple ldd ?
Posté par FantastIX . Évalué à 2.
# C'est du lourd !
Posté par Watchwolf . Évalué à 6.
Du coup c'est pas trop trop utilisable.
J'ai pas testé si ça fonctionne par contre comme j ai les libs sur mon système. Mais ça a l'air, en tous cas ça se lance.
[^] # Re: C'est du lourd !
Posté par claudex . Évalué à 3.
Comme les applications pour Windows.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: C'est du lourd !
Posté par barmic . Évalué à 2.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: C'est du lourd !
Posté par JGO . Évalué à 3.
Mais sinon ce n'est pas inhabituel que des logiciels un peu complexes embarquent un exemplaire de bibliothèques système. Par exemple le paquet binaire scilab 5.3.0 beta4 fait 140 Mo dont la moitié est une machine virtuelle java.
# Windows enfin à portée de Linux
Posté par Kerro . Évalué à 7.
[^] # Re: Windows enfin à portée de Linux
Posté par lolop (site web personnel) . Évalué à 3.
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
# Laisser en téléchargement des binaires qui s'exécuteront chez tous le
Posté par zecrazytux (site web personnel) . Évalué à 6.
Il prend pas un peu le problème à l'envers, là ?
[^] # Re: Laisser en téléchargement des binaires qui s'exécuteront chez tou
Posté par JGO . Évalué à 5.
Avec cde, tu peux faire la même chose sur un binaire quelconque. Par exemple, mettons que tu as fait un script bash qui démontre un bug du shell de ta distribution. Tu exécutes le script avec cde, il va capturer le binaire de bash, les dépendances éventuelles, le fichier .bashrc, etc. Tu envoies tout ça aux mainteneurs de ta distribution qui peuvent reproduire le bug sur leur machine.
[^] # Re: Laisser en téléchargement des binaires qui s'exécuteront chez tou
Posté par zecrazytux (site web personnel) . Évalué à 3.
Laisser en téléchargement des binaires qui s'exécuteront chez tous les utilisateurs sans qu'ils aient à installer des dépendances, à compiler, ou à installer une machine virtuelle ;
ton argumentation, que j'ai très bien comprise, revient plutot sur le point:
Soumettre un rapport de bug exécutable permettant sa reproduction chez les développeurs.
[^] # Re: Laisser en téléchargement des binaires qui s'exécuteront chez tou
Posté par JGO . Évalué à 2.
Sur la différence avec la compilation statique, voilà ce que l'auteur en dit : « CDE is strictly more powerful than static linking and binary packaging tools, since it can collect run-time dependencies (e.g., configuration files) that programs often require. »
Et puis tu compiles rarement tout en statique. Par exemple, on peut trouver en téléchargement des binaires de Skype pour plusieurs version de la libc. Ici, cde empaquette aussi la libc.
[^] # Re: Laisser en téléchargement des binaires qui s'exécuteront chez tou
Posté par wismerhill . Évalué à 1.
Pour pouvoir profiter des mêmes failles de sécurité que celui qui a créé le paquet :-)
(donc de ce point de vue ça fait "aussi mal" qu'une compilation statique)
[^] # Re: Laisser en téléchargement des binaires qui s'exécuteront chez tou
Posté par JGO . Évalué à 2.
Dans tous les cas, le binaire tourne en chroot avec des privilèges bas. Cela procure déjà une certaine sécurité.
[^] # Re: Laisser en téléchargement des binaires qui s'exécuteront chez tou
Posté par Antoine . Évalué à 2.
C'est un principe assez connu dans le monde Python, avec des outils comme py2exe ou cx_Freeze.
# Existe ?
Posté par Sébastien B. . Évalué à 2.
Par exemple, j'ai un logiciel, quand il se lance il charge la SDL présente sur le système mais il charge OpenAL qui est distribué avec le logiciel parce que je n'ai pas OpenAL d'installé.
On combine ainsi l'avantage des librairies partagées (occupation de RAM, mise à jour, ...) avec celui de la compilation statique (facile à distribuer).
Donc ça existe ce genre de trucs ?
[^] # Re: Existe ?
Posté par Xaapyks . Évalué à -1.
[^] # Re: Existe ?
Posté par JoeltheLion (site web personnel) . Évalué à 2.
[^] # Re: Existe ?
Posté par Olivier (site web personnel) . Évalué à 1.
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
[^] # Re: Existe ?
Posté par JoeltheLion (site web personnel) . Évalué à 4.
Il me semble que c'est exactement l'inverse que sebastienb voulait faire...
[^] # Re: Existe ?
Posté par totof2000 . Évalué à 3.
[^] # Re: Existe ?
Posté par JoeltheLion (site web personnel) . Évalué à 4.
[^] # Re: Existe ?
Posté par totof2000 . Évalué à 2.
Etya pas moyen de récupérer cette info automatiquement ? Je serais surpris que ça ne soit pas possible.
[^] # Re: Existe ?
Posté par VoixOff . Évalué à 2.
(Il faut être root.)
[^] # Re: Existe ?
Posté par meumeu1402 . Évalué à 2.
# J'ai oublié...
Posté par Xowap (site web personnel) . Évalué à 3.
[^] # Re: J'ai oublié...
Posté par JGO . Évalué à 3.
Pour encapsuler un environnement, tu peux toujours lancer une machine virtuelle mais c'est pas forcément très pratique (c'est comme maintenir deux machines)
Pour les autres fonctionnalités (packager un binaire quelconque pour qu'il s'exécute de partout), je ne vois pas.
# contradictions ?
Posté par NeoX . Évalué à 2.
Le binaire ainsi encapsulé est exécutable sur une autre machine [...] la même version majeure du noyau (par exemple 2.6).
[...]
Permettre l'exécution de programmes binaires anciens sur des machines récentes, ou le contraire ;[...]
ce n'est parfois pas le cas si les machines ont trop d'années d'ecart.
ex : noyau 2.4 au lieu de 2.6
mais sur des machines pas trop "decalées" ca pourrait le faire
[^] # Re: contradictions ?
Posté par JGO . Évalué à 5.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.