# [scripts] chenvr et syndgen (chroot & install/maj déporté)

## kwenspc

Comme prévu je post ici 2 petits scripts qui pourront, je l'espère, en aider quelques uns. 

Note: GenServ est très crade et manque cruellement de pas mal de choses (voir ToDo list). Entre l'idée et l'implémentation y a un monde, avec moi...  :Neutral: 

I - Principe:

J'utilise actuellement ces 2 scripts dans un buts bien précis: mettre à jour mon serveur sous Gentoo, sans pour autant faire les compil sur mon serveur, et sans même que mon serveur n'ait de compilateur ni rien de relatif à portage etc... En gros j'ai un serveur Gentoo, sans tous les outils qui font une Gentoo. 

L'idée de départ est basé sur deux faits:

mon serveur est un antique P3 600 et compiler n'est plus de son âge.  :Laughing: 

dans un soucis de sécurité - minimaliste, je l'avoue - un serveur n'a pas à avoir de compilateur (ni pas mal de chose d'ailleurs).

Ce qui revient à dire que le serveur doit pouvoir être mis à jour sans que lui ne fasse de grosses tâches de maj. On oublis donc distcc, car là il faut encore que le serveur travail un peu. J'ai donc opté pour la technique de la mise à jour 100% déportée. Ça revient à avoir une image, complète cette fois-ci, de votre serveur ailleurs qui elle peut donc être mise à jour. Puis ensuite il faut exporté ces mises à jours sur le serveur de la manière la plus simple qui soit.

II - Chenvr:

Site (avec ebuild cette fois): ICI

L'image complète (avec compilo, portage et cie) de mon serveur, je ne pouvais la crée sur une autre machine dédiée. La seule machine autre que j'ai c'est mon desktop. Soit utilisons le desktop. Je suis partis de ce topic --> [HOWTO]chroot 32 bit sur amd64 . Et chenvr n'est rien de moins que l'automatisation de la procédure décrite dans ce topic (merci à marvin rouge au passage pour le-dit topic)

Vous pouvez télécharger chenvr.sh ici.

Merci à adjaxio pour les tests successifs du script  :Wink: 

L'avantage de cette technique est de pouvoir utiliser la puissance de nos desktop (leur arbre portage aussi) tout en continuant à utiliser le desktop en question pour nos autres tâches habituelles.

Bien évidemment chenvr peut servir à créer un environnement chrooté pour une utilisation comme celle décrite dans le topic de marvin rouge.

L'utilisation est très simple. La seule contrainte et de l'utiliser dans un emplacement de votre disque où il pourra disposer d'un espace suffisamment large (> 1Go "en gros") et il nécessite d'être lancé avec les droits root. 

L'aide et la version:

```

# ./chenvr -h

...

# ./chenvr -v

```

chenvr parle de "'target", de cible. La cible c'est le nome de l'environnement chrooté que vous souhaitez créer. l'option -t vous permet de spécifier ce nom et -c de créer la cible proprement dite. Vous avez accès à 3 bases machines: x86 (i386), i686 et x86_64 (pour ceux qui tournent avec un desktop en amd64 bien entendu).

```

#./chenvr -t gnia -c i686  (va créer un environnement chrooté 32 bits appelé "gnia" sur une base i686)

```

chenvr télécharge de lui même le bon stage3, tout est automatique.

Pour utiliser la cible ensuite c'est très simple:

```

#./chenvr -t gnia

```

Sinon il y a l'option -b pour faire une sauvegarde de la cible et enfin l'option -r pour supprimer la cible.

J'ai personnellement plusieurs cibles gérées via chenvr: une pour mon serveur (et chenvr) une pour la maj de mon laptop et une pour pouvoir lancer certaine applis 32 bits comme epsxe par exemple.

Nouvelle version: Vous aurez remarquer le changement de nom de genenv on est possé à chenvr (CHrooted ENViRonment + jeux de mot pourri oui oui). En fait Je voudrais qu'à terme ce script puisse être utilisé pas uniquement sur/pour gentoo. 

- nouveauté: finit les répertoires cachés en dehors de la cible. Là tout est DANS la cible (elle embarque son propre .chenvr à la racine)

- un script custom.sh  est appelé lors de chroot: vous pouvez le modifier et lui faire faire ce que vous voulez. Il y a pas mal de tâches automatisable (export de variables d'environnement comme DISPLAY, TERM ce que vous voulez, meme des commandes comme env-update, source /etc/profile etc... et bien éviedemment plus encore.)

III - Syndgen:

Le site de syndgen.

----------

## F!nTcH

T'es énorme !!

J'ai un PIII 500 qui contient une gentoo, et ça lui ferai le plus grand bien de ne pas avoir à compiler (et moi aussi ...)

Je poste sans avoir tout lu ni tout regardé, d'autres passeront aussi. Si je trouve un peu de temps dans le courant de la semaine, je jeterai un oeil à tes scripts, et je pourrais éventuellement te proposer une idée pour le transfert de fichiers.

Pour ceux qui voudraient me devancer, je travaillerai à base d'FTP avec un serveur FTP autorisant le compte root (oui c'est pas beau, mais bon, y'a un moment où il faut savoir mesurer risques et prise de tête), et un client à base de NcFTP (copie récursive, utilisation par scripts et même dans les scripts)

PS : pour le serveur FTP, on peut le blinder un peu : accès LAN uniquement, restrictions à 1 IP, FTPs, ou même, connexion de l'admin par SSH et démarrage/arrêt manuel du serveur FTP ... et bien d'autres ... chacun se gère ... (on peut en débattre à côté dans un autre topic  :Wink:  )

On va bien trouver des gens pour t'aider à faire du ménage kwenpc  :Wink: 

Merci encore !

----------

## kwenspc

À la limite pourquoi pas offrir plusieurs manière de déploiement. Je suis en train de voir rsync là, avec l'option  --exclude=PATTERN si y a pas moyen d'exclure toute une liste de pattern ça pourrait être sympa.

[edit] ah bah ouais --> --exclude-from=FILE [/edit]

----------

## sd44

si j'ai bien compris tu fais une sorte de depots style debian et ta machine vient chercher son package dedans ? et tu souhaite automatiser la maj 

juste une suggestion pour ta premiere copie, pourquoi pas une sorte de "cp -a" + "emerge -C gcc etc ..." + emerge --depclean  revdep etc 

ensuite il faudrait que quand tu fait un emerge truc, il aille compiler truc sur ta machine a compiler et revienne installer le paquet sur ta machine,

pour les mise a jour, mettre a jour le srv de compil et ton srv ensuite qui ira chercher les paquets naturelement avec "emerge -uDa --getbinpkgonly world" ou un truc du genre

enfin bon c'est juste une idée en vrac   :Very Happy: 

----------

## kwenspc

 *sd44 wrote:*   

> si j'ai bien compris tu fais une sorte de depots style debian et ta machine vient chercher son package dedans ? et tu souhaite automatiser la maj 
> 
> 

 

Actuellement la machine ne fait rien qui concerne la maj. Elle n'est pas capable d'aller chercher aucune mise à jour (pas de portage, pas d'emerge, pas de gcc, pas de headers dans /usr/include, bref rien qui touche à la gestion de paquet...).

Sinon merci pour l'idée, je verrais ça. Mais je suis en train de refaire genserv en Python cette fois (oui oui un beau script qui s'installe proprement avec un ebuild et tout, et qui fout pas des fichiers de config tout moisis là où il faut pas  :Laughing: )

Je suis aussi en train de passer à rsync, mais ça demande encore à faire des tests. L'idée c'est que :

- lors de la première install, via un live cd, on fasse un rsync (avec les bons paramètres) qui ira chercher ce qu'il faut dans le serveur rsync (qui ne sera rien d'autre que l'environement chrooté avec genserv dedans pour géré le tout)

- lors de maj, pareil un rsync sur le même environnement

Rsync permet en effet l'exclusion précise de tel ou tel rep/fichiers. Maintenant reste à savoir si c'est pas trop lourd en terme de temps/performance côté client en tout cas (la machine qui se synchronise)

Au pire je laisserais le choix des méthodes (envois des tbz2 par ssh, ou rsync ou autre...). Je tente de faire un truc vraiment modulaire, facile à modifier par l'ajout de plugins. Je vous tiens au courant.

----------

## geekounet

[déconnade]

 *kwenspc wrote:*   

> mon serveur est un antique P3 600 et compiler n'est plus de son âge. 

 

 *F!nTcH wrote:*   

> J'ai un PIII 500 qui contient une gentoo, et ça lui ferai le plus grand bien de ne pas avoir à compiler (et moi aussi ...)

 

Mais, mais, mais ... qu'est ce que vous avez contre ce bon vieux PIII auquel je voue un culte suprême ?  :Sad:  (et à ces petits frères Pentium M et compagnie aussi)

Faut lui faire honneur et le laisser compiler comme les grands, il tient encore très bien la forme avec son âge ^^

[ma vie]

Mon bon vieux PIII 800 compile tranquillement ses mises à jour de FreeBSD, fait tourner un spamassassin et tout plein d'autres trucs lourds en même temps sans broncher ... bon ok, il a beaucoup de mal à faire tourner de manière décente une application RoR, mais bon c'est d'une nouvelle génération ça, ça peut se comprendre ...

[/ma vie]

Si ça continue, je vais devoir fonder un temple pour le culte du PIII, et batailler pour conserver sa gloire d'antan  :Laughing: 

Oui bon, vous savez il est tard, tout ça .... oui bon, j'y vais, oui je sais, c'est par là => ... []

[/déconnade]

----------

## kwenspc

Ah ah  :Laughing:  nan geekounet le problème est avant-tout un soucis de sécurité. Pour moi il est totalement exlut que mon serveur possède quoique ce soit qui permette de compiler. D'où l'idée de déporté la maj ailleurs et faire en sorte que la synchronisation de l'install avec le serveur évite de lui mettre gcc, etc...

----------

## F!nTcH

@geekounet

Rhooo !! mais nan !! Je suis également très fier de mon PIII 500 et jamais je l'enverrai à la poubelle (le boîtier peut-être il m'énerve...).

Après tout, il s'est compilé son kernel tout seul, j'ai simplement fait autre chose à côté (sur un PIV HT ...  :Cool:  )

Je pense depuis longtemps que ça fera un très très bon serveur domestique. Par contre, c'est bruyant ... (du moins pour ma part, j'ai une version en slot et pas en socket, il fout un barouf terrible   :Confused:  )

