En cas d'erreur ou si le machin plante ben à moi de réparer le script et si besoin est, recommencer. Scripté ou pas, quand ça foire tu répares et tu recommences en général :)

Sachant que mon seul but est d'installer le système, un serveur web, PHP, MySQL, SVN et un ou deux trucs, c'est tout. (sans oublier les commandes à exécuter pour mettre à jour certains trucs, redémarrer [b]xinetd[/b] par exemple) À part quelques fichiers de config tout ce qu'il y a à faire c'est demander l'installation des programmes par emerge (ou peu importe quel gestionnaire de paquet pour quelle distribution).

Pour le scriptage, ca se défend, mais dans le cas où tu fais pas script une opération qui habituellement se fait à mano, tu n'as pas peur d'une erreur de compilation ou de téléchargement qui ferait planter tout le processus ? Notamment s'il y a des problèmes de compatibilité ou de dépendance, ou bien alors des problèmes de connexion aux dépots, de fichiers supprimés...

J'imagine que c'est le ratio simplicité/taille qui me fait pencher vers le scriptage. Le script et l'archive contenant quelques fichiers de config (serveur web, sql, etc...) doit faire quelques dizaines de kilos, à comparer aux ~2 GiB que doit faire le système complet. Et puis un script ça se met à jour facilement. Si un mois après avoir installé je me rends compte que j'avais oublié un programme je peux le rajouter à la liste d'[b]emerge[/b].

[quote="Sékiltoyai"]quel est l'intérêt de recompiler pour réinstaller ?[/quote]
C'est très théorique mais si je me faisais hacker je préfèrerais formatter/réinstaller un système identique plutôt que d'essayer de tout effacer/mettre à jour.

Il y a des tas de façons de faire ça, j'ai lu des histoires de gens gardant tout leur système sous SVN ou garder une copie prête à rsync'er, mais dans mon cas (une installation par an) un script bash c'est léger et ça fait le même boulot donc l'un dans l'autre je pense que c'est ce qui me convient le mieux.

[quote="Hubert Roksor"]
Oui, sûrement :lol: D'autant plus que les deux machines sont identiques, ça veut dire que j'emergerais sur l'une puis sur l'autre, ce qui n'a pas de sens (autant [i]emerge[/i]r les deux individuellement mais simultanément). [/quote]
Je te crois sur parole, à vrai dire je n'ai jamais utilisé de gentoo (c'est limite si j'ai déjà réussi à compiler un programme sous linux :D

[quote="Hubert Roksor"]
Je ne cherche pas juste à le "faire marcher", ce que je cherche c'est surtout à savoir [i]si[/i] ça marche et [i]comment[/i] ça marche, avec pour but d'automatiser toute cette procédure par un script. De cette façon en cas de pépin ou en cas de besoin je peux réinstaller la machine en quelques instants (si on oublie la demi journée passée à recompiler... :lol:).
[/quote]
Si la compilation se passe bien et qu'au final tu as des binaires stables, et compilés spécialement pour ta machine avec toutes les optimisations et tout, quel est l'intérêt de recompiler pour réinstaller ? Ce ne serait pas plus simple, plus pratique et plus rapide de vider la racine et réuploader le système entier préalablement compilé sur ta dédibox si jamais tu avais un problème avec ton serveur ?

Bon, ben finalement mon problème s'est plus ou moins réglé à force d'acharnement. Il semblerait qu'il s'agisse d'un combinaison de variables d'environnement pas prises en compte (pas mises au bon endroit) et/ou de package qui n'utilise pas la parallélisation. En ajoutant à mon [b]/etc/make.conf[/b] la variable d'environnement [b]DISTCC_HOSTS[/b] je suis parvenu à le faire marcher.

Je recompile [b]dev-util/subversion[/b] en boucle depuis que je suis réveillé pour tester différents réglages, mais les gains en performance sur ce paquet sont loin d'être faramineux, même s'il peut s'agir d'un erreur de ma part au niveau de la config. Imaginez les deux machines sd1 et sd2. Ce que je remarque, c'est qu'en compilant sur sd1 avec 3 jobs à la fois (1 distcc en local, 2 distcc sur sd2) la seconde machine, sd2, reste idle pendant d'assez longues périodes (lisez "quelques secondes) apparement dû à la latence entre les jobs. Je suis passé à 2 en local et 3 sur l'autre machine avec une légère amélioration. Pour info, pour une compilation locale sans [b]dev-util/subversion[/b] prend à peu près 10min40 (real, d'après time). Avec 1+2 jobs on tombe à 9min20 et avec 2+3 jobs je suis tombé à 9min10. Le tout sans [b]ccache[/b] pour ne pas fausser les résultats bien sûr. Je vais sûrement faire quelques tests supplémentaires, mais je ne pense pas continuer dans cette voie. Ah, autre observation importante : de façon à lancer 1 job de compilation en local et 3 autre sur la seconde machine on est obligé de mettre le nombre de jobs effectués par [b]make[/b] à 4
[code]MAKEOPTS="-j4"[/code]
C'est très bien quand on compile parce que 3 de ces jobs vont à l'extérieur, mais toutes les opérations d'installations (exécution de scripts, copier/déplacer/compresser des fichiers, etc...) sont elles aussi effectuées 4 par 4 par la machine locale, qui se retrouve surchargée (la valeur recommandée étant de 2 par CPU) ce qui explique les longues périodes d'inactivités des machines "externes". J'ai lu sur la mailing-list de distcc qu'un patch existait pour changer le nombre de jobs selon le type d'activité, mais aucun patch n'a été fusionné aux sources, qui sont apparemment dans le coma depuis plusieurs années. La bonne nouvelle c'est que Google semble intéressé (normal quand on compile des dizaines de kernels par jour, j'imagine), possède plusieurs patches qu'ils souhaitent publier et fusionner. Donc gardez un œil sur distcc au cas où.

