| View previous topic :: View next topic |
| Pensez-vous que Gentoo Linux soit adaptée à un usage professionnel ? |
| Oui, je pense... |
|
33% |
[ 36 ] |
| Oui, et j'en suis sûr : ça marche déjà chez moi ! |
|
37% |
[ 40 ] |
| Non, je ne crois pas... |
|
16% |
[ 18 ] |
| Non, j'ai déjà essayé, et je ne suis pas convaincu ! |
|
1% |
[ 2 ] |
| Oui et non : je suis normand, et je m'en vais vous expliquer mon point de vue ci-dessous ! |
|
9% |
[ 10 ] |
|
| Total Votes : 106 |
|
| Author |
Message |
xaviermiller
Bodhisattva
Joined: 23 Jul 2004
Posts: 8711
Location: ~Brussels - Belgique
|
|
| Back to top |
|
 |
bountykiller
n00b
Joined: 24 Feb 2005
Posts: 30
Location: Belgique (Tournai)
|
 Posted: Sat May 20, 2006 10:53 am Post subject: |
 |
|
| Oupsman wrote: |
Sur un ensemble de serveurs gentoo en production et fonctionnant sous la même application, les USE flags seront les mêmes partout. Cela tombe sous le sens  Et il y'aura aussi des serveurs de recette/qualification/préproduction. Ca aussi çà tombe sous le sens
|
Ben non justement, pas toujours.
| Oupsman wrote: |
Ensuite, il est évident qu'un tel service de production demande une certaine planification et ne s'adresse pas à une pme.
C'est mon métier l'administration système et je peux te dire que le temps passé à faire des mises à jour/patches et autre est absolument prioritaire sur le reste des tâches, quitte à les déléguer. Et en planifiant intelligement ses mises à jour, cela se fait sans douleur.
Mais encore une fois, il faut que le parc de serveurs soit absolument homogène. Ceci dit, dans une grosse boite c'est très réalisable.
|
Exactement. Je travaille dans une pme, et les serveurs que l'ont installe sont pas toujours les mêmes, et n'ont pas forcément la même config et/ou les même progs d'installer (même si on essaie d'uniformiser un max).
Ensuite, comme tu les dis, il faut avoir une à plusieurs personnes qui ne s'occupent que de ça, avec quelques machines à disposition.
La question que je me pose alors est, s'il faut tout cela juste pour utiliser gentoo à la place d'une debian par exemple, quel est l'intéret pour ton employeur? Je ne dis pas que ce genre de chose n'est pas réalisable, (assurément cela l'est), mais j'ai du mal à voir l'intéret d'un point de vue économique.
Et de toute façon, comme tu l'as dis ce genre de chose associé à la contrainte d'avoir un parc homogène rend ceci quasi inexploitable dans une pme comme celle ou je suis. (Car là, les mises à jour concerne des centaines de serveurs pas forcément homogènes et qui sont chez nos client)
_________________
Xfce Rocks |
|
| Back to top |
|
|
k-root
Guru
Joined: 08 Jan 2005
Posts: 428
|
| Posted: Sat May 20, 2006 12:57 pm Post subject: |
|
|
| PabOu wrote: | je plussoie Siryessire et Oupsman. Ils ont répondu à ces gens qui pensent que Gentoo n'est pas adapté au milieu professionel pour des raisons qu'ils ne comprennent pas (manque de connaissances/compétences ?).
|
tu est de la famille de gcc ? tu a une option -pedantic ?
| PabOu wrote: |
En gros, le problème évoqué c'est "gentoo n'est pas adapté car compiler c'est pas bien, c'est lourd et ca prend du temps". |
je ne vois pas ce qu'il y a de choquant a dire que "compiler c'est pas bien, c'est lourd et ca prend du temps" , il y a des situation proffessionel ou c'est un gros handicape. le temps c'est de l'argent.
_________________
| boozo wrote: | | Gentoo, ça mange des ours et baffe des buffles par 37°C avec un bob et des tongs |
|
|
| Back to top |
|
|
PabOu
Veteran
Joined: 11 Feb 2004
Posts: 1088
Location: Hélécine - Belgium
|
| Posted: Sat May 20, 2006 2:04 pm Post subject: |
|
|
| cuicui wrote: | | si j'ai le choix entre passer plusieurs heures par semaine à mettre à jour mes serveurs (gentoo) et passer plusieurs minutes (Debian) pour un résultat final identique, je vais évidemment prendre la méthode qui me permet de travailler le plus efficacement. |
Il va falloir que tu m'expliques ou tu trouves une différence pareille pour mettre à jour des services. Et seulement "plusieurs minutes", ca me semble vraiment du travail baclé...
Le travail de mise à jour est le même partout :
- Vérifier les mises à jour disponibles
- Décider si il est utile ou pas d'installer une mise à jour (correction d'un bug ou d'une faille de sécu, meilleures performances ou bien nouvelles fonctionnalités). Si on ne met pas à jour, cela s'arrête là.
- Dans le cas où l'on choisit de mettre à jour, il faut tout d'abord prendre un serveur de test (dans le cas gentoo, rien n'empêche de le configurer initialement pour crééer des paquets binaires au passage, ca prend juste une fois 2minutes pour tout écrire dans le make.conf)
- Sur le serveur de test, on fait (éventuellement un backup suivi de) la mise à jour (sous gentoo, ca compile, mais rien ne t'oblige à rester devant ton terminal pour regarder la compilation)
- On teste les conséquences, histoire de voir si le système n'est pas devenu instable, si le service n'est pas cassé (du genre, si on met php à jour, s'assurer que toutes les pages web fonctionnent encore de la façon voulue), si la syntaxe d'un fichier de config n'a pas changé, des nouvelles options à paramétrer, et si le reste du système n'est pas impacté.. et enfin, si on ne peut pas se passer (et c'est ce point ci qui demande bien plus que tes quelques minutes avec Debian)
- Quand tout ca est OK, on fait un backup des serveurs de production (ben oui, une erreur peut quand même arriver)
- On met les serveurs à jour (au moment le plus opportun. avec gentoo, l'installation se fera grâce aux paquets générés précédemments sur la machine de test)
- On s'assure que tout fonctionne sur le serveur. Au besoin, on a fait une sauvegarde juste avant.
- On sourit béatement, content de notre travail :)
Le travail est le même partout, et même si Gentoo prend beaucoup de temps pour compiler certains paquets, ca n'êmpeche pas la mise à jour, et ca ne t'empêche pas de travailler sur un autre projet.
| k-root wrote: | | je ne vois pas ce qu'il y a de choquant a dire que "compiler c'est pas bien, c'est lourd et ca prend du temps" , il y a des situation proffessionel ou c'est un gros handicape. le temps c'est de l'argent. |
C'est un faux problème, comme je l'ai expliqué. Sauf dans le cas ou tu as un serveur qui tombe et tu dois en remettre un sur pied tres rapidement. Ca se contourne aussi comme problème, mais ca prend de l'argent.
_________________
Mangez du poulet ! |
|
| Back to top |
|
|
geekounet
Bodhisattva
Joined: 11 Oct 2004
Posts: 3772
Location: Wellington, Aotearoa
|
| Posted: Sat May 20, 2006 3:12 pm Post subject: |
|
|
Je ne travaille pas encore, j'en suis encore au études, mais je plussoie PabOu. 
Et pour argumenter, j'ajoute que dans l'entreprise où bosse mon papa ^^, ils font tourner une vingtaine de serveur sous Gentoo avec 3-4 machines de tests, et ça se gère très bien.  |
|
| Back to top |
|
|
cuicui
Apprentice
Joined: 17 Dec 2004
Posts: 208
|
| Posted: Sat May 20, 2006 3:34 pm Post subject: |
|
|
| PabOu wrote: | | cuicui wrote: | | si j'ai le choix entre passer plusieurs heures par semaine à mettre à jour mes serveurs (gentoo) et passer plusieurs minutes (Debian) pour un résultat final identique, je vais évidemment prendre la méthode qui me permet de travailler le plus efficacement. |
Il va falloir que tu m'expliques ou tu trouves une différence pareille pour mettre à jour des services. Et seulement "plusieurs minutes", ca me semble vraiment du travail baclé... |
Disons que je n'ai pas le choix... Si j'avais que ça a faire, je passerai peut-être mes journées à faire des tests de mises à jour. Seulement en plus des serveurs je suis tout seul pour administrer 260 postes clients sous Windows 2000/XP. Donc quand il y a une mise à jour, je l'applique. Il n'y a pas tous les jours des mises à jour d'Apache / Squid / SaMBa donc à l'échelle d'une semaine le temps d'admin est tout a fait gérable.
Si la mise à jour pose un problème il me faudra quoi? Quelques dizaines de secondes pour remettre l'ancienne version (le temps de me connecter au serveur, d'arrêter le service, de supprimer un lien symbolique, de créer un nouveau lien symbolique et de redémarrer le service).
Je suis tout à fait d'accord sur le fait qu'il faut toujours tester les mises à jour avant de les mettre en production, mais le schéma serveur de test / serveur de pré-prod / serveur de prod ne peut pas s'appliquer dans mon cas. J'ai ma méthode, elle a ses défauts, elle est ni safe, ni secure mais j'ai rarement eu de problèmes lors d'une mise à jour (la pluspart du temps c'est des erreurs de ma part, pas des erreurs intrinsèque à la nouvelle version), et si ça ne marche pas, tant pis on remet l'acienne et on verra plus tard |
|
| Back to top |
|
|
PabOu
Veteran
Joined: 11 Feb 2004
Posts: 1088
Location: Hélécine - Belgium
|
| Posted: Sat May 20, 2006 4:01 pm Post subject: |
|
|
| cuicui wrote: | | Je suis tout à fait d'accord sur le fait qu'il faut toujours tester les mises à jour avant de les mettre en production, mais le schéma serveur de test / serveur de pré-prod / serveur de prod ne peut pas s'appliquer dans mon cas. J'ai ma méthode, elle a ses défauts, elle est ni safe, ni secure mais j'ai rarement eu de problèmes lors d'une mise à jour (la pluspart du temps c'est des erreurs de ma part, pas des erreurs intrinsèque à la nouvelle version), et si ça ne marche pas, tant pis on remet l'acienne et on verra plus tard :) |
Je ne sais pas du tout ou tu travailles, ce que tu fais, et l'activité de ton entreprise (et des serveurs), mais j'imagine le cas suivant :
programme de génération de factures... on fait X factures par mois. La nouvelle version d'un des services sur un des serveurs à cette conséquence : 5% des factures sont érronées, aucune erreur dans les logs, à l'écran.. rien !
Mais encore faut-il voir les erreurs ! (refaire les calculs à la main pour vérifier et tout ca).
Les utilisateurs du service se disent que tout est OK, ils ne savent pas que toi tu as fait la mise à jour, et pour eux, il n'y a pas de raison de se dire qu'il y a un problème.
Lorsqu'un client recevra sa facture et fera un peu attention lui aussi (et ca peut prendre des semaines, le temps de générer/envoyer et puis de l'autre coté de classer/analyser) et vous fera part du problème.. vous allez devoir trouver l'origine du problème.
Et puis quoi ? si vous trouvez le programme en cause, il vous suffira de retourner à la précédente version ?
Et si ce n'est pas possible (parceque certains trucs ont changé entre temps) ?
_________________
Mangez du poulet ! |
|
| Back to top |
|
|
cuicui
Apprentice
Joined: 17 Dec 2004
Posts: 208
|
| Posted: Sat May 20, 2006 4:38 pm Post subject: |
|
|
| PabOu wrote: | Je ne sais pas du tout ou tu travailles, ce que tu fais, et l'activité de ton entreprise (et des serveurs), mais j'imagine le cas suivant :
programme de génération de factures... on fait X factures par mois. La nouvelle version d'un des services sur un des serveurs à cette conséquence : 5% des factures sont érronées, aucune erreur dans les logs, à l'écran.. rien !
Mais encore faut-il voir les erreurs ! (refaire les calculs à la main pour vérifier et tout ca).
Les utilisateurs du service se disent que tout est OK, ils ne savent pas que toi tu as fait la mise à jour, et pour eux, il n'y a pas de raison de se dire qu'il y a un problème.
Lorsqu'un client recevra sa facture et fera un peu attention lui aussi (et ca peut prendre des semaines, le temps de générer/envoyer et puis de l'autre coté de classer/analyser) et vous fera part du problème.. vous allez devoir trouver l'origine du problème.
Et puis quoi ? si vous trouvez le programme en cause, il vous suffira de retourner à la précédente version ?
Et si ce n'est pas possible (parceque certains trucs ont changé entre temps) ? |
On s'éloigne un peu du débat, mais je ne suis pas kamikaze non plus ;) Nous avons un gros serveur de base de données sous Tru64 dont toutes les mises à jour sont validées en amont. Les versions du système, le hardware, etc. doit être strictement conforme aux recommandations.
Les serveurs Debian dont je m'occupe n'ont rien à voir avec cette énorme (et très critique) application, ce sont des services "périphériques" à disposition des utilisateurs et/ou qui me permettent de gérer le parc informatique. C'est pour ça que je me permet de faire des maj un peu cavalières: il n'y a qu'un seul serveur véritablement public et ce n'est qu'un simple connecteur :)
Evidemment si les autres serveurs ont un problème ça a une incidence pour les utilisateurs, mais c'est de l'ordre du "plus rien marche" rien à voir avec un scénario de réaction en chaîne que tu évoquais, c'est des choses simples (et pour cette raison, je pourrais tout à fait les mettres sous Gentoo). Si j'administrais un serveur de messagerie avec plusieurs centaines de compte, là effectivement je m'amuserais pas à faire des maj à chaud comme je le fais maintenant, tout simplement parce que la messagerie est quelque chose de beaucoup plus critique (c'est ce que j'aime aussi dans mon boulot, je m'occupe de trucs pas trop chiants à administrer). |
|
| Back to top |
|
|
PabOu
Veteran
Joined: 11 Feb 2004
Posts: 1088
Location: Hélécine - Belgium
|
| Posted: Sat May 20, 2006 7:31 pm Post subject: |
|
|
Mais dans tout ca, je ne suis pas convaincu que gentoo est plus difficile/chiant à entretenir qu'une debian (ou autre). Ou alors c'est simplement une question de goûts, et la réponse au vote est non valide.
_________________
Mangez du poulet ! |
|
| Back to top |
|
|
nico_calais
l33t
Joined: 09 Jun 2005
Posts: 628
Location: Saint Julien en Genevois
|
| Posted: Sat May 20, 2006 8:29 pm Post subject: |
|
|
| PabOu wrote: | | Mais dans tout ca, je ne suis pas convaincu que gentoo est plus difficile/chiant à entretenir qu'une debian (ou autre). Ou alors c'est simplement une question de goûts, et la réponse au vote est non valide. |
C'est un peu comme windows et linux. Chacun trouvera des arguments pour chaque O/S. Y en a qui vont preferrer dépenser de la tune pour windows 2003 Server tout simplement parce qu'ils ont baigné dans windows depuis toujours. Ils sont en terrain connu, ils perdent moins de temps, sont plus productifs.
C'est pareil pour une personne utilisant red-hat ou debian depuis un moment. Cette personne maitrise sa distribution. Pourquoi desirerait elle changer une equipe qui gagne ? Elle a ses habitudes, sa routine, etc.
Je prend l'exemple d'un pote qui utilise Unbutu/Debian parce qu'ils utilisaient Debian dans son université.
Quand j'etais à l'IUT, je suis resté sur Aurox/Fedora parce qu'on utilisait Red-Hat.
Si pendant vos etudes ou pendant votre parcours professionel, vous êtes amener à utiliser Gentoo regulièrement, vous risquez de préferrer cet O/S à d'autres si on vous donne le choix.
Chaque distrib a ses contraintes et ses avantages. Les contraintes, on fait avec. Les avantages, on les exploitent.
_________________
"Unix IS user friendly... It's just selective about who its friends are." Tollef Fog Heen tollef@add.no |
|
| Back to top |
|
|
anigel
Bodhisattva
Joined: 14 Apr 2003
Posts: 1894
Location: Un petit bled pas loin de Limoges ;-)
|
| Posted: Sun May 21, 2006 10:09 am Post subject: |
|
|
Débat enflammé en tous cas ! Ca fait plaisir. Nous nous interrogions ces derniers temps sur l'opportunité de continuer ces débats, les derniers n'ayant pas suscité un gros enthousiasme (le troll n'est peut-être pas domptable  ). Peut-être avions-nous mal choisi les sujets, tout simplement ?
Bref, pour en revenir au sujet du jour, je crois qu'on touche dans les derniers posts à ce qui fait la valeur du débat : bien différencier les problèmes, et les solutions à y apporter.
Gentoo est-il adapté au monde professionnel ? Personnellement, je ne peux que répondre "oui". Gentoo peut-elle concurrencer Debian (ou une autre distrib pré-compilée) ? Oui, sans aucun doute ! Est-ce toujours justifié ? Pas forcément !
Je gère depuis 3 ans maintenant 2 types de serveurs uniquement : Debian, et Gentoo.Le premier est un serveur hyper-statique (des besoins clairement définis au départ : DNS / DHCP / e-mail / serveur web). Autrement dit, des logiciels dont les nouvelles versions sont plutôt rares. Dans ce cas, Debian convient parfaitement. Une fois installée, et configurée, la machine ne me prend plus beaucoup de temps dans l'année. Les seules mises à jour que j'ai à y faire sont des updates de sécurité, et les fichiers de conf ne changent pas, puisque nous restons sur les mêmes versions de softs.
Il n'y a eu qu'un cas où j'ai été ennuyé avec cette architecture : lorsque l'on m'a demandé de mettre en place un CMS : Plone. Là, nous étions encore à l'époque de la woody, et il a fallu installer zope. Pour cela, il fallait faire des updates de couches très basses du système (libc). Lesquelles engendraient des tonnes de dépendances... Après avoir fait un test rapide sur une machine miroir montée en vitesse, je me suis rendu compte que tout ça était très, très bancal... Je suis donc passé sur Debian testing, qui allait devenir peu de temps après la nouvelle Debian "stable". Ca s'est bien passé, mais je crois que l'on touchait là aux limites du système de release tel que le connaissent les distribs classiques, et dont Debian souffre particulièrement : faire une release impose de "figer" le système à un instant T.
C'est là que Gentoo intervient. Mes 2 autres serveurs sont des machines nettement plus "mouvantes". L'un d'eux héberge les comptes de près de 2500 étudiants, et l'autre est un gros serveur de calcul sur lequel je dois avoir en permanence des versions de soft récentes. Je travaille dans un labo de recherche, et on me demande parfois de faire des updates de softs qui ont quelques semaines seulement, afin de faire profiter les étudiants des dernières innovations. Gentoo me permet cela !
Mieux : toutes les machines "clientes" de mon parc tournent sous Gentoo. Les mises à jour / installation, se font à distance, via un système totalement centralisé que je développe. Ce système permet actuellement :
- des updates de softs, par utilisation de binaires précompilés sur une machine témoin, ou par compilation directe sur l'hôte.
- des updates du repository portage.
- de modifier les fichiers de conf (seulement de portage pour le moment) à la volée.
Côté environnement utilisateur, j'ai mis en place un système qui me permet de modifier depuis le serveur les profils utilisateurs, de façon extensive.
Les avantages d'avoir choisi cette distrib sont multiples : tout d'abord, ayant un parc très hétérogène (du duron 600 / 128 Mo au P4 3,2 Ghz / 1 Go), j'ai pu me confectionner mes propres versions de logiciels. Un bon exemple : emacs. La version livrée dans toute distrib à paquet est linkée sur gtk. lancer emacs = 40 Mo de RAM partis. Ma version tourne avec motif, et occupe 8 Mo, pour des fonctionnalités strictement équivalentes. Sur les duron, la différence est énorme : on passe d'un système lourd et pénible, à un système rapide et réactif. Bilan de l'opération la 1ère année de mise en service : cette salle, jusque-là désertée par les étudiants, s'est re-remplie en quelques jours.
Il faut bien sûr tempérer cette vision des choses : le monde de l'éducation et la recherche a des besoins très spécifique, et gentoo y répond parfaitement. Mais je crois sincèrement qu'elle ne vaut pas moins qu'une autre distrib. Les temps de mises à jour ne sont pas supérieurs à celle d'une Debian, quoi qu'on en dise (qui regarde défiler les lignes de compilation ?), et la souplesse induite par portage vaut largement l'effort. La mise à jour des fichiers de conf n'est pas plus difficile dans un cas que dans l'autre :
- changement de version mineure, correction de bug
 fichier de conf inchangé, il suffit les 3/4 du temps de zapper le nouveau
- changement de version majeure c'est une opération lourde, qu'on ne fait pas un lundi matin au pied levé ; quelle que soit la distrib, on ne fait pas l'économie de l'examen complet des incidences d'un tel changement.
Gentoo en production : pour moi, approuvé !
_________________
Il y a 10 sortes d'individus en ce bas-monde : ceux qui causent binaire, et les autres. |
|
| Back to top |
|
|
yuk159
Veteran
Joined: 18 Apr 2003
Posts: 1802
Location: noumea ,nouvelle-caledonie
|
| Posted: Thu May 25, 2006 8:27 am Post subject: |
|
|
Bin je sais pas vous, mais moi j'aurai tendance à penser que ce sujet et clos depuis la réponse d'anigel
_________________
The box said: "Requires Windows 98/2000/XP/NT, or better."
So, I installed LINUX!
Instagram |
|
| Back to top |
|
|
anigel
Bodhisattva
Joined: 14 Apr 2003
Posts: 1894
Location: Un petit bled pas loin de Limoges ;-)
|
| Posted: Thu May 25, 2006 5:52 pm Post subject: |
|
|
Histoire d'essayer de relancer le débat, avec une petite mésaventure qui m'est arrivée voilà quelques jours... en voici le résumé, sur bgo .
_________________
Il y a 10 sortes d'individus en ce bas-monde : ceux qui causent binaire, et les autres. |
|
| Back to top |
|
|
dapsaille
Advocate
Joined: 02 Aug 2004
Posts: 2366
Location: Paris
|
| Posted: Thu May 25, 2006 6:33 pm Post subject: |
|
|
Question bete et méchante à peu près hors sujet ..
Ou sont stockés ces threads sur le forum ? |
|
| Back to top |
|
|
kopp
Advocate
Joined: 09 Apr 2004
Posts: 2885
Location: Grenoble, France
|
| Posted: Thu May 25, 2006 6:38 pm Post subject: |
|
|
| Eh bien, une fois qu'il ne sont plus sticky, ils reprennent leur place normal dans l'ordre chronologique, comme un thread normal. |
|
| Back to top |
|
|
anigel
Bodhisattva
Joined: 14 Apr 2003
Posts: 1894
Location: Un petit bled pas loin de Limoges ;-)
|
| Posted: Thu May 25, 2006 7:50 pm Post subject: |
|
|
| kopp wrote: | | Eh bien, une fois qu'il ne sont plus sticky, ils reprennent leur place normal dans l'ordre chronologique, comme un thread normal. |
Exactement ! Et, en prime, nous tenons même un annuaire à jour, à la fin du post principal de la boîte à idées.
_________________
Il y a 10 sortes d'individus en ce bas-monde : ceux qui causent binaire, et les autres. |
|
| Back to top |
|
|
Oupsman
Veteran
Joined: 19 Jul 2004
Posts: 1042
|
| Posted: Thu May 25, 2006 8:37 pm Post subject: |
|
|
| anigel wrote: | | Histoire d'essayer de relancer le débat, avec une petite mésaventure qui m'est arrivée voilà quelques jours... en voici le résumé, sur bgo . |
Oui je sais c'est pas drôle, c'est même assez bizarre d'ailleurs parce que ma crontab moi ressemble à çà :
| Code: |
35 1 * * * emerge sync | mailx -s "Synchro portage" oupsman@oupsman.no-ip.org 2>&1
52 1 * * * emerge world -pv | mailx -s "Paquets a mettre a jour" oupsman@oupsman.no-ip.org 2>&1
0 0 * * * /opt/f-prot/tools/check-updates.pl | mailx -s "Mise a jour F-PROT" oupsman@oupsman.no-ip.org 2>&1
30 0 * * * time f-prot /home/partage | mailx -s "Scan Partage WINDOWS" oupsman@oupsman.no-ip.org 2>&1
28 * * * * freshclam >> /var/log/update_clamav.log 2>&1
#Redémarrage journalier de courier-authlib
0 6 * * * /etc/init.d/courier-authlib restart | mailx -s "Redemarrage courier-authlib" 2>&1
|
et moi aussi j'utiliser vixie-cron :
| Code: |
These are the packages that would be merged, in order:
Calculating dependencies... done!
[ebuild R ] sys-process/vixie-cron-4.1-r8 USE="pam -debug" 57 kB
Total size of downloads: 57 kB
|
Par contre, si je puis me permettre, il faut toujours rediriger la sortie d'une commande lancée via cron vers un fichier de logs/un mail car sinon tu peux te gratter la tête très longtemps en cherchant pourquoi ca ne marche pas.
_________________
--
L'idéal de nouveauté semble avoir remplacé l'idéal de progrès. C'est bien triste.
----
Unix philosophy: "Do one thing and do it well."
systemd: "Try to do everything and do it wrong." |
|
| Back to top |
|
|
nico_calais
l33t
Joined: 09 Jun 2005
Posts: 628
Location: Saint Julien en Genevois
|
| Posted: Fri May 26, 2006 12:09 am Post subject: |
|
|
| anigel wrote: | | Histoire d'essayer de relancer le débat, avec une petite mésaventure qui m'est arrivée voilà quelques jours... en voici le résumé, sur bgo . |
C'est bizarre. J'utilise vixie-cron pour faire un emerge --sync tous les jours et j'ai pas eu ce problème. Et je confirme que ca le fait bien, le ventilo du PC devient un peu plus bruillant et me reveille tous les matins 
_________________
"Unix IS user friendly... It's just selective about who its friends are." Tollef Fog Heen tollef@add.no |
|
| Back to top |
|
|
Oupsman
Veteran
Joined: 19 Jul 2004
Posts: 1042
|
| Posted: Fri May 26, 2006 5:55 am Post subject: |
|
|
| nico_calais wrote: |
C'est bizarre. J'utilise vixie-cron pour faire un emerge --sync tous les jours et j'ai pas eu ce problème. Et je confirme que ca le fait bien, le ventilo du PC devient un peu plus bruillant et me reveille tous les matins |
Ca c'est de la geekerie pure
_________________
--
L'idéal de nouveauté semble avoir remplacé l'idéal de progrès. C'est bien triste.
----
Unix philosophy: "Do one thing and do it well."
systemd: "Try to do everything and do it wrong." |
|
| Back to top |
|
|
anigel
Bodhisattva
Joined: 14 Apr 2003
Posts: 1894
Location: Un petit bled pas loin de Limoges ;-)
|
| Posted: Fri May 26, 2006 8:52 am Post subject: |
|
|
| Oupsman wrote: | | Par contre, si je puis me permettre, il faut toujours rediriger la sortie d'une commande lancée via cron vers un fichier de logs/un mail car sinon tu peux te gratter la tête très longtemps en cherchant pourquoi ca ne marche pas. |
Effectivement, c'est aussi ce que je fais. Mais pour ne pas encombrer le bugzilla, je n'ai pas recopié l'intégralité de mon fichier, qui comporte presque 70 lignes au total .
En fait, il semble que le problème se produise plus spécifiquement lorsque emerge est appelé par un script, ce qui est mon cas (je fais, dans un même script bash, la synchro de portage, un examen de la liste des paquets à mettre à jour, une liste des paquets affectés par un avis de sécurité, et aussi un lien vers les GLSA correspondantes, le tout étant envoyé par mail par vixie quand il a fini). Mais, malheureusement, si vixie est relativement verbeux sur les tâches qu'il exécute correctement, il est beaucoup plus discret quand ça déconne...
_________________
Il y a 10 sortes d'individus en ce bas-monde : ceux qui causent binaire, et les autres. |
|
| Back to top |
|
|
sireyessire
Advocate
Joined: 20 Mar 2003
Posts: 2991
Location: back in Paris, France
|
| Posted: Fri May 26, 2006 9:12 am Post subject: |
|
|
| anigel wrote: | | Oupsman wrote: | | Par contre, si je puis me permettre, il faut toujours rediriger la sortie d'une commande lancée via cron vers un fichier de logs/un mail car sinon tu peux te gratter la tête très longtemps en cherchant pourquoi ca ne marche pas. |
Effectivement, c'est aussi ce que je fais. Mais pour ne pas encombrer le bugzilla, je n'ai pas recopié l'intégralité de mon fichier, qui comporte presque 70 lignes au total .
En fait, il semble que le problème se produise plus spécifiquement lorsque emerge est appelé par un script, ce qui est mon cas (je fais, dans un même script bash, la synchro de portage, un examen de la liste des paquets à mettre à jour, une liste des paquets affectés par un avis de sécurité, et aussi un lien vers les GLSA correspondantes, le tout étant envoyé par mail par vixie quand il a fini). Mais, malheureusement, si vixie est relativement verbeux sur les tâches qu'il exécute correctement, il est beaucoup plus discret quand ça déconne... |
pure curiosité, j'installais vixie-cron à un moment, mais je suis passé à fcron depuis quelques années.
C'est quoi les principales différences entre tous ces crons? vixie est vraiment mieux?
le fait est qu'avant par fainéantise je prenais vixie parce qu'il y avait une commande de moins à taper
_________________
I never think of the future. It comes soon enough.
Albert Einstein
Try simpler first
Shockley |
|
| Back to top |
|
|
nico_calais
l33t
Joined: 09 Jun 2005
Posts: 628
Location: Saint Julien en Genevois
|
| Posted: Fri May 26, 2006 10:17 am Post subject: |
|
|
| Oupsman wrote: | | nico_calais wrote: |
C'est bizarre. J'utilise vixie-cron pour faire un emerge --sync tous les jours et j'ai pas eu ce problème. Et je confirme que ca le fait bien, le ventilo du PC devient un peu plus bruillant et me reveille tous les matins |
Ca c'est de la geekerie pure |
Mouarff
_________________
"Unix IS user friendly... It's just selective about who its friends are." Tollef Fog Heen tollef@add.no |
|
| Back to top |
|
|
zigz4g
n00b
Joined: 12 Aug 2005
Posts: 37
|
| Posted: Fri May 26, 2006 12:54 pm Post subject: |
|
|
Salut, je rajoute ma petite expérience.
J'en suis a 6 machines en entreprise. 2 machines serveurs et 4 machines clientes pour du développement PHP5.
Les petits problèmes que je rencontre sont :
- Pour les serveurs, je ne veux pas toujours mettre a jour tous les dimanches matin par exemple. Linux est stable et me rend les services que je lui demande. De temps en temps je fais un petit emerge system.
Le problème vient surtout du fait que un des serveurs fait serveur de sync pour emerge de toutes les autres machines. J'ai par exemple plus la possibilite de mettre a jour php4 avec ces USE flags d'il y a un an maintenant.
- Pour les machines clientes, je fais de temps en temps le tour en ssh pour mettre a jour et faire l'admin. Le problème les machines sont toutes un peut différentes points de vue matériel. Il faut donc faire attention aux configs.
En générale je testes les mise a jour sur ma machine en premier pour les répercuter sur les autres machines.
Pour la question de mettre gentoo en production dans les boites, il faut forcément un service qui s'occupe des mises a jours et corriger les problèmes. Mais la tout dépends de la qualité de service que l'on veut, non ?
Pour nos serveurs de productions qui seront dédié a de l'hébergement web, ce sera soit du Red Hat, soit du Debian. Pourquoi ? Alors que je mets du Gentoo ? Tout simplement que pour les clients il faut pouvoir fournir une garantie et un service support qui n'existe pas réellement chez Gentoo. Sachant que c'est pas nous qui feront l'hébergement mais une autre boite. Il est dur de demander une nouvelle distrib qui n'est pas maitrisée.
Pour le coté perso, y'a pas photo, gentoo
_________________
--
NoSig |
|
| Back to top |
|
|
anigel
Bodhisattva
Joined: 14 Apr 2003
Posts: 1894
Location: Un petit bled pas loin de Limoges ;-)
|
| Posted: Fri May 26, 2006 9:04 pm Post subject: |
|
|
| sireyessire wrote: | pure curiosité, j'installais vixie-cron à un moment, mais je suis passé à fcron depuis quelques années.
C'est quoi les principales différences entre tous ces crons? vixie est vraiment mieux?
le fait est qu'avant par fainéantise je prenais vixie parce qu'il y avait une commande de moins à taper |
Ils ont chacun leurs avantages et leurs inconvénients en fait. vixie-cron est le plus complet, le plus porté. Il supporte une system crontab par exemple, alors que les deux autres, non.
fcron permet une gestion cron sur des machines qui ne tournent pas en permanence (il va aller vérifier si on a "raté" des tâches).
dcron est le plus simple des 3 (c'est celui que j'utilisais jusqu'à présent): pas de system crontab, pas de gestion des tâches manquées, mais il marche, tout simplement.
Dans le cas des 2 derniers, il faut aussi noter une gestion différente de l'accès à la crontab pour les utilisateurs.
_________________
Il y a 10 sortes d'individus en ce bas-monde : ceux qui causent binaire, et les autres. |
|
| Back to top |
|
|
sireyessire
Advocate
Joined: 20 Mar 2003
Posts: 2991
Location: back in Paris, France
|
| Posted: Sat May 27, 2006 7:55 am Post subject: |
|
|
| anigel wrote: | | sireyessire wrote: | pure curiosité, j'installais vixie-cron à un moment, mais je suis passé à fcron depuis quelques années.
C'est quoi les principales différences entre tous ces crons? vixie est vraiment mieux?
le fait est qu'avant par fainéantise je prenais vixie parce qu'il y avait une commande de moins à taper |
Ils ont chacun leurs avantages et leurs inconvénients en fait. vixie-cron est le plus complet, le plus porté. Il supporte une system crontab par exemple, alors que les deux autres, non.
fcron permet une gestion cron sur des machines qui ne tournent pas en permanence (il va aller vérifier si on a "raté" des tâches).
dcron est le plus simple des 3 (c'est celui que j'utilisais jusqu'à présent): pas de system crontab, pas de gestion des tâches manquées, mais il marche, tout simplement.
Dans le cas des 2 derniers, il faut aussi noter une gestion différente de l'accès à la crontab pour les utilisateurs. |
oki merci pour ces précisions
_________________
I never think of the future. It comes soon enough.
Albert Einstein
Try simpler first
Shockley |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
French