Après je suis d'accord que l'arbre portage sur le serveur, ça le fait pas trop ...

----------

## kwenspc

 *F!nTcH wrote:*   

> Par contre, c'est bruyant ... (du moins pour ma part, j'ai une version en slot et pas en socket, il fout un barouf terrible   )
> 
> 

 

Carrément. Le mien est un PII 600EB slot one. Le seul moyen que j'ai eu de le faire "taire" c'est de coller un potentiomètre sur la bornes '+', puis de réglmer afin que le ventilo ait un rapport rpm/bruit acceptable. 

(d'ailleurs si vous avez un PIII 600EB slot one en rab je suis preneur   :Cool:   j'ai une CM bi-cpu qui s'ennuie là)

----------

## bi3l

Très intéressants, ces scripts ! D'autant que j'ai un eee pc sur lequel je mettrai bien une gentoo ! Je me disais même qu'il devrait être possible de limiter encore plus les fichiers à mettre sur le client déporté en ne déployant que les paquetages en "runtime dependency" (RDEPEND). Cependant, je ne sais absolument pas comment récupérer les RDEPEND effectives d'un ebuild installé. Quelqu'un connait un script qui sait faire ça ?

----------

## kwenspc

 *bi3l wrote:*   

> Très intéressants, ces scripts ! D'autant que j'ai un eee pc sur lequel je mettrai bien une gentoo ! Je me disais même qu'il devrait être possible de limiter encore plus les fichiers à mettre sur le client déporté en ne déployant que les paquetages en "runtime dependency" (RDEPEND). Cependant, je ne sais absolument pas comment récupérer les RDEPEND effectives d'un ebuild installé. Quelqu'un connait un script qui sait faire ça ?

 

Ça doit pas être bien compliqué en fait.

Suffit de savoir quelle version est installée le paquet x, ensuite tu pécho la liste de soft contenu dans le fichier /var/db/pkg/x-v/RDEPEND

Sauf si tu cherches à partir d'un paquet à faire tout la liste de dépendance et de leur RDEPEND. là ça commence à être un poil plus compliqué (faire en sorte d'éviter les doublons donc les risques de tourner en rond). Mais peut-être qu'un soft fais déjà ça. (à mon avis oui)

