OVH Cloud OVH Cloud

[gentoo-user-fr] Utiliser portage/emerge avec des paquets binaires...

14 réponses
Avatar
Ivan Havlicek
Bonjour,

Si vous en avez assez d'attendre les résultats de compilation,
vous pouvez peut-être essayer d'utiliser nos paquets binaires.
Une seule personne compile, met à jour le serveur de référence et
évite ainsi à tous les autres cette tâche fastidieuse.

Cela fait un mois que nous utilisons ce système qui permet
de récupérer des paquets déjà compilés, en particulier pour
mettre à jour nos serveurs d'hébergement.
La seule condition est que le type de votre processeur soit
déjà référencé sur notre serveur (et qu'un volontaire se soit déjà
tapé tout le boulot ;-)

=> http://rsync4.fr.gentoo.org/grp/

Vous pouvez alors ajouter les options suivantes à votre emerge :
# emerge --getbinpkgonly --usepkgonly
pour ne télécharger que les paquets déjà compilés.

Vous devez d'abord simplement ajouter à votre fichier make.conf :

# (PROC_TYPE actuellement disponibles : "c7 pentium3 pentium4 pentium4m
athlon64" )
PROC_TYPE="pentium3"
PORTAGE_BINHOST="http://gentoo.modulix.net/gentoo/grp/${CHOST}/${PROC_TYPE}"

Pour voir les options utilisées par la machine qui a compilé ces paquets,
vous pouvez voir les make.conf sur http://rsync4.fr.gentoo.org/localfiles/
(il y a aussi la configuration des noyaux)

Si vous possédez un autre type de processeur et que vous souhaitez
contribuer,
écrivez un mail à webmaster@modulix.net

Commentaires, suggestions et autres remarques sur ce service de préférence
sur cette liste.

Qu'en pensez-vous ?
--
Ivan Havlicek

--
gentoo-user-fr@gentoo.org mailing list

4 réponses

1 2
Avatar
Aurélien Francillon
On Friday 28 July 2006 18:44, Jean-François Maeyhieux wrote:
On Fri, 2006-07-28 at 18:34 +0200, Aurélien Francillon wrote:
> Tu peux ajouter un deuxiemme gros probleme: la securité de tout ca ...
>
> Coment peut tu etre sur que le package binnaire que tu télécharge ne
> contiendra pas de virus, chevaux de troie, rootkit ou autres friandises ?
>
> Faire confiance aux dev gentoo et aux serveurs rsync on a pas trop le
> choix et semble plutot raisonable. Ca sera mieux quand le systeme de
> verification de signatures sera mis en place
>
> Faire confiance a quelques personnes bien identifiées qui administrent un
> serveur de packages binnaires semble etre acceptable pour certains ...
> au pire si on trouve un jour une saleté ajoutée dans un pkg on sait "sur
> qui tapper"
>
> Faire confiance a nimporte qui sur un reseau P2P de distribution de
> packages binaires ... avec potentiellemnt des milliers de contributeurs
> ca me semble de la folie ! Ca devient vraiment trop facile de prendre le
> controle d'une pachine a distance ;) A moins d'avoir un systeme de
> gestion de "reputation" et des signatures GPG ... mais c'est pas simple a
> mettre en oeuvre...
>
> Aurélien

Le problème de la sécurité est évident, je te l'accorde mais il serait
possible de vérifier l'authenticité d'un paquet binaire en le mettant à
disposition sur le P2P



Ce qui revient a le recompiler avec exactement les memes
options/compilateur/libraires juste pour verifier que c'est le meme ...
soit en mettant en place un système d'authentification des fournisseurs
de pkgs soit tout simplement par élimination des paquets binaires
n'ayant pas un nombre de fournisseurs différents jugés comme suffisant.



"différents" comment on sait ca ... comme un meme fournisseur peut se faire
passer pour plusieurs personnes il faut bien un systeme de reputation ...

C'est à creuser mais cela me semble pas insurmontable. Et pourquoi pas
valider les hashcodes des paquets par les devs gentoo ou créer une
entité gentoo pour cela...



a mon avis il y a peu de chances d'avoir le support officiel de gentoo... le
sujet a deja ete beaucoup discute je crois ...
et aussi une idée similaire la :
http://marc.theaimsgroup.com/?l=gentoo-dev&m3071488514488&w=2
http://forums.gentoo.org/viewtopic.php?t&5559

bon courage ;)
Aurelien



--
mailing list
Avatar
Ivan Havlicek
Aurélien Francillon a écrit :

a mon avis il y a peu de chances d'avoir le support officiel de gentoo... le
sujet a deja ete beaucoup discute je crois ...




Pour moi, il ne s'agit pas de créer un nouveau truc dans la Gentoo.

