je viens d'arriver dans une boite où la plupart
des serveurs sont installés en redhat Entr (4 ou 5).
Perso, j'avais plutôt l'expérience debian/ubuntu pour les serveurs.
Malheureusement, la maitrise de l'administration est catastrophique:
-aucune mise à jour des systèmes, gravé dans le marbre à l'install cd
si ça foire ou j'ai oublié un paquet je réinstalle tout si si...
(rpm forever)
-donc aucune maitrise de up2date ou yum en interne, puisqu'ils
n'utilisent jamais...
-installation de nouveaux paquets à partir de source tar.gz
Dans le cadre, de l'évolution, j'aimerais trouvé sérieusement des liens
récent sur des articles qui font la comparaison entre les distrib
linux pour le monde de l'entreprise. Genre avantages, inconvénients.
Pour l'instant, le vrai point bloquant sur la debian, c'est pas de
support commercial. Visiblement cela a fait parti du choix redhat,
pour avoir un support éditeur.
Autre point éfrayant, pour pouvoir appliquer les maj paquets chez redhat
il faut enregistrer son système sur le RHN (200$ la bête ).
De plus, je viens de toucher à une machine pour la mettre à jour, mais
je ne suis même pas certain que l'updater restart les services qui ont
été upgradés...
Y'a encore des gens qui tourne avec du redhat dans le monde de l'entreprise?
> Je mettrais un sacré bémol pour Redhat qui à mon avis est la dernière des distributions à mettre en entreprise. Effectivement, il y a des tas de machins labellisés pour distribution Redhat, mais ce sont des distributions sont les mises à jour sont scabreuses. Personnellement, je m'en tape depuis le tout début de redhat et ce n'est pas allé en s'arrangeant. Mettre un serveur debian à jour d'une stable vers une stable, ça se fait les doigts dans le nez. Mettre à jour une redhat vers une redhat, c'est un sport de haute voltige avec au passage des serveurs qui explosent en vol. J'ai connu, et depuis, je n'en installe plus une seule.
Tu pourrais approfondir le dernier passage, ça m'intéresse beaucoup. L'upgrade se faisait dans le cadre d'un support RH à coté?
Merci
> Je mettrais un sacré bémol pour Redhat qui à mon avis est la
dernière des distributions à mettre en entreprise. Effectivement, il y a
des tas de machins labellisés pour distribution Redhat, mais ce sont des
distributions sont les mises à jour sont scabreuses. Personnellement, je
m'en tape depuis le tout début de redhat et ce n'est pas allé en
s'arrangeant. Mettre un serveur debian à jour d'une stable vers une
stable, ça se fait les doigts dans le nez. Mettre à jour une redhat vers
une redhat, c'est un sport de haute voltige avec au passage des serveurs
qui explosent en vol. J'ai connu, et depuis, je n'en installe plus une
seule.
Tu pourrais approfondir le dernier passage, ça m'intéresse beaucoup.
L'upgrade se faisait dans le cadre d'un support RH à coté?
> Je mettrais un sacré bémol pour Redhat qui à mon avis est la dernière des distributions à mettre en entreprise. Effectivement, il y a des tas de machins labellisés pour distribution Redhat, mais ce sont des distributions sont les mises à jour sont scabreuses. Personnellement, je m'en tape depuis le tout début de redhat et ce n'est pas allé en s'arrangeant. Mettre un serveur debian à jour d'une stable vers une stable, ça se fait les doigts dans le nez. Mettre à jour une redhat vers une redhat, c'est un sport de haute voltige avec au passage des serveurs qui explosent en vol. J'ai connu, et depuis, je n'en installe plus une seule.
Tu pourrais approfondir le dernier passage, ça m'intéresse beaucoup. L'upgrade se faisait dans le cadre d'un support RH à coté?
Merci
Fabien LE LEZ
On Sat, 04 Apr 2009 16:12:20 +0200, chksum :
Pour l'instant, le vrai point bloquant sur la debian, c'est pas de support commercial.
Je comprends ta douleur. Le "support commercial", c'est généralement un truc pour rassurer le patron qui n'y connaît rien, et ça ne sert rigoureusement à rien en pratique : en cas de panne, tu te démerdes. Au pire, tu peux engueuler les gens du support pour te défouler, mais ça s'arrête là.
N'existe-t-il pas un prestataire qui peut fournir cette illusion pour Debian ?
On Sat, 04 Apr 2009 16:12:20 +0200, chksum <utilisateur@exemple.fr>:
Pour l'instant, le vrai point bloquant sur la debian, c'est pas de
support commercial.
Je comprends ta douleur. Le "support commercial", c'est généralement
un truc pour rassurer le patron qui n'y connaît rien, et ça ne sert
rigoureusement à rien en pratique : en cas de panne, tu te démerdes.
Au pire, tu peux engueuler les gens du support pour te défouler, mais
ça s'arrête là.
N'existe-t-il pas un prestataire qui peut fournir cette illusion pour
Debian ?
Pour l'instant, le vrai point bloquant sur la debian, c'est pas de support commercial.
Je comprends ta douleur. Le "support commercial", c'est généralement un truc pour rassurer le patron qui n'y connaît rien, et ça ne sert rigoureusement à rien en pratique : en cas de panne, tu te démerdes. Au pire, tu peux engueuler les gens du support pour te défouler, mais ça s'arrête là.
N'existe-t-il pas un prestataire qui peut fournir cette illusion pour Debian ?
Netsurfeur
chksum a écrit :
Bonjour,
Pour répondre à votre dernière question, il y a énormément de gens qui utilisent RedHat en entreprise. En tant que prestataire, j'essaie de proposer Debian chaque fois que c'est possible mais pour des raisons d'homogénéité certaines entreprises imposent RedHat car c'est la seule distribution pour laquelle toutes leurs applications critiques sont supportées (ex: SGBD Oracle).
A ce que je viens de voir, on dira que c'est pour une utilisation standard (comprendre des applications standards à ce que j'ai vu pour l'instant, aucun logiciel commercial en vue...)
Si par standard vous entendez inclus dans la distribution, le choix RedHat a assez peu d'intérêt. Debian est aussi réactif que RedHat pour diffuser les mises à jour. Le seul intérêt de RedHat est de disposer d'un support "contractuel", mais il faut accepter de jouer le jeu RedHat : payer le support et maintenir les machines à jour à partir de leurs dépôts.
La stratégie est plutôt : - machine critique = RedHat + contrat de mise à jour RHN - machine non critique (développement, test,...) = CentOS.
C'est marrant, mon premier cas qu'on m'a mis dans les mains. -> Mets à jour c'est machines critiques STP Gloups!
Je répète, dans votre cas, il est aberrant d'imposer RedHat et de ne pas en accepter les conséquences (mise sous contrat RHN de tous les serveurs critiques). Pour avoir l'heure, on n'est pas obligé de choisir une Rolex; surtout quand on en a pas les moyens (d'autres le font aussi bien pour beaucoup moins cher ! ;))
D'un point de vue pratique, nous faisons régulièrement des mises à jour de serveurs critiques dans de *très* anciennes distributions. Généralement, nous commençons par cloner le serveur dans une machine virtuelle et validons la procédure de mise à jour avant de l'appliquer sur le serveur réel.
Dans le cas de votre entreprise, l'aberration est d'avoir choisi RedHat pour le support et de ne pas souscrire aux contrats RHN. Quel support comptez-vous avoir en cas de problème ? Comment allez-vous obtenir les correctifs ? Le temps passé à installer les RPM un par un (ou compiler des sources) plutôt qu'utiliser yum ou up2date ne vaut-il pas plus de 200$/an ?
si mais encore faut-il le maitriser, ce qui n'est pas le cas actuellement... Le support RH fait du botage en touche pour l'instant sur des machines critiques non upgradés. trop la classe.
Si vous choisissez RedHat, vous devez accepter leurs règles de fonctionnement. La durée de support de leurs distributions est assez longue (la durée de vie d'une version Enterprise est de 7 ans); à vous de vous organiser pour que vos serveurs critiques puissent être supportés.
Si la volonté est d'utiliser une distribution équivalente à RedHat sans payer de contrat RHN, le mieux serait d'utiliser CentOS.
De toute façon, RedHat et CentOS sont moins riches que Debian en terme de paquets supportés. Il vous faudra en plus utiliser des dépôts comme dag-rpm pour compléter l'offre RedHat/CentOS. Ces dépôts sont accessibles via yum. C'est quand même plus propre que de recompiler à partir des sources (à moins que vous ayez un processus robuste de compilation/test/déploiement pour ces sources; mais à la lumière de votre description de la situation, j'ai des doutes...).
Mon idée était plutôt de partir sur du ubuntu serveur/canonical pour le support, mais de ce que ce coté là, Pas grand chose à se mettre sous la dent.
Si toutes vos applications font partie de la distribution Ubuntu Server et que vous voulez des engagements contractuels, la solution Ubuntu/Canonical est peut être une bonne alternative. Ceci dit, je n'ai aucune expérience du support Canonical.
Cordialement, -- Netsurfeur
chksum a écrit :
Bonjour,
Pour répondre à votre dernière question, il y a énormément de gens qui
utilisent RedHat en entreprise. En tant que prestataire, j'essaie de
proposer Debian chaque fois que c'est possible mais pour des raisons
d'homogénéité certaines entreprises imposent RedHat car c'est la seule
distribution pour laquelle toutes leurs applications critiques sont
supportées (ex: SGBD Oracle).
A ce que je viens de voir, on dira que c'est pour une utilisation
standard (comprendre des applications standards à ce que j'ai vu
pour l'instant, aucun logiciel commercial en vue...)
Si par standard vous entendez inclus dans la distribution, le choix
RedHat a assez peu d'intérêt. Debian est aussi réactif que RedHat pour
diffuser les mises à jour.
Le seul intérêt de RedHat est de disposer d'un support "contractuel",
mais il faut accepter de jouer le jeu RedHat : payer le support et
maintenir les machines à jour à partir de leurs dépôts.
La stratégie est plutôt :
- machine critique = RedHat + contrat de mise à jour RHN
- machine non critique (développement, test,...) = CentOS.
C'est marrant, mon premier cas qu'on m'a mis dans les mains.
-> Mets à jour c'est machines critiques STP Gloups!
Je répète, dans votre cas, il est aberrant d'imposer RedHat et de ne pas
en accepter les conséquences (mise sous contrat RHN de tous les serveurs
critiques).
Pour avoir l'heure, on n'est pas obligé de choisir une Rolex; surtout
quand on en a pas les moyens (d'autres le font aussi bien pour beaucoup
moins cher ! ;))
D'un point de vue pratique, nous faisons régulièrement des mises à jour
de serveurs critiques dans de *très* anciennes distributions.
Généralement, nous commençons par cloner le serveur dans une machine
virtuelle et validons la procédure de mise à jour avant de l'appliquer
sur le serveur réel.
Dans le cas de votre entreprise, l'aberration est d'avoir choisi
RedHat pour le support et de ne pas souscrire aux contrats RHN.
Quel support comptez-vous avoir en cas de problème ?
Comment allez-vous obtenir les correctifs ?
Le temps passé à installer les RPM un par un (ou compiler des sources)
plutôt qu'utiliser yum ou up2date ne vaut-il pas plus de 200$/an ?
si mais encore faut-il le maitriser, ce qui n'est pas le cas
actuellement... Le support RH fait du botage en touche pour l'instant
sur des machines critiques non upgradés. trop la classe.
Si vous choisissez RedHat, vous devez accepter leurs règles de
fonctionnement. La durée de support de leurs distributions est assez
longue (la durée de vie d'une version Enterprise est de 7 ans); à vous
de vous organiser pour que vos serveurs critiques puissent être supportés.
Si la volonté est d'utiliser une distribution équivalente à RedHat
sans payer de contrat RHN, le mieux serait d'utiliser CentOS.
De toute façon, RedHat et CentOS sont moins riches que Debian en terme
de paquets supportés. Il vous faudra en plus utiliser des dépôts comme
dag-rpm pour compléter l'offre RedHat/CentOS. Ces dépôts sont
accessibles via yum. C'est quand même plus propre que de recompiler à
partir des sources (à moins que vous ayez un processus robuste de
compilation/test/déploiement pour ces sources; mais à la lumière de
votre description de la situation, j'ai des doutes...).
Mon idée était plutôt de partir sur du ubuntu serveur/canonical pour le
support, mais de ce que ce coté là, Pas grand chose à se mettre sous
la dent.
Si toutes vos applications font partie de la distribution Ubuntu Server
et que vous voulez des engagements contractuels, la solution
Ubuntu/Canonical est peut être une bonne alternative.
Ceci dit, je n'ai aucune expérience du support Canonical.
Pour répondre à votre dernière question, il y a énormément de gens qui utilisent RedHat en entreprise. En tant que prestataire, j'essaie de proposer Debian chaque fois que c'est possible mais pour des raisons d'homogénéité certaines entreprises imposent RedHat car c'est la seule distribution pour laquelle toutes leurs applications critiques sont supportées (ex: SGBD Oracle).
A ce que je viens de voir, on dira que c'est pour une utilisation standard (comprendre des applications standards à ce que j'ai vu pour l'instant, aucun logiciel commercial en vue...)
Si par standard vous entendez inclus dans la distribution, le choix RedHat a assez peu d'intérêt. Debian est aussi réactif que RedHat pour diffuser les mises à jour. Le seul intérêt de RedHat est de disposer d'un support "contractuel", mais il faut accepter de jouer le jeu RedHat : payer le support et maintenir les machines à jour à partir de leurs dépôts.
La stratégie est plutôt : - machine critique = RedHat + contrat de mise à jour RHN - machine non critique (développement, test,...) = CentOS.
C'est marrant, mon premier cas qu'on m'a mis dans les mains. -> Mets à jour c'est machines critiques STP Gloups!
Je répète, dans votre cas, il est aberrant d'imposer RedHat et de ne pas en accepter les conséquences (mise sous contrat RHN de tous les serveurs critiques). Pour avoir l'heure, on n'est pas obligé de choisir une Rolex; surtout quand on en a pas les moyens (d'autres le font aussi bien pour beaucoup moins cher ! ;))
D'un point de vue pratique, nous faisons régulièrement des mises à jour de serveurs critiques dans de *très* anciennes distributions. Généralement, nous commençons par cloner le serveur dans une machine virtuelle et validons la procédure de mise à jour avant de l'appliquer sur le serveur réel.
Dans le cas de votre entreprise, l'aberration est d'avoir choisi RedHat pour le support et de ne pas souscrire aux contrats RHN. Quel support comptez-vous avoir en cas de problème ? Comment allez-vous obtenir les correctifs ? Le temps passé à installer les RPM un par un (ou compiler des sources) plutôt qu'utiliser yum ou up2date ne vaut-il pas plus de 200$/an ?
si mais encore faut-il le maitriser, ce qui n'est pas le cas actuellement... Le support RH fait du botage en touche pour l'instant sur des machines critiques non upgradés. trop la classe.
Si vous choisissez RedHat, vous devez accepter leurs règles de fonctionnement. La durée de support de leurs distributions est assez longue (la durée de vie d'une version Enterprise est de 7 ans); à vous de vous organiser pour que vos serveurs critiques puissent être supportés.
Si la volonté est d'utiliser une distribution équivalente à RedHat sans payer de contrat RHN, le mieux serait d'utiliser CentOS.
De toute façon, RedHat et CentOS sont moins riches que Debian en terme de paquets supportés. Il vous faudra en plus utiliser des dépôts comme dag-rpm pour compléter l'offre RedHat/CentOS. Ces dépôts sont accessibles via yum. C'est quand même plus propre que de recompiler à partir des sources (à moins que vous ayez un processus robuste de compilation/test/déploiement pour ces sources; mais à la lumière de votre description de la situation, j'ai des doutes...).
Mon idée était plutôt de partir sur du ubuntu serveur/canonical pour le support, mais de ce que ce coté là, Pas grand chose à se mettre sous la dent.
Si toutes vos applications font partie de la distribution Ubuntu Server et que vous voulez des engagements contractuels, la solution Ubuntu/Canonical est peut être une bonne alternative. Ceci dit, je n'ai aucune expérience du support Canonical.
Cordialement, -- Netsurfeur
Erwan David
chksum écrivait :
Patrick Texier a écrit :
Le Sat, 04 Apr 2009 16:12:20 +0200, chksum a écrit :
Malheureusement, la maitrise de l'administration est catastrophique:
[...]
-installation de nouveaux paquets à partir de source tar.gz
Effectivement, le mieux c'est souvent d'aller chercher les patches ou le CVS.
Oui mais là, bonjour les coupures de services dans les cas d'upgrade. -> retrouver les options de compil de la version précédente. -> tester avant les maj -> limiter au *maximum* l'interruption de services.
Dans le cas de passage avec des paquets, je ne rencontre pas ces soucis là. (En tout cas pour l'instant, je ne l'ai jamais rencontré)
dans le pire des cas j'ai eu "attention vous devriez passer en postgresql 8.3, mais comme il y a des risques, voilà la procédure pour le faire. Ce qui m'a permis de faire la manip à un moment choisi par moi pour géner le moins possible les utilisateurs.
-- Le travail n'est pas une bonne chose. Si ça l'était, les riches l'auraient accaparé
chksum <utilisateur@exemple.fr> écrivait :
Patrick Texier a écrit :
Le Sat, 04 Apr 2009 16:12:20 +0200, chksum a écrit :
Malheureusement, la maitrise de l'administration est catastrophique:
[...]
-installation de nouveaux paquets à partir de source tar.gz
Effectivement, le mieux c'est souvent d'aller chercher les patches ou le
CVS.
Oui mais là, bonjour les coupures de services dans les cas d'upgrade.
-> retrouver les options de compil de la version précédente.
-> tester avant les maj
-> limiter au *maximum* l'interruption de services.
Dans le cas de passage avec des paquets, je ne rencontre pas ces soucis
là. (En tout cas pour l'instant, je ne l'ai jamais rencontré)
dans le pire des cas j'ai eu "attention vous devriez passer en
postgresql 8.3, mais comme il y a des risques, voilà la procédure pour
le faire. Ce qui m'a permis de faire la manip à un moment choisi par moi
pour géner le moins possible les utilisateurs.
--
Le travail n'est pas une bonne chose. Si ça l'était,
les riches l'auraient accaparé
Le Sat, 04 Apr 2009 16:12:20 +0200, chksum a écrit :
Malheureusement, la maitrise de l'administration est catastrophique:
[...]
-installation de nouveaux paquets à partir de source tar.gz
Effectivement, le mieux c'est souvent d'aller chercher les patches ou le CVS.
Oui mais là, bonjour les coupures de services dans les cas d'upgrade. -> retrouver les options de compil de la version précédente. -> tester avant les maj -> limiter au *maximum* l'interruption de services.
Dans le cas de passage avec des paquets, je ne rencontre pas ces soucis là. (En tout cas pour l'instant, je ne l'ai jamais rencontré)
dans le pire des cas j'ai eu "attention vous devriez passer en postgresql 8.3, mais comme il y a des risques, voilà la procédure pour le faire. Ce qui m'a permis de faire la manip à un moment choisi par moi pour géner le moins possible les utilisateurs.
-- Le travail n'est pas une bonne chose. Si ça l'était, les riches l'auraient accaparé
Thumain Th.
Le Sun, 05 Apr 2009 09:48:06 +0200, chksum a écrit:
Nous utilisons maintenant SUSE.
Pour avoir vu une suze entreprise, il n'y a pas longtemps. J'éviterais tant que possible, j'arrive toujours pas à me faire à YAST...
On s'y fait plutôt bien à la pratique.
-- TT
Le Sun, 05 Apr 2009 09:48:06 +0200, chksum <utilisateur@exemple.fr> a
écrit:
Nous utilisons maintenant SUSE.
Pour avoir vu une suze entreprise, il n'y a pas longtemps.
J'éviterais tant que possible, j'arrive toujours pas à me faire
à YAST...
Le Sun, 05 Apr 2009 09:48:06 +0200, chksum a écrit:
Nous utilisons maintenant SUSE.
Pour avoir vu une suze entreprise, il n'y a pas longtemps. J'éviterais tant que possible, j'arrive toujours pas à me faire à YAST...
On s'y fait plutôt bien à la pratique.
-- TT
chksum
Fabien LE LEZ a écrit :
On Sat, 04 Apr 2009 16:12:20 +0200, chksum :
Pour l'instant, le vrai point bloquant sur la debian, c'est pas de support commercial.
Je comprends ta douleur. Le "support commercial", c'est généralement un truc pour rassurer le patron qui n'y connaît rien, et ça ne sert rigoureusement à rien en pratique : en cas de panne, tu te démerdes. Au pire, tu peux engueuler les gens du support pour te défouler, mais ça s'arrête là.
N'existe-t-il pas un prestataire qui peut fournir cette illusion pour Debian ?
c'est pas possible, tu lis le fond de ma pensée!!
Je pense que "l'argument qui tue" est : on a le support de l'éditeur et pas une société tierce qui va se défaussé au premier soucis.
c'est pour ça que je pensais à ubuntu/canonical pour le coté admin friendly avec le support de l'éditeur.
Je vais affuter mes arguments et je vais aller voir du coté de canonical les prix et les services proposés.
Fabien LE LEZ a écrit :
On Sat, 04 Apr 2009 16:12:20 +0200, chksum <utilisateur@exemple.fr>:
Pour l'instant, le vrai point bloquant sur la debian, c'est pas de
support commercial.
Je comprends ta douleur. Le "support commercial", c'est généralement
un truc pour rassurer le patron qui n'y connaît rien, et ça ne sert
rigoureusement à rien en pratique : en cas de panne, tu te démerdes.
Au pire, tu peux engueuler les gens du support pour te défouler, mais
ça s'arrête là.
N'existe-t-il pas un prestataire qui peut fournir cette illusion pour
Debian ?
c'est pas possible, tu lis le fond de ma pensée!!
Je pense que "l'argument qui tue" est : on a le support de l'éditeur
et pas une société tierce qui va se défaussé au premier soucis.
c'est pour ça que je pensais à ubuntu/canonical pour le coté
admin friendly avec le support de l'éditeur.
Je vais affuter mes arguments et je vais aller voir du coté de canonical
les prix et les services proposés.
Pour l'instant, le vrai point bloquant sur la debian, c'est pas de support commercial.
Je comprends ta douleur. Le "support commercial", c'est généralement un truc pour rassurer le patron qui n'y connaît rien, et ça ne sert rigoureusement à rien en pratique : en cas de panne, tu te démerdes. Au pire, tu peux engueuler les gens du support pour te défouler, mais ça s'arrête là.
N'existe-t-il pas un prestataire qui peut fournir cette illusion pour Debian ?
c'est pas possible, tu lis le fond de ma pensée!!
Je pense que "l'argument qui tue" est : on a le support de l'éditeur et pas une société tierce qui va se défaussé au premier soucis.
c'est pour ça que je pensais à ubuntu/canonical pour le coté admin friendly avec le support de l'éditeur.
Je vais affuter mes arguments et je vais aller voir du coté de canonical les prix et les services proposés.
chksum
>> A ce que je viens de voir, on dira que c'est pour une utilisation standard (comprendre des applications standards à ce que j'ai vu pour l'instant, aucun logiciel commercial en vue...)
Si par standard vous entendez inclus dans la distribution, le choix RedHat a assez peu d'intérêt. Debian est aussi réactif que RedHat pour diffuser les mises à jour. Le seul intérêt de RedHat est de disposer d'un support "contractuel", mais il faut accepter de jouer le jeu RedHat : payer le support et maintenir les machines à jour à partir de leurs dépôts.
pour l'instant sur les machines où je suis passé c'est genre: apache/php/tomcat/mysql/nagios/script shell perl. Que du standard pour moi, et franchement y'a pas de quoi fouetter un chat.
La stratégie est plutôt : - machine critique = RedHat + contrat de mise à jour RHN - machine non critique (développement, test,...) = CentOS.
C'est marrant, mon premier cas qu'on m'a mis dans les mains. -> Mets à jour c'est machines critiques STP Gloups!
Je répète, dans votre cas, il est aberrant d'imposer RedHat et de ne pas en accepter les conséquences (mise sous contrat RHN de tous les serveurs critiques). Pour avoir l'heure, on n'est pas obligé de choisir une Rolex; surtout quand on en a pas les moyens (d'autres le font aussi bien pour beaucoup moins cher ! ;))
D'un point de vue pratique, nous faisons régulièrement des mises à jour de serveurs critiques dans de *très* anciennes distributions. Généralement, nous commençons par cloner le serveur dans une machine virtuelle et validons la procédure de mise à jour avant de l'appliquer sur le serveur réel.
Comme tu dis une montre donne l'heure rien n'oblige à prendre une rollex. Pour les mises à jour serveurs en faisant des clonages, tu parles bien de machines sous redhat? Je voudrais savoir comment tu procèdes ou si tu as un lien pour expliquer cela. Parce que de ce que je vois, ça oblige à enregistrer le clone sur RHN juste pour tenter l'upgrade. Aberrant selon moi (à moi que j'ai raté qlq chose)
Le vrai problème selon moi, je suis dans une boite "riche" (comprendre avec des problèmes de riches). Au tout début il aurait mis une distrib "whatever" sans se poser de questions, maintenant y'a le flip du support linux.
Mon idée était plutôt de partir sur du ubuntu serveur/canonical pour le support, mais de ce que ce coté là, Pas grand chose à se mettre sous la dent.
Si toutes vos applications font partie de la distribution Ubuntu Server et que vous voulez des engagements contractuels, la solution Ubuntu/Canonical est peut être une bonne alternative. Ceci dit, je n'ai aucune expérience du support Canonical.
Cordialement,
si quelqu'un peut donner des remontées du coté ubuntu/canonical, je suis preneur. Surtout pour le coté, réactivité et qualité du support.
Merci
>> A ce que je viens de voir, on dira que c'est pour une utilisation
standard (comprendre des applications standards à ce que j'ai vu
pour l'instant, aucun logiciel commercial en vue...)
Si par standard vous entendez inclus dans la distribution, le choix
RedHat a assez peu d'intérêt. Debian est aussi réactif que RedHat pour
diffuser les mises à jour.
Le seul intérêt de RedHat est de disposer d'un support "contractuel",
mais il faut accepter de jouer le jeu RedHat : payer le support et
maintenir les machines à jour à partir de leurs dépôts.
pour l'instant sur les machines où je suis passé c'est genre:
apache/php/tomcat/mysql/nagios/script shell perl.
Que du standard pour moi,
et franchement y'a pas de quoi fouetter un chat.
La stratégie est plutôt :
- machine critique = RedHat + contrat de mise à jour RHN
- machine non critique (développement, test,...) = CentOS.
C'est marrant, mon premier cas qu'on m'a mis dans les mains.
-> Mets à jour c'est machines critiques STP Gloups!
Je répète, dans votre cas, il est aberrant d'imposer RedHat et de ne pas
en accepter les conséquences (mise sous contrat RHN de tous les serveurs
critiques).
Pour avoir l'heure, on n'est pas obligé de choisir une Rolex; surtout
quand on en a pas les moyens (d'autres le font aussi bien pour beaucoup
moins cher ! ;))
D'un point de vue pratique, nous faisons régulièrement des mises à jour
de serveurs critiques dans de *très* anciennes distributions.
Généralement, nous commençons par cloner le serveur dans une machine
virtuelle et validons la procédure de mise à jour avant de l'appliquer
sur le serveur réel.
Comme tu dis une montre donne l'heure rien n'oblige à prendre une rollex.
Pour les mises à jour serveurs en faisant des clonages, tu parles
bien de machines sous redhat? Je voudrais savoir comment tu procèdes
ou si tu as un lien pour expliquer cela. Parce que de ce que je vois,
ça oblige à enregistrer le clone sur RHN juste pour tenter l'upgrade.
Aberrant selon moi (à moi que j'ai raté qlq chose)
Le vrai problème selon moi, je suis dans une boite "riche" (comprendre
avec des problèmes de riches). Au tout début il aurait mis une distrib
"whatever"
sans se poser de questions, maintenant y'a le flip du support linux.
Mon idée était plutôt de partir sur du ubuntu serveur/canonical pour le
support, mais de ce que ce coté là, Pas grand chose à se mettre sous
la dent.
Si toutes vos applications font partie de la distribution Ubuntu Server
et que vous voulez des engagements contractuels, la solution
Ubuntu/Canonical est peut être une bonne alternative.
Ceci dit, je n'ai aucune expérience du support Canonical.
Cordialement,
si quelqu'un peut donner des remontées du coté ubuntu/canonical, je suis
preneur.
Surtout pour le coté, réactivité et qualité du support.
>> A ce que je viens de voir, on dira que c'est pour une utilisation standard (comprendre des applications standards à ce que j'ai vu pour l'instant, aucun logiciel commercial en vue...)
Si par standard vous entendez inclus dans la distribution, le choix RedHat a assez peu d'intérêt. Debian est aussi réactif que RedHat pour diffuser les mises à jour. Le seul intérêt de RedHat est de disposer d'un support "contractuel", mais il faut accepter de jouer le jeu RedHat : payer le support et maintenir les machines à jour à partir de leurs dépôts.
pour l'instant sur les machines où je suis passé c'est genre: apache/php/tomcat/mysql/nagios/script shell perl. Que du standard pour moi, et franchement y'a pas de quoi fouetter un chat.
La stratégie est plutôt : - machine critique = RedHat + contrat de mise à jour RHN - machine non critique (développement, test,...) = CentOS.
C'est marrant, mon premier cas qu'on m'a mis dans les mains. -> Mets à jour c'est machines critiques STP Gloups!
Je répète, dans votre cas, il est aberrant d'imposer RedHat et de ne pas en accepter les conséquences (mise sous contrat RHN de tous les serveurs critiques). Pour avoir l'heure, on n'est pas obligé de choisir une Rolex; surtout quand on en a pas les moyens (d'autres le font aussi bien pour beaucoup moins cher ! ;))
D'un point de vue pratique, nous faisons régulièrement des mises à jour de serveurs critiques dans de *très* anciennes distributions. Généralement, nous commençons par cloner le serveur dans une machine virtuelle et validons la procédure de mise à jour avant de l'appliquer sur le serveur réel.
Comme tu dis une montre donne l'heure rien n'oblige à prendre une rollex. Pour les mises à jour serveurs en faisant des clonages, tu parles bien de machines sous redhat? Je voudrais savoir comment tu procèdes ou si tu as un lien pour expliquer cela. Parce que de ce que je vois, ça oblige à enregistrer le clone sur RHN juste pour tenter l'upgrade. Aberrant selon moi (à moi que j'ai raté qlq chose)
Le vrai problème selon moi, je suis dans une boite "riche" (comprendre avec des problèmes de riches). Au tout début il aurait mis une distrib "whatever" sans se poser de questions, maintenant y'a le flip du support linux.
Mon idée était plutôt de partir sur du ubuntu serveur/canonical pour le support, mais de ce que ce coté là, Pas grand chose à se mettre sous la dent.
Si toutes vos applications font partie de la distribution Ubuntu Server et que vous voulez des engagements contractuels, la solution Ubuntu/Canonical est peut être une bonne alternative. Ceci dit, je n'ai aucune expérience du support Canonical.
Cordialement,
si quelqu'un peut donner des remontées du coté ubuntu/canonical, je suis preneur. Surtout pour le coté, réactivité et qualité du support.
Merci
Fabien LE LEZ
On Sun, 05 Apr 2009 12:13:49 +0200, chksum :
et pas une société tierce qui va se défausser au premier soucis.
Argument qui ne tient bien évidemment pas une seconde -- l'éditeur se défausse aussi facilement. Il suffit de prévoir des pénalités financières en cas de non-fourniture du service et le problème est réglé.
Mais bon... si les scientifiques ont réussi à faire pousser des dents chez des poussins, il n'ont pas encore réussi à fournir un cerveau aux décideurs.
On Sun, 05 Apr 2009 12:13:49 +0200, chksum <utilisateur@exemple.fr>:
et pas une société tierce qui va se défausser au premier soucis.
Argument qui ne tient bien évidemment pas une seconde -- l'éditeur se
défausse aussi facilement.
Il suffit de prévoir des pénalités financières en cas de
non-fourniture du service et le problème est réglé.
Mais bon... si les scientifiques ont réussi à faire pousser des dents
chez des poussins, il n'ont pas encore réussi à fournir un cerveau aux
décideurs.
et pas une société tierce qui va se défausser au premier soucis.
Argument qui ne tient bien évidemment pas une seconde -- l'éditeur se défausse aussi facilement. Il suffit de prévoir des pénalités financières en cas de non-fourniture du service et le problème est réglé.
Mais bon... si les scientifiques ont réussi à faire pousser des dents chez des poussins, il n'ont pas encore réussi à fournir un cerveau aux décideurs.
Fabien LE LEZ
On Sun, 05 Apr 2009 12:23:54 +0200, chksum :
Le vrai problème selon moi, je suis dans une boite "riche"
Semi-riche. Le vrai riche, il a AIX, pas Linux.
On Sun, 05 Apr 2009 12:23:54 +0200, chksum <utilisateur@exemple.fr>:
Le vrai problème selon moi, je suis dans une boite "riche"
Le vrai problème selon moi, je suis dans une boite "riche"
Semi-riche. Le vrai riche, il a AIX, pas Linux.
chksum
Fabien LE LEZ a écrit :
On Sun, 05 Apr 2009 12:13:49 +0200, chksum :
et pas une société tierce qui va se défausser au premier soucis.
Argument qui ne tient bien évidemment pas une seconde -- l'éditeur se défausse aussi facilement. Il suffit de prévoir des pénalités financières en cas de non-fourniture du service et le problème est réglé.
Je verais la réaction du support cette semaine concernant le sujet et pourrais déjà me faire une idée plus précise de la situation avant de trancher dans le vif. Je reviendrais le we prochain pour dire comment ça se passe.
Merci
Fabien LE LEZ a écrit :
On Sun, 05 Apr 2009 12:13:49 +0200, chksum <utilisateur@exemple.fr>:
et pas une société tierce qui va se défausser au premier soucis.
Argument qui ne tient bien évidemment pas une seconde -- l'éditeur se
défausse aussi facilement.
Il suffit de prévoir des pénalités financières en cas de
non-fourniture du service et le problème est réglé.
Je verais la réaction du support cette semaine concernant le sujet et
pourrais déjà me faire une idée plus précise de la situation
avant de trancher dans le vif. Je reviendrais le we prochain
pour dire comment ça se passe.
et pas une société tierce qui va se défausser au premier soucis.
Argument qui ne tient bien évidemment pas une seconde -- l'éditeur se défausse aussi facilement. Il suffit de prévoir des pénalités financières en cas de non-fourniture du service et le problème est réglé.
Je verais la réaction du support cette semaine concernant le sujet et pourrais déjà me faire une idée plus précise de la situation avant de trancher dans le vif. Je reviendrais le we prochain pour dire comment ça se passe.