----------

## bi3l

 *kwenspc wrote:*   

> Suffit de savoir quelle version est installée le paquet x, ensuite tu pécho la liste de soft contenu dans le fichier /var/db/pkg/x-v/RDEPEND

 

Sauf que le fichier RDEPEND contient les dépendances "non résolues", c'est-à-dire la recopie exacte du RDEPEND de l'ebuild avec les USE et les >=, =, ||, ... C'est tout de suite moins facile...

----------

## kwenspc

 *bi3l wrote:*   

> 
> 
> Sauf que le fichier RDEPEND contient les dépendances "non résolues", c'est-à-dire la recopie exacte du RDEPEND de l'ebuild avec les USE et les >=, =, ||, ... C'est tout de suite moins facile...

 

Tu veux dire que dans le RDEPEND il liste tous les ebuild sans appliquer ce qu'on aura pas sur le système pour couse de USE non inclus? 

C'est pas génial dans ce cas en effet. Du coup mieux vaut encore rester sur un rsync de la partition (avec exclusion des reps/binaires inutiles) même si c'est pas un travail en 2 commandes.

----------

## Mickael

Juste comme ça, peut-être une bonne idée de parler de tes scripts dans la prochaine GMN, non?

----------

## kwenspc

 *Mickael wrote:*   

