Salut,
Selon vous, est-il judicieux d'utiliser une debian testing en prod ou est-il préférable d'utiliser une debian stable ? L'avantage de la testing c'est que les mises à jour logicielles sont plus fréquentes mais du coup le risque de casse est plus élevé, nos serveurs sont actuellement en Lenny (Installés avant le passage en stable) mais vu que je vais bientôt devoir monter de nouveaux serveurs je me posais la question de testing ou stable.
Si tu utilises du testing pour de la prod', tu pourras pas dire que tu n'as pas été prévenu =)
Stable pour la prod. Même s'il faut attendre pour obtenir certaines features (les security update sont aussi rapides à être publiées lorsque nécessaires).
Benjamin
Le 13/12/2010 23:57, Mickael MARCON a écrit :
Salut,
Selon vous, est-il judicieux d'utiliser une debian testing en prod ou est-il préférable d'utiliser une debian stable ? L'avantage de la testing c'est que les mises à jour logicielles sont plus fréquentes mais du coup le risque de casse est plus élevé, nos serveurs sont actuellement en Lenny (Installés avant le passage en stable) mais vu que je vais bientôt devoir monter de nouveaux serveurs je me posais la question de testing ou stable. _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Autre alternative : utiliser Ubuntu LTS
Ca fonctionne plutôt pas trop mal et on a pas trop de soucis de notre côté, l'avantage : ne pas être trop vieux au niveau versions paquets.
Lilian
Le 14/12/2010 00:26, Benjamin Billon a écrit :
Si tu utilises du testing pour de la prod', tu pourras pas dire que tu n'as pas été prévenu =)
Stable pour la prod. Même s'il faut attendre pour obtenir certaines features (les security update sont aussi rapides à être publiées lorsque nécessaires).
Benjamin
Le 13/12/2010 23:57, Mickael MARCON a écrit :
Salut,
Selon vous, est-il judicieux d'utiliser une debian testing en prod ou est-il préférable d'utiliser une debian stable ? L'avantage de la testing c'est que les mises à jour logicielles sont plus fréquentes mais du coup le risque de casse est plus élevé, nos serveurs sont actuellement en Lenny (Installés avant le passage en stable) mais vu que je vais bientôt devoir monter de nouveaux serveurs je me posais la question de testing ou stable. _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Liste de diffusion du FRsAG http://www.frsag.org/
Oui,
Je fais poser la question en pensant aux éventuelles update logicielles nécessaires, comme là par exemple, mettre à jour Samba pour essayer de régler un problème de rattachement à notre domaine. On tourne actuellement avec la version 3.4.7, les versions 3.5 "corrigeraient" notre problème mais bien évidemment pour Lenny le paquet Samba est à jour, va sûrement falloir que je compile et je crains que Samba ne requiert des paquets plus que ceux qui sont dispos sous Lenny, problèmes de dépendances etc. Après je me doute que rester en testing sur un serveur de Prod ce n'est pas forcément très malin, c'est risqué.
On 14/12/2010 07:19, Mickael MARCON wrote:
Oui,
Je fais poser la question en pensant aux éventuelles update logicielles nécessaires, comme là par exemple, mettre à jour Samba pour essayer de régler un problème de rattachement à notre domaine. On tourne actuellement avec la version 3.4.7, les versions 3.5 "corrigeraient" notre problème mais bien évidemment pour Lenny le paquet Samba est à jour, va sûrement falloir que je compile et je crains que Samba ne requiert des paquets plus que ceux qui sont dispos sous Lenny, problèmes de dépendances etc. Après je me doute que rester en testing sur un serveur de Prod ce n'est pas forcément très malin, c'est risqué. _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Les backports (http://backports.debian.org/) ont samba à jour pour Lenny il me semble.
My 2 cents.
Oui, j'avais déjà activé les backports mais j'avais un peu oublié de câler un "-t lenny-backports" quand je voulais mettre à jour un paquet... Forcément je ne risquais pas de voir la dernière version de Samba... Je lancerai ça ce soir en espérant que tout se passe correctement, merci pour les conseils en tout cas ;)
Le 14 décembre 2010 07:44, Antoine MILLET antoine.millet@grimly.org a écrit :
On 14/12/2010 07:19, Mickael MARCON wrote:
Oui,
Je fais poser la question en pensant aux éventuelles update logicielles
nécessaires, comme là par exemple, mettre à jour Samba pour essayer de régler un problème de rattachement à notre domaine.
On tourne actuellement avec la version 3.4.7, les versions 3.5
"corrigeraient" notre problème mais bien évidemment pour Lenny le paquet Samba est à jour, va sûrement falloir que je compile et je crains que Samba ne requiert des paquets plus que ceux qui sont dispos sous Lenny, problèmes de dépendances etc.
Après je me doute que rester en testing sur un serveur de Prod ce n'est
pas forcément très malin, c'est risqué.
Liste de diffusion du FRsAG http://www.frsag.org/
Les backports (http://backports.debian.org/) ont samba à jour pour Lenny il me semble.
My 2 cents.
-- Antoine MILLET _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Le Tue, Dec 14, 2010 at 08:11:21AM +0100, Jaymzwise Jaymzwise [jaymzwize@gmail.com] a écrit:
Oui, j'avais déjà activé les backports mais j'avais un peu oublié de câler un "-t lenny-backports" quand je voulais mettre à jour un paquet... Forcément je ne risquais pas de voir la dernière version de Samba...
« apt-cache policy paquet » pour voir les versions proposées :)
Et sinon, d'une manière générale, on peut aussi faire soit même des backports. (bon, certains paquets sont mal foutus, et faut charcuter dedans ou remonter 30 dépendances...)
idem
les ubuntu LTS sont très stables et plutot à jour j'en administre tous les jours avec joie :p
Le 14/12/2010 00:28, Lilian RIGARD - Devclic a écrit :
Autre alternative : utiliser Ubuntu LTS
Ca fonctionne plutôt pas trop mal et on a pas trop de soucis de notre côté, l'avantage : ne pas être trop vieux au niveau versions paquets.
Lilian
Le 14/12/2010 00:26, Benjamin Billon a écrit :
Si tu utilises du testing pour de la prod', tu pourras pas dire que tu n'as pas été prévenu =)
Stable pour la prod. Même s'il faut attendre pour obtenir certaines features (les security update sont aussi rapides à être publiées lorsque nécessaires).
Benjamin
Le 13/12/2010 23:57, Mickael MARCON a écrit :
Salut,
Selon vous, est-il judicieux d'utiliser une debian testing en prod ou est-il préférable d'utiliser une debian stable ? L'avantage de la testing c'est que les mises à jour logicielles sont plus fréquentes mais du coup le risque de casse est plus élevé, nos serveurs sont actuellement en Lenny (Installés avant le passage en stable) mais vu que je vais bientôt devoir monter de nouveaux serveurs je me posais la question de testing ou stable. _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Liste de diffusion du FRsAG http://www.frsag.org/
Liste de diffusion du FRsAG http://www.frsag.org/
On Tue, 14 Dec 2010 17:52:44 +0100, Christophe Deze christophedeze@wanadoo.fr wrote:
idem
les ubuntu LTS sont très stables et plutot à jour j'en administre tous les jours avec joie :p
Ouch. Pas trop mal au coeur ?
Le 14/12/2010 00:28, Lilian RIGARD - Devclic a écrit :
Autre alternative : utiliser Ubuntu LTS
Ca fonctionne plutôt pas trop mal et on a pas trop de soucis de notre côté, l'avantage : ne pas être trop vieux au niveau versions paquets.
Alors, je connais peu voire pas les Ubuntu Server, mais à chaque fois que j'ai testé Ubuntu (régulièrement depuis la 5.04), y'a toujours eu un truc qui déconnait dans l'install de base. J'ai plus l'historique, mais par exemple dans mon dernier test avec la 10.10, Firefox freezait toutes les 2 minutes, quasi inutilisable. L'install aurait tenu plus d'une journée, j'aurais ptet découvert d'autres surprises. Bref, j'ai vite vite fait un retour arrière. Ca ne donne pas forcément super envie de coller la même distro en prod.
Le 14/12/2010 18:32, Julien Gormotte a écrit :
On Tue, 14 Dec 2010 17:52:44 +0100, Christophe Deze christophedeze@wanadoo.fr wrote:
idem
les ubuntu LTS sont très stables et plutot à jour j'en administre tous les jours avec joie :p
Ouch. Pas trop mal au coeur ?
non, on s'y fait ;) j'ai vu pire ...
Le 14/12/2010 00:28, Lilian RIGARD - Devclic a écrit :
Autre alternative : utiliser Ubuntu LTS
Ca fonctionne plutôt pas trop mal et on a pas trop de soucis de notre côté, l'avantage : ne pas être trop vieux au niveau versions paquets.
Alors, je connais peu voire pas les Ubuntu Server, mais à chaque fois que j'ai testé Ubuntu (régulièrement depuis la 5.04), y'a toujours eu un truc qui déconnait dans l'install de base. J'ai plus l'historique, mais par exemple dans mon dernier test avec la 10.10, Firefox freezait toutes les 2 minutes, quasi inutilisable. L'install aurait tenu plus d'une journée, j'aurais ptet découvert d'autres surprises. Bref, j'ai vite vite fait un retour arrière. Ca ne donne pas forcément super envie de coller la même distro en prod.
je ne parlait en effet que de la version server. même si je n'ai rien contre la version desktop!
Liste de diffusion du FRsAG http://www.frsag.org/
Bonjour,
Squeeze (actuellement testing) devrait passer stable sous peu, entre fin 2010 - début 2011. Tout dépend des versions de logiciels dont vous avez besoin et de votre échéance, si il vous reste 1-2 semaines installé directement en squeeze peut permettre d'éviter un upgrade (même si sous debian c'est "finger in the noose") par contre il reste 280 bugs critiques mais 80 réelement important, Stat à la date du 8 décembre cf. http://www.debian.org/News/weekly/2010/17/).
La décision vous reviens.
Lucas
PS: Squeeze :O
Bonjour,
Chez nous cela fait environ 3 mois qu'on installe que de la Squeeze (une bonne centaine en place actuellement, et ça continue) ... aucun problème à ce jour. En surveillant régulièrement les mises à jour ca ne me parait pas être une folie (après ca dépend de l'environnement). On l'utilise parce que les versions de certains softs vont bien avec nos besoins.
Cdt,
Le 14/12/2010 09:37, Jonathan Amiez a écrit :
Bonjour,
Chez nous cela fait environ 3 mois qu'on installe que de la Squeeze (une bonne centaine en place actuellement, et ça continue) ... aucun problème à ce jour. En surveillant régulièrement les mises à jour ca ne me parait pas être une folie (après ca dépend de l'environnement). On l'utilise parce que les versions de certains softs vont bien avec nos besoins.
Cdt,
Bonjour,
pareil ici, on utilise squeeze depuis bientôt un an sur certains hôtes kvm. En revanche, tous les déploiements récents, se font bien en squeeze. Noyaux recompilés, packages recompilés suivants les besoins.
Je dirais, qu'après, tout dépend des besoins, des services qui tournent dessus, et des tests menés, avant le passage en production.
A+
Ok, je verrai quand j'aurai les nouveaux serveurs sous la main. Après concernant les services qui tourneront dessus rien d'extraordinaire à signaler : Samba, openLDAP, CUPS, DHCP et Bind. On tourne avec la Lenny depuis qu'elle est unstable, aucun pépin à signaler, pas vraiment étonnant vu que la politique de mon N+1 c'est plutôt d'éviter de mettre à jour un serveur qui tourne correctement... Vu comme ça c'est sûr que l'on ne risque pas de casser quelque chose... L'arrivée des nouveaux serveurs sera l'occasion de justement changer cette "façon" de travailler et d'avoir des serveurs le plus à jour possible, enfin je vais essayer du moins.
Le 14 décembre 2010 09:51, Menil Jean-Philippe < jean-philippe.menil@univ-nantes.fr> a écrit :
Le 14/12/2010 09:37, Jonathan Amiez a écrit :
Bonjour,
Chez nous cela fait environ 3 mois qu'on installe que de la Squeeze (une bonne centaine en place actuellement, et ça continue) ... aucun problème à ce jour. En surveillant régulièrement les mises à jour ca ne me parait pas être une folie (après ca dépend de l'environnement). On l'utilise parce que les versions de certains softs vont bien avec nos besoins.
Cdt,
Bonjour,
pareil ici, on utilise squeeze depuis bientôt un an sur certains hôtes kvm. En revanche, tous les déploiements récents, se font bien en squeeze. Noyaux recompilés, packages recompilés suivants les besoins.
Je dirais, qu'après, tout dépend des besoins, des services qui tournent dessus, et des tests menés, avant le passage en production.
A+
Liste de diffusion du FRsAG http://www.frsag.org/
Pareil pour nous, j'étais plutôt contre l'idée d'installer de la testing en prod.
Mais on a 100 node en Debian Testing et ça tourne sans problème.
Notre logiciel interne a peu de dépendance avec la testing donc ça aide et on ne les mets à jour qu'en cas de besoin.
Le mardi 14 décembre 2010 à 09:37 +0100, Jonathan Amiez a écrit :
Bonjour,
Chez nous cela fait environ 3 mois qu'on installe que de la Squeeze (une bonne centaine en place actuellement, et ça continue) ... aucun problème à ce jour. En surveillant régulièrement les mises à jour ca ne me parait pas être une folie (après ca dépend de l'environnement). On l'utilise parce que les versions de certains softs vont bien avec nos besoins.
Cdt,
De notre côté on utilise SID pour certains softs (nginx / lighttpd / haproxy / clamav / SA par exemple ou lorsqu'on a besoin des dernières versions).
Pour les paquets PHP, j'utilise les dépots dotdeb.
Dans notre sources.list on a qu'une seule ligne qui n'est pas en "stable" mais qui est en "lenny" et après:
sed -i 's/lenny/sid/g' /etc/apt/sources.list apt-get update && apt-get install nginx sed -i 's/sid/lenny/g' /etc/apt/sources.list apt-get update
Le tout en alias avec un fupdate <paquet>.
On a aussi quelques serveurs 100% en squeeze et jamais eu de gros bugs. Le paquet "apt-listbugs" permet d'être prévenu ;)
Le 13/12/2010 23:57, Mickael MARCON a écrit :
Salut,
Selon vous, est-il judicieux d'utiliser une debian testing en prod ou est-il préférable d'utiliser une debian stable ? L'avantage de la testing c'est que les mises à jour logicielles sont plus fréquentes mais du coup le risque de casse est plus élevé, nos serveurs sont actuellement en Lenny (Installés avant le passage en stable) mais vu que je vais bientôt devoir monter de nouveaux serveurs je me posais la question de testing ou stable.
On 14/12/2010 10:16, ml@admin-serv.net wrote:
De notre côté on utilise SID pour certains softs (nginx / lighttpd / haproxy / clamav / SA par exemple ou lorsqu'on a besoin des dernières versions).
Pour les paquets PHP, j'utilise les dépots dotdeb.
Dans notre sources.list on a qu'une seule ligne qui n'est pas en "stable" mais qui est en "lenny" et après:
sed -i 's/lenny/sid/g' /etc/apt/sources.list apt-get update && apt-get install nginx sed -i 's/sid/lenny/g' /etc/apt/sources.list apt-get update
man apt_preferences (aka "pinning"), et tu n'as pas besoin de toucher à ton sources.list et de passer par update && install. Un simple update && upgrade suffira.
Salut,
J'ai tenté une fois de monter des archis en testing en production ca marche très bien mais il faut être rigoureux. Rigoureux dans le sens où des petites mises à jour chaque semaine ou toutes les deux semaines permettent de faire évoluer la machine tranquillement.
Si par contre tu ne mets plus à jour la machine pendant un lapse de temps, le jour où ton client te demande un nouveau package, tu vas avec le jeu des dépendances devoir tout mettre à jour et là ca sera le drame.
Donc comme j'ai pu vérifier que les clients et les boites ne te laissent par le temps de bien faire les choses dans ce cas je te conseil plutôt de faire du stable et soit faire un backport soit de faire l'installation de tel ou tel soft en testing.
Voir mieux de les compiler (php, apache, mysql, ...) comme cela tu choisis la version que tu veux laisser en production.
Sinon à titre personnel toutes mes machines sont en testing et ca ne pose pas de soucis car mise à jour dès qu'un paquet est dispo pour.
-- Pierre-Henry Muller
Le Wed, Dec 15, 2010 at 06:07:02PM +0100, Pierre-Henry Muller [wallace@morkitu.org] a écrit:
Voir mieux de les compiler (php, apache, mysql, ...) comme cela tu choisis la version que tu veux laisser en production.
Et tu sédimentes.
Le 15 déc. 2010 à 18:22, Dominique Rousseau a écrit :
Le Wed, Dec 15, 2010 at 06:07:02PM +0100, Pierre-Henry Muller [wallace@morkitu.org] a écrit:
Voir mieux de les compiler (php, apache, mysql, ...) comme cela tu choisis la version que tu veux laisser en production.
Et tu sédimentes.
Quand une webagency, un éditeur de logiciel dit clairement à son client, si vous n'avez pas exactement telle et telle version des logiciels suivants on n'assure pas le support.
Donc le client reporte la demande des versions exactes et tu es obligé de répondre à cette demande. Comme à un instant T aucun des logiciels demandés n'est à la bonne version et que tu ne peux le garantir après une mise à jour, la compilation reste le seul moyen de répondre correctement aux prérequis.
Par contre après faut mettre en place la veille sur les failles pour faire pression pour une mise à jour ou tenter un backport du patch si il est disponible.
-- Pierre-Henry Muller
Salut,
On Mon, Dec 13, 2010 at 11:57:17PM +0100, Mickael MARCON wrote:
Selon vous, est-il judicieux d'utiliser une debian testing en prod ou est-il préférable d'utiliser une debian stable ? L'avantage de la testing c'est que les mises à jour logicielles sont plus fréquentes mais du coup le risque de casse est plus élevé, nos serveurs sont actuellement en Lenny (Installés avant le passage en stable) mais vu que je vais bientôt devoir monter de nouveaux serveurs je me posais la question de testing ou stable.
Si l'équipe est assez grosse, vous pouvez envisager de construire votre propre distribution basée soit sur stable ou un snapshot de testing.
Je suis dans une petite boîte, en gros, je suis seul à administrer des serveurs sous Debian ^^ Donc, merci pour le conseil mais je vais passer mon tour ;)
Je pense que la stable avec les backports est un bon compromis, à l'avenir je partirai sur ça :)
Le 16 déc. 2010 à 00:02, Jeremie Le Hen a écrit :
Salut,
On Mon, Dec 13, 2010 at 11:57:17PM +0100, Mickael MARCON wrote:
Selon vous, est-il judicieux d'utiliser une debian testing en prod ou est-il préférable d'utiliser une debian stable ? L'avantage de la testing c'est que les mises à jour logicielles sont plus fréquentes mais du coup le risque de casse est plus élevé, nos serveurs sont actuellement en Lenny (Installés avant le passage en stable) mais vu que je vais bientôt devoir monter de nouveaux serveurs je me posais la question de testing ou stable.
Si l'équipe est assez grosse, vous pouvez envisager de construire votre propre distribution basée soit sur stable ou un snapshot de testing.
-- Jeremie Le Hen
Humans are born free and equal. But some are more equal than others. Coluche _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
On Thu, 16 Dec 2010 00:09:26 +0100, Mickael MARCON jaymzwize@gmail.com wrote:
Je suis dans une petite boîte, en gros, je suis seul à administrer des serveurs sous Debian ^^ Donc, merci pour le conseil mais je vais passer mon tour ;)
De toute manière, même avec une grosse équipe, il vaut mieux garder une distro "normale". J'ai vu un exemple dans une TRES grosse boite, ou ils ont leur propre distrib basée sur LFS, avec une couche RPM dessus... Ben c'est jamais à jour, il manque toujours des deps, quasiment toutes les installs sont faites en --force... Tout simplement parce que c'est énormément de boulot de maintenir sa propre distrib, et que meme dans un grosse boite c'est problématique d'assigner suffisament de ressources.
Donc, amha, très mauvaise idée :)
Je pense que la stable avec les backports est un bon compromis, à l'avenir je partirai sur ça :)
Le 16 déc. 2010 à 00:02, Jeremie Le Hen a écrit :
Salut,
On Mon, Dec 13, 2010 at 11:57:17PM +0100, Mickael MARCON wrote:
Selon vous, est-il judicieux d'utiliser une debian testing en prod ou est-il préférable d'utiliser une debian stable ? L'avantage de la testing c'est que les mises à jour logicielles sont plus fréquentes mais du coup le risque de casse est plus élevé, nos serveurs sont actuellement en Lenny (Installés avant le passage en stable) mais vu que je vais bientôt devoir monter de nouveaux serveurs je me posais la question de testing ou stable.
Si l'équipe est assez grosse, vous pouvez envisager de construire votre propre distribution basée soit sur stable ou un snapshot de testing.
-- Jeremie Le Hen
Humans are born free and equal. But some are more equal than others. Coluche _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Liste de diffusion du FRsAG http://www.frsag.org/
On Thu, Dec 16, 2010 at 10:10:38AM +0100, Julien Gormotte wrote:
On Thu, 16 Dec 2010 00:09:26 +0100, Mickael MARCON jaymzwize@gmail.com wrote:
Je suis dans une petite boîte, en gros, je suis seul à administrer des serveurs sous Debian ^^ Donc, merci pour le conseil mais je vais passer mon tour ;)
De toute manière, même avec une grosse équipe, il vaut mieux garder une distro "normale". J'ai vu un exemple dans une TRES grosse boite, ou ils ont leur propre distrib basée sur LFS, avec une couche RPM dessus... Ben c'est jamais à jour, il manque toujours des deps, quasiment toutes les installs sont faites en --force... Tout simplement parce que c'est énormément de boulot de maintenir sa propre distrib, et que meme dans un grosse boite c'est problématique d'assigner suffisament de ressources.
J'aurais dû être plus clair dans mon message : je parlais de faire sa propre distrib _basée sur Debian_. J'ai d'ailleurs mensioné qu'on pouvait partir de stable ou d'un snapshot de testing.
Quoiqu'il en soit, je ne pense pas qu'on puisse parler de "distrib" basée sur LFS :-), même avec du RPM dessus.
On Thu, 16 Dec 2010 23:40:59 +0100, Jeremie Le Hen jeremie@le-hen.org wrote:
Quoiqu'il en soit, je ne pense pas qu'on puisse parler de "distrib" basée sur LFS :-), même avec du RPM dessus.
Ben, si on maintiens un ensemble de packages sur des repositories, c'est une distrib hein. Dans l'absolu, tu package un kernel et un busybox, et t'as une distrib linux.
Le Thu, Dec 16, 2010 at 12:09:26AM +0100, Mickael MARCON [jaymzwize@gmail.com] a écrit:
Je suis dans une petite boîte, en gros, je suis seul à administrer des serveurs sous Debian ^^ Donc, merci pour le conseil mais je vais passer mon tour ;)
Je pense que la stable avec les backports est un bon compromis, à l'avenir je partirai sur ça :)
Stable + volatile + backports officiels (ceux de backports.debian.org) ça permet en général de répondre à toutes les demandes normales.
Après, backporter soi même certains trucs, et/ou du pinning pour aller chercher « tel paquet » dans testing (avec upgrade la libc au passage ;), c'est parfois nécessaire quand même...