Au départ, c'est une facilité que j'utilise pour mettre à jour plusieurs
serveurs identiques sans avoir à recompiler sur chaque machine.
Ensuite, j'ai pensé que ce système pouvait servir à d'autres personnes,
j'upload donc ces paquets sur un serveur qui est public (j'ai aussi
rajouté quelques postes de travail).
Maintenant, on envisage de distribuer la Gentoo à des entreprises
avec un contrat de "maintenance logicielle" (maj des version).
Ils se synchroniseraient uniquement avec des paquets binaires que
nous aurions préalablement validés.
Je pensais donc plutôt à un repository de binaires dont chaque
"répertoire" avait son mainteneur public (pb sécurité effectivement).
En terme de souplesse l'idéal serait d'avoir des paquets binaires qui
reflèteraient les USE flags actifs, mais cela équivaudrait presque à ce que
chaque utilisateur ait ses binaires, donc pas de capitalisation par le
partage sans compter qu'il fait bien que quelqu'un les ait compilé
une fois.
A l'inverse, ne proposer que deux "types" de binaires (avec ou sans X11)
me parraît effectivement trop réducteur.
La solution se trouve sans doute entre ces deux extrêmes, un peu comme
les "grands" choix d'implémentation. Je voyais plutôt un truc du genre :
/grp/$CHOST/$PROC_TYPE/Xorg/Gnome
/grp/$CHOST/$PROC_TYPE/Xorg/KDE
/grp/$CHOST/$PROC_TYPE/Xorg/XFCE
(et d'autres s'il y a des volontaires)

/grp/$CHOST/$PROC_TYPE/noXorg/Qmail
/grp/$CHOST/$PROC_TYPE/noXorg/Sendmail

Des échanges entre les mainteneurs permettraient peut-être à terme de
mettre en place un "socle commun" à tous les modèles en comparant les
USE de chaque sélection.
Chaque utilisateur pourrait ainsi choisir le modèle le plus proche de sa
machine et devrait limiter les écarts de USE flags.

--
mailing list
Avatar
Nico
------=_Part_14938_23463206.1154127096742
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: base64
Content-Disposition: inline

SnVzdGUgaGlzdG9pcmUgZGUgY2Fzc2VyIGxlIG1vcmFsIGRlcyB0cm91cGVzLCBsaXNleiBkb25j
CmNlY2k8aHR0cDovL2xpbnV4ZnIub3JnLzIwMDYvMDcvMjgvMjExNDAuaHRtbD46IGxhIHNvbHV0
aW9uIFAyUCBlc3QKZXhjZWxsZW50ZSwgbWFpcyBjb21tZW50IGZhaXJlIHNpIGxlcyBsb2dpY2ll
bHMKc2VydmFudCDDoCDDp2Egc29udCBpbGzDqWdhdXggPwo ------=_Part_14938_23463206.1154127096742
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: base64
Content-Disposition: inline

SnVzdGUgaGlzdG9pcmUgZGUgY2Fzc2VyIGxlIG1vcmFsIGRlcyB0cm91cGVzLCA8YSBocmVmPSJo
dHRwOi8vbGludXhmci5vcmcvMjAwNi8wNy8yOC8yMTE0MC5odG1sIj5saXNleiBkb25jIGNlY2k8
L2E+IDogbGEgc29sdXRpb24gUDJQIGVzdCBleGNlbGxlbnRlLCBtYWlzIGNvbW1lbnQgZmFpcmUg
c2kgbGVzIGxvZ2ljaWVscyBzZXJ2YW50IMOgIMOnYSBzb250IGlsbMOpZ2F1eCA/PGJyPgo ------=_Part_14938_23463206.1154127096742--
--
mailing list
Avatar
Stephane Bortzmeyer
On Fri, Jul 28, 2006 at 06:44:20PM +0200,
Jean-François Maeyhieux wrote
a message of 79 lines which said:

Le problème de la sécurité est évident, je te l'accorde mais
il serait possible de vérifier l'authenticité d'un paquet binaire en
le mettant à disposition sur le P2P soit en mettant en place un
système d'authentification des fournisseurs de pkgs



Là encore, on peut utiliser l'expérience de Debian : les architectures
"minoritaires" (comme la Sparc) n'ont pas assez de machines de
compilation automatique ("build daemon") des paquetages
officiels. Régulièrement, un gars sympa dit qu'il a une vieille Sparc
achetée sur eBay et qu'il veut bien la faire mouliner la nuit pour
Debian. Et, non moins régulièrement, son offre est rejetée car, même
si lui est connu et de confiance, comment savoir si sa machine va être
bien administrée et bien sécurisée ?

Un paquetage binaire étant forcément installé par root, je crois que
le problème de sécurité est LE problème de cette proposition et que
c'est celui à creuser en premier.
--
mailing list
1 2