[quote="Sékiltoyai"]Si tu lances la compilation sur une de tes deux machines, elle aura peut être fini avant que t'ai trouvé la solution. :mrgreen:[/quote]
Oui, sûrement :lol: D'autant plus que les deux machines sont identiques, ça veut dire que j'emergerais sur l'une puis sur l'autre, ce qui n'a pas de sens (autant [i]emerge[/i]r les deux individuellement mais simultanément). Je ne cherche pas juste à le "faire marcher", ce que je cherche c'est surtout à savoir [i]si[/i] ça marche et [i]comment[/i] ça marche, avec pour but d'automatiser toute cette procédure par un script. De cette façon en cas de pépin ou en cas de besoin je peux réinstaller la machine en quelques instants (si on oublie la demi journée passée à recompiler... :lol:).

Si j'ai d'autres infos intéressantes je les posterai ici.

Si tu lances la compilation sur une de tes deux machines, elle aura peut être fini avant que t'ai trouvé la solution. :mrgreen:

A priori c'est ouvert puisque j'arrive visiblement à faire une boucle où chaque machine appelle l'autre pour compiler et se renvoit la balle indéfiniment. Je vais faire un coup de nmap par acquis de conscience, parce que j'arrive à court d'idées de toutes façons :cry:

Je vous tiens informés, n'hésitez pas si vous pensez à autre chose :roll:

PS: j'allais oublier, en fait je pense que distcc n'est tout simplement pas appelé du tout et que le compiler est appelé directement. Manque de bol je comprends rien au système qui permet à l'un d'appeler l'autre, y'a des fichiers partout et des symlinks dans tous les sens :lol:

Edit: c'est rigolo, je viens de réessayer et maintenant il semblerait qu'une des deux machines utilise bien distcc (pour s'appeler elle-même et pour appeler l'autre) mais pas l'autre. Va comprendre :-s Pour le reste, nmap me dit que c'est ouvert

Les compil distribuées avec distcc existent aussi sous Debian (et donc certainement sous Ububtu) mais, c'est vrai qu'on compile moins que sur une Gentoo :wink:

Je suppose que tes ports sont ouverts (iptables?) et que les paquets IP ne sont pas filtrés par un TcpWrapper (hosts.allow hosts.deny).

Connais pas Gentoo, mais tu es sûr que ton protocole (tcp ?) n'est pas bloqué d'une manière ou d'une autre? Si nmap existe sous Gentoo, il devrait t'aider à voir ce qui est ouvert. Si c'est ouvert, les paquets arrivent-ils bien de l'autre côté (tcpdump ou autre packet sniffer).

Je n'ai jamais joué avec Gentoo, je ne sais pas qui c'est ccache et distcc, donc j'espère que c'est pas à moi que tu pensais :lol:

Bonjour chers amis,

Je suis en train de faire quelques tests sous Gentoo (que je découvre) et j'essaie en ce moment même de faire fonctionner distcc sans succès. Je crois me rappeler qu'il y a un ou deux utilisateurs expérimentés ici (sauf que j'ai oublié qui :lol:) donc je tente ma chance ici à tout hasard.

Je plante le décor : j'ai formatté 2 dédibox avec Gentoo 2006.1, sync'é, un peu mis à jour puis installé ccache et distcc avec
[code]emerge --sync
emerge sys-apps/portage
emerge sys-devel/gcc
emerge dev-util/ccache
ccache-config --install-links i686-pc-linux-gnu
emerge sys-devel/distcc[/code]
J'ai configuré/installé distcc sur le port 30000 avec les IPs externes des 2 machines
[code]distcc-config --set-hosts "88.191.xxx.yyy:30000 88.191.xxx.zzz:30000"
rc-update add distccd default
/etc/init.d/distccd start[/code]
J'ai configuré /etc/conf.d/distccd toubienkomifo (en changeant l'IP de --listen pour chaque machine)
[code]DISTCCD_EXEC="/usr/bin/distccd"
DISTCCD_PIDFILE="/var/run/distccd/distccd.pid"
DISTCCD_OPTS="-j2 --port 30000 --log-level debug --allow 88.191.xxx.yyy --allow 88.191.xxx.zzz --listen 88.191.xxx.yyy"
DISTCCD_NICE="15"[/code]
puis modifié mon /etc/make.conf en conséquence (ce sont les seules modifs liées à ccache/distcc)
[code]FEATURES="ccache distcc parallel-fetch"
CCACHE_SIZE="4G"
CCACHE_DIR="/var/tmp/ccache"[/code]

En théorie et d'après les sites que j'ai lu, je devrais avoir fini. J'ai même rebooté par acquis de conscience mais mes logs restent désespéremment vide et distcc ne semble pas être utilisé. J'ai vérifié avec distccmon, en surveillant avec netstat ou top... nope, l'autre machine reste totalement inerte pendant que la première compile (par emerge). J'ai essayé l'ancienne méthode d'installation de distcc, qui consistait à utiliser
[code]CCACHE_PREFIX="distcc"[/code]...mais chaque machine reçoit l'ordre de compilation, lance ccache, qui lance distcc, qui renvoit vers une autre machine, etc... heureusement distcc s'aperçoit de la boucle et refuse de continuer.

Je suis ouvert à toute suggestion, si vous avez la moindre idée... merci merci.