> Juste comme ça, peut-être une bonne idée de parler de tes scripts dans la prochaine GMN, non?

 

Serieusement? non  :Laughing: 

Le code est pas génial. (soyons francs)

J'ai refait genenv il y a peu (toujours pas posté) et genserv est obsolète. Je dois le refaire mais... le baobab dans la main   :Confused: 

Et je me tâte toujours quand à les passer en full python, plutôt que de rester en bash (d'autant que là je suis même pas sûr qu'il soit posix, c'est mêmé certain...donc pour zsh et autres c'est mort.)

----------

## adjaxio

Merci .

Je vais enfin pouvoir passer mon serveur sous gentoo (il est en se moment avec fedora).

Consernant zsh ca fonctionne bien avec pour le genenv.sh

AdJaXiO

----------

## kwenspc

 *adjaxio wrote:*   

> 
> 
> Consernant zsh ca fonctionne bien avec pour le genenv.sh
> 
> AdJaXiO

 

Ah merci d'avoir testé  :Smile: 

----------

## adjaxio

Pour le moment je fait des teste sur une machine virtuel mais j'aime bien le principe

----------

## kwenspc

Ça me motive pour continuer! 

Les dernières modifs que j'ai faites sont centrées sur la flexibilité. On oublis les reps cachés externes tout crades pour garder la config des target. Cette fois chaque target possède sa propre config et, de plus, il est possible d'étendre par scripts interposés l'automatisation de commandes lors du chroot. Ce qui me permet à moi de passer la variable d'environnement à TERM=xterm (sinon j'ai des erreurs quand ça reste à rxvt-unicode) mais aussi de loggé en user, puis d'eporter la variable DISPLAY afin de pouvoir lancer des applis dans le Xorg courant  à partir du chroot (pratique pour epsxe qui n'a pas été porté en x86_64  :Wink:  )

Je vais tenter de poster cette nouvelle version. Je suis passé au repos funtoo aussi pour les stages 3.

maintenant faut que fasse genserv en python, depuis que je le dis.

----------

## adjaxio

J'attent avec impatience les nouveautés

----------

## kwenspc

 *adjaxio wrote:*   

> J'attent avec impatience les nouveautés

 

T'as reçus mon MP?

----------

## adjaxio

 *kwenspc wrote:*   

>  *adjaxio wrote:*   J'attent avec impatience les nouveautés 
> 
> T'as reçus mon MP?

 

Je vien de voir ton Mp je teste et je te tien au courant

----------

## xaviermiller

Pas mal !

Y-a-t-il déjà un article décrivant comment créer une Gentoo "user-only", sans les "build tools" ?

----------

## bi3l

 *XavierMiller wrote:*   

> Y-a-t-il déjà un article décrivant comment créer une Gentoo "user-only", sans les "build tools" ?

 

Tu peux t'inspirer de http://fr.gentoo-wiki.com/Asus_Eee_Pc_701

----------

## xaviermiller

moui, j'aime pas trop l'approche qui évite des répertoires plutôt que de n'installer que les packages nécessaires (via des qpkg)

----------

## bi3l

Ce sont bien des qpkg. Mais les qpkg contiennent effectivement des .h, des .la, des .a, ... autant de fichiers qui ne doivent pas être installés sur une distrib binaires.

----------

## xaviermiller

bon, je vais regarder alors  :Wink: 

----------

## kwenspc

C'est effectivement le seul moyen d'éviter ces fichiers .h, .a etc... Le masque d'installation est le seul moyen de les éviter relativement proprement.

----------

## kwenspc

Le développement de genserv avance (fin dès que j'ai du temps). L'état actuel du logiciel fait déjà beaucoup plus que l'ancien script bash obsolète. J'essaie du mieux que je peux de faire un soft qui suit le principe KISS (la configuration de base de logiciel permet dès le départ de l'utiliser).

Je vous tiens au courant.  :Smile: 

----------

## Temet

 *le tuto wrote:*   

> chenvr est indépendant de chenvr (et inversement d'ailleurs). 

 

Sur qu'inversement, chenvr est indépendant de chenvr  :Laughing:   :Laughing: 

----------

## kwenspc

 *Temet wrote:*   

>  *le tuto wrote:*   chenvr est indépendant de chenvr (et inversement d'ailleurs).  
> 
> Sur qu'inversement, chenvr est indépendant de chenvr  

 

Corrigé  :Wink: 

Sinon une version de test "devrait" apparaître la semaine prochaine pour genserv. (si tout va bien)

----------

## kwenspc

Packaging terminé  :Smile:   bon il me faut tester tout ça en vrai avant de pouvoir faire la release.

----------

## kwenspc

Je suis en plein test là, j'ai une petite question à propos de rsync si y en a qui maîtrise l'outil.

Dans le man il y a cette section: 

 *Quote:*   

> 
> 
> USING RSYNC-DAEMON FEATURES VIA A REMOTE-SHELL CONNECTION
> 
>        It is sometimes useful to use various features of an rsync daemon (such as named modules) without actually allowing any new socket con-
> ...

 

Le "spawning a single-use "daemon" server that expects to read its config file in the home dir of  the  remote  user" je l'ai compris tel que le démon rsync va se lancer en prenant pour config le rsyncd.conf trouvé dans le home du user (compte distant, celui du ssh pas le compte local).

Je me dis chouette je fous un rsyncd.conf dans /root coté serveur, je start sshd sur le serveur. Côté client je lance la commande rsync qui va bien et il me dit "no module blabla found". Pourtant le module blabla est bien config. Je déplace le /root/rsyncd.conf dans /etc et là ça marche. Ça m'arrange moyen, mais dois-je conclure que pour l'utilisateur root, la config est /etc/rsyncd.conf de toute façon et qu'il n'y a pas moyen d'avoir un ~/rsyncd.conf?

----------

## Untux

ça aide ça ?

----------

## kwenspc

 *Untux wrote:*   

> ça aide ça ?

 

Hélàs non. J'ai bien spécifié les "::", j'ai suivis à la lettre la doc et le man. A priori ça à l'air du vouloir faire ça qu'avec l'utilisateur root.

C'est pas un problème bloquant, juste ennuyeux c'est tout.

----------

## kwenspc

Bon j'ai trouvé une autre méthode pour faire la même chose. C'est pas aussi propre cependant.

Faut lancer le démon rsync sur le serveur en spécifiant le fichier de config du user root et ensuite sur le client:

```

export RSYNC_CONNECT_PROG='ssh -p 2222 server nc server 873'

rsync -avn server::module ./

```

Bref c'est tout moche, ça utilise netcat pour faire "proxy". Mais au moins ça utilise pas le rsyncd.conf sur /etc

----------

## kwenspc

Bonsoir, 

J'ai finit le code de genserv (il y a quelques jours déjà), je suis en train d'écrire la doc maintenant (le plus chiant mais le plus important en fait ^^). Cependant avant de diffuser quoique ce soit je voudrais faire des tests plus poussés que les mien et/ou différents, surtout. Est-ce quelqu'un serait intéressé? 

Envoyez moi un mp, je vous passerais l'archive, l'ebuild et la doc (faut juste que je la termine).

----------

## dapsaille

Un peu HS mais bon pour toi ca peux le faire =

http://search.ebay.fr/search/search.dll?from=R40&_trksid=m37&satitle=600+eb&category0=

----------

## kwenspc

Exactement ce que je cherche sauf que je suis pas en France  :Confused:  Fin c'est pas ma priorité n°1 en ce moment de trouver un frère jumeau au CPU actuel de mon serveur. Si ça se trouve j'ai ptet un collègue dans le coin qui en a. Merci en tout cas!

----------

## kwenspc

La page de chenvr

Je me suis déchiré sur le design ouèb   :Cool: 

nan?

----------

## Untux

Fantastique. Et trop bien l'ajout des {prepare,clean}.sh !

Merci !

 *kwenspc wrote:*   

> Je me suis déchiré sur le design ouèb 
> 
> nan?

 

Un chef-d'oeuvre de sobriété typographique !

----------

## kwenspc

Le site de syndgen (anciennement nommé genserv)

Voilà voilà. Bon côté doc ça pèche un peu. C'est pas super clair, manque la doc pour les devs etc... Mais c'est un début.

----------

## truc

 *kwenspc wrote:*   

> Le site de syndgen (anciennement nommé genserv)
> 
> Voilà voilà. Bon côté doc ça pèche un peu. C'est pas super clair, manque la doc pour les devs etc... Mais c'est un début.

 

"Table des matières" 

C'est anglais ça?   :Razz: 

Sinon ça serait sympa de pouvoir voir les différents scripts sans entrer dans la phase d'installation, car même pour le site ou t'as mis trac, j'vais rien quand on browse les sources  :Confused: 

----------

## kwenspc

 *truc wrote:*   

> 
> 
> "Table des matières" 
> 
> C'est anglais ça?  
> ...

 

Tiens oui, vais corriger ça.   :Embarassed: 

 *truc wrote:*   

> 
> 
> Sinon ça serait sympa de pouvoir voir les différents scripts sans entrer dans la phase d'installation, car même pour le site ou t'as mis trac, j'vais rien quand on browse les sources 

 

C'est prévu, un repos bzr va être mis en place. (lisible depuis trac)

[edit]makeinfo qui me fait un truc space, je lui fournit le @documentlanguage en  et il continue de me mettre "Table des matières" alors que texi2html fonctionne. Pas net ça...[/edit]

----------

## adjaxio

Bonjour,

Y a t-il une traduction prévue de la documentation ?

Merci

----------

## kwenspc

Pas bête. Je pense oui que je vais en faire une. Et sans doute même meilleur (c'est pas dur en même temps) que celle en anglais.

Faut aussi que je fasse une doc développeur. (le code est pas compliqué du tout, surtout pour ajouter des commandes)

----------

## kwenspc

Ok le browser source est configuré.

makeinfo me fait toujours le truc foireux par contre.

----------

## kwenspc

Juste un ptit up pour dire que j'ai ajouté 2 nouvelles doc sur le site: une qui décrit un cas d'utilisation (en fait, peu ou prou ce que j'ai fait sur mon serveur perso) et une pour les devs.

La version trunk possède une nouvelle fonction: la capacité de créer une exclusion rsync à partir d'une liste de paquet gentoo, ça simplifie pas mal les choses (mais ça check pas encore les RDEPENDS)

----------

## Da_Risk

Mais ils sont passés ou ces super scripts pour mettre a jour mon eeepc ??? 

Quelle ne fut pas ma surprise lorsque je m'apperçu qu'il m'était impossible de télécharger les sources snifff

Si quelqu'un a les archives sous la main qu'il me fasse signe ^^

----------

