[REPO] amélioration la gestion de la soumission des paquets

Présentation de la communauté, le site/forum/wiki etc...
Répondre
Avatar de l’utilisateur
bapt
Daikyu
Messages : 85
Inscription : jeu. 20 sept. 2007, 09:20
Contact :

[REPO] amélioration la gestion de la soumission des paquets

Message par bapt » lun. 07 janv. 2008, 11:43

Voici une petite proposition pour la gestion de la soumission des paquets dans les repos archlinux.

Actuellement tout se fait par ssh.

Je vois plusieurs problèmes :
1/ un accès par utilisateur par ssh (même si les comptes sont restreint.
2/ Une gestion chiante des boulets (comme moi) qui flingue leur compte avec ssh-installkeys (d'ailleur wain si tu me regarde, j'ai encore flingué mon compte :))

Voila l'architecture que je propose pour simplifier la gestion et la contribution. :

Mise en place d'un serveur ftp (anonyme ou non, ssl ou non, c'est au choix des admins). Les serveurs ftp modernes (pure-ftpd par exemple, vue que je l'affectionne particulièrement :)) sont capable d'executer une command après un upload.

Si le ftp est anonyme, il n'y a plus besoin de gestion des user, a la place, je propose que chaque tu fournisse à l'équipe archlinuxfr une clef gpg, ainsi lors de la contribution de leur pkg, pour s'assurer de l'identité de celui qui a envoyer le pkg, une signature gpg est fournit avec.

Ainsi un utilisateur qui veut mettre a disposition un nouveau pkg pour les répertoire archlinuxfr depose un archive tar (gz ?) du genre :
monpkg.tar:
./monpkgarch.pkg.tar.gz
./signature.gpg
./fichierinfo

une fois l'upload terminé, le serveur ftp execute un script qui prend en charge le nouveau fichier, extrait le nom de l'utilisateur de fichierinfo, vérifie si la signature est bien celle de l'utilisateur en question et par la même occasion que monpkgarch.pkg.tag.gz n'est pas corrompu, valide une certains nombre de critères concernant les packages (peu éventuellement envoyer un mail en cas de problèmes)

Ensuite deux possibilité en fonction de la charge des serveurs :
1/ soit le script passe le pkg a ajouter a un programme démon gérant une pile de pkg a traiter.
2/ soit il fini le traitement du pkg lui même.

Avantage :
1/ archtecture relativement simple a mettre en place.
2/ possibilité d'extension facile : interface web a la "aur" pour s'inscrire/se désinscrire, gérer sa clef gpg, et une activation du finale du compte par l'équipe archlinux (donc plus de visibilité sur ce projet, et donc peut être plus de gens pour soumettre des pkgs)

Qu'en pensez vous ?

Un lien vers la fonctionnalité d'execution de script de pureftpd :
http://download.pureftpd.org/pub/pure-ftpd/doc/README chercher uploadscript.

Avatar de l’utilisateur
wain
Maître du Kyudo
Messages : 1854
Inscription : ven. 11 août 2006, 19:15
Localisation : Nancy (54)
Contact :

Re: [REPO] amélioration la gestion de la soumission des paqu

Message par wain » lun. 07 janv. 2008, 13:39

Salut, je vais étudier attentivement ta proposition, mais vite fait une remarque sur ce qui motive ton post:
bapt a écrit :Actuellement tout se fait par ssh.
Je vois plusieurs problèmes :
1/ un accès par utilisateur par ssh (même si les comptes sont restreint.
2/ Une gestion chiante des boulets (comme moi) qui flingue leur compte avec ssh-installkeys (d'ailleur wain si tu me regarde, j'ai encore flingué mon compte :))
Je ne comprend pas le point 1. Je peux uploader mes paquets depuis plusieurs PC avec des comptes utilisateurs différents. Il n'y a pas de limitation. Le point 2 est vrai: boulets ou pas, l'accès n'est pas toujours simple à configurer pour ceux qui n'ont pas l'habitude d'utiliser ssh. Plusieurs solutions peuvent être apportées pour améliorer ça: une doc claire, moins de restrictions sur le système anti bruteforce (c'est déjà fait).
En revanche nous avons choisi ce système car il offre une bonne sécurité et une gestion simple puisqu'il n'y a pas de serveur supplémentaire (ftp) à maintenir. Les utilisateurs sont créés en une seule commande dans un environnement chrooté restreint. Seules quelques commandes sont accessibles.
La clef ssh n'est pas obligatoire non plus. On pourrait très bien taper son mdp quand on upload son paquet.

On va étudier ce que tu proposes parceque Lenglemetz a prévu de faire évoluer prochainement le système actuel vers un nouveau serveur qui se chargerait de la compilation des paquets. En pratique l'utilisateur n'enverrait plus que son PKGBUILD et le serveur ferait le reste.
a+

Avatar de l’utilisateur
bapt
Daikyu
Messages : 85
Inscription : jeu. 20 sept. 2007, 09:20
Contact :

Message par bapt » lun. 07 janv. 2008, 13:40

Le point 1 signifiait que chacun des utilisateurs (TU) avais un compte (même restreint) sur le serveur repo.archlinux.fr

Avatar de l’utilisateur
bapt
Daikyu
Messages : 85
Inscription : jeu. 20 sept. 2007, 09:20
Contact :

Message par bapt » lun. 07 janv. 2008, 13:46

Autre avantage, les packages (PKGBUILD) sont automatiquement pris en compte, (et pas toutes les 10mins comme c'est la cas actuellement). De plus j'imagine que aujourd'hui c'est une cron qui déclenche la prise en compte d'un pkg, donc elle est déclenchée même si il n'y a rien de déposer (ca va que ca doit pas être trop couteux, mais c'est toujours mieux d'avoir quelque chose qui se lance a la demande quand c'est nécessaire.

Dernière chose, concernant la plateforme qui recompile automatiquement les PKGBUILD, attention la charge, car si j'envoie mon PKGBUILD icedtea ou si quelqu'un fait un PKGBUILD openoffice par exemple, ca va être lourd et long a avaler. De plus fakeroot n'est pas 100% fiable, certains PKGBUILD (java par exemple ne sont pas compatible avec fakeroot, dans mon cas icedtea plante à la compilation à cause de fakeroot).

Avatar de l’utilisateur
lenglemetz
Chu Ko Nu
Messages : 307
Inscription : dim. 27 mai 2007, 22:26
Localisation : Kamikaze Land
Contact :

Message par lenglemetz » lun. 07 janv. 2008, 15:52

bapt a écrit : Dernière chose, concernant la plateforme qui recompile automatiquement les PKGBUILD, attention la charge, car si j'envoie mon PKGBUILD icedtea ou si quelqu'un fait un PKGBUILD openoffice par exemple, ca va être lourd et long a avaler. De plus fakeroot n'est pas 100% fiable, certains PKGBUILD (java par exemple ne sont pas compatible avec fakeroot, dans mon cas icedtea plante à la compilation à cause de fakeroot).
Il y aura une file d'attente mise en place, mais bon on verra tout ça le moment venu :)
☠ ☠ ☠ ⅛|™ ☠ ☠ ☠ ¬|¬ Born To Be Web ¬|¬ DonF ¬|¬ ☠ ☠ ☠ ®|© > [Thème] Sujet (état) <

Avatar de l’utilisateur
warnaud
Maître du Kyudo
Messages : 1640
Inscription : ven. 11 août 2006, 17:05
Localisation : Rolle (CH)
Contact :

Message par warnaud » lun. 07 janv. 2008, 18:20

En fait on a essayé de faire simple et sûr ...
On a déjà tenté de nous démonter le serveur ssh... alors multiplier les serveurs (et donc les risques, les updates ...) c'est pas forcément souhaitable si on a pas des gens "24/24" dessus. Aujourd'hui y'a que wain et skunnyk (peut être lenglemetz :D) qui s'en occupent c'est trop peu. Derrière y'a aussi très peu de contributeurs. Le cron est là pour éviter d'envoyer 50 micros pkg et à chaque fois de recréer la base, c'est discutable certe. Quand a la ferme de compilation, pourquoi pas mais comme tu le soulignes faut vraiment faire gaffe aux catastrophes possibles.
Plus ça rate, plus ça a de chance de réussir. En somme, un succès n'est qu'une erreur qui a finit par réussir (même par erreur). Ne déséspérez donc pas et perseverez. Utilisez La Rache™
Patientia quod lard quod barrus planto diligo ut licentia
—¤÷(`[¤*Powered By *¤]´)÷¤—
Archlinux ~ Fvwm ~ Irssi ~ URxvt

Avatar de l’utilisateur
wain
Maître du Kyudo
Messages : 1854
Inscription : ven. 11 août 2006, 19:15
Localisation : Nancy (54)
Contact :

Message par wain » lun. 07 janv. 2008, 19:02

bapt a écrit :Le point 1 signifiait que chacun des utilisateurs (TU) avais un compte (même restreint) sur le serveur repo.archlinux.fr
Obligatoire ça. Si on doit fermer le compte d'un TU on ne va pas faire subir à tout le monde un changement de passe.

Pour l'exécution d'une commande après l'upload, il faudrait que l'utilisateur ait un compte avec assez de privilèges. C'est dangereux. Le système actuel avec sa tâche cron permet d'avoir dans un premier temps un paquetage déposé par le TU dans un endroit restreint (jail ssh) et ensuite un robot qui va chercher le paquet dans cet endroit pour le mettre sur le dépot public.
Passer par du ftp ssl pourquoi pas mais il faut garder ce principe de sécurité.

Pour ce qui est de la compilation sur le serveur lui-même, je vous rappelle que tout TU doit déjà tester son paquetage en local. Or de question de balancer son PKGBUILD au monde entier et découvrir ensuite que la compilation plante :-D
Le cas du programme java qui ne compile pas avec fakeroot devra être étudié en détail. Pour ce qui est de l'intrégrité du système de compilation, encore une fois tout sera fait dans un environnement chroot temporaire qui sera remplacé avant chaque compilation. A la limite fakeroot ne serait même pas utile.

Avatar de l’utilisateur
lenglemetz
Chu Ko Nu
Messages : 307
Inscription : dim. 27 mai 2007, 22:26
Localisation : Kamikaze Land
Contact :

Message par lenglemetz » lun. 07 janv. 2008, 19:52

warnaud a écrit :Aujourd'hui y'a que wain et skunnyk (peut être lenglemetz :D) qui s'en occupent c'est trop peu.
Oui chef, je compile toujours pour 64 bits, je me sent seul :D
☠ ☠ ☠ ⅛|™ ☠ ☠ ☠ ¬|¬ Born To Be Web ¬|¬ DonF ¬|¬ ☠ ☠ ☠ ®|© > [Thème] Sujet (état) <

Avatar de l’utilisateur
bapt
Daikyu
Messages : 85
Inscription : jeu. 20 sept. 2007, 09:20
Contact :

Message par bapt » lun. 07 janv. 2008, 19:55

wain a écrit :Pour l'exécution d'une commande après l'upload, il faudrait que l'utilisateur ait un compte avec assez de privilèges. C'est dangereux. Le système actuel avec sa tâche cron permet d'avoir dans un premier temps un paquetage déposé par le TU dans un endroit restreint (jail ssh) et ensuite un robot qui va chercher le paquet dans cet endroit pour le mettre sur le dépot public.
Le script déclenché par l'upload d'un fichier peut être exécuter avec d'autres droits que ceux de l'utilisateur, car il est lancé par le serveur ftp et non par l'utilisateur lui même.

pure-uploadscript a pour option -u (uid) et -g (gid) pour savoir en quel utilisateur il va être exécuter.

Avatar de l’utilisateur
wain
Maître du Kyudo
Messages : 1854
Inscription : ven. 11 août 2006, 19:15
Localisation : Nancy (54)
Contact :

Message par wain » lun. 07 janv. 2008, 21:51

bapt a écrit : Le script déclenché par l'upload d'un fichier peut être exécuter avec d'autres droits que ceux de l'utilisateur, car il est lancé par le serveur ftp et non par l'utilisateur lui même.

pure-uploadscript a pour option -u (uid) et -g (gid) pour savoir en quel utilisateur il va être exécuter.
Dans ce cas c'est parfait 8)

Répondre