Testing ou stable pour un serveur?

Bonjour,

l’entreprise ou je travaille posséde un serveur de fichier et d’impression sous Windows Server 2003 mais ce dernier plante plutot souvent à mon gout (crosoft oblige), enfin bref j’aimerai leur proposer une solution Samba/Cups en relation avec le PDC NT4 grace a Winbind, mais j’hésite entre une distrib Testing et Stable, sachant que le serveur est un serveur plutot critique car il héberge tous les fichiers de la boite et gére toutes les imprimantes, donc doit etre disponible à 100%.

Voila en gros ma situation, au passage j’aimerai avoir vos avis sur la question du passage d’un serveur crosoft à Linux, les pour et les contres, vos expériences, afin de savoir si mon projet est viable et surtout pouvoir leur monter un dossier béton :wink:, mon plus gros probléme étant la maintenance d’un telle serveur et son côut en main d’oeuvre !!

J’attend avec impatience toutes vos suggestions qui me seront d’une aide précieuse.

à la prochaine et une bonne journée à tous :slightly_smiling:

Moi je dirais stable… mais bon j’ai peut’ère pas le niveaux pour un conseille… :confused:

Je lis “critique”…
Je dis STABLE.

Pour un serveur en production qui plus est…

Je pense que testing est un bon choix car la sortie de Etch est prévue pour décembre, ce serai dommage de s’en priver. D’ici là, côté maintenance, avec des mises à jours réguilières le serveur serai tout aussi fiable qu’avec une sarge.

Je profite du poste pour pausé une tite question d’information, ceux qui son en stable et veule passé en testing c’est fesable fassilement ?

ben moi j’y suis arrivé assez facilement:
tu change ton sources.list (tu remplace stable par testing ou sarge par etch)
apt-get update
apt-get dist-upgrade

eh hop

pour ton serveur je dirait-stable vu que tu n’aura pas vraiment besoin d’interface graphique dessus. Sur la sarge au moins tu es sur de ne pas faire de mise à jour foireuse( plutot que sur etch ou tu as parfois des paquets bloqués donc problèmes de dépendances)

Stable sans reflechir!
Soit Sarge soit tu attends la Etch si par exemple il te manque des trucs et plus particulierement des drivers qui seront dans le noyau de la Etch; parceque si tu peux pas booter ou utiliser ta carte réseau car exotique, t’as plus qu’a attendre la etch.

edit:
Ah oui kernel 2.4 est jugé stable, le 2.6 pas encore…

Backports ou compile du kernel à la mano :laughing:

tout a fait petit_chat, le matos non détecté n’est pas une fatalitée sur sarge.

Quand au 2.6 je dirais qu’il peu maintenant etre utilisé meme sur quelque chose de critique… je conseil Sarge avec 2.6, passage à etch QUAND il sera stable :slightly_smiling:

Je suis du même avis que toi, et pourtant j’adore les versions sid et testing, mais sur un serveur de production, sincèrement ce serait prendre des risques. Et visiblement t’en as déjà pris. La testing semble certes stable jusqu’a la petite mise a jour particulière qui n’a jamais été testé sur ton matos très spécifique et qui va te provoquer un bug…
On sait jamais, mieux vaut prévenir comme on dit…

Stable + backports, mais j’avoue que j’ai aussi un routeur en etch (je ne sais plus pkoi) et 1 autre avec un noyaux et toutes ses dépendances en sid (fonctions avancées d’iptables, si je me souviens bien pkoi).

[quote=“avision”]tout a fait petit_chat, le matos non détecté n’est pas une fatalitée sur sarge.

Quand au 2.6 je dirais qu’il peu maintenant etre utilisé meme sur quelque chose de critique… je conseil Sarge avec 2.6, passage à etch QUAND il sera stable :slightly_smiling:[/quote]+1

quitte à dire une connerie, ce que je ferais est d’installer une debian stable (sarge à l’heure actuelle) et de modifier le source.list comme suit:

[code]deb http://ftp.fr.debian.org/debian/ sarge main
deb-src http://ftp.fr.debian.org/debian/ sarge main

deb http://security.debian.org/debian/ sarge/updates main
deb-src http://security.debian.org/debian/ sarge/updates main[/code]

par

[code]deb http://ftp.fr.debian.org/debian/ stable main
deb-src http://ftp.fr.debian.org/debian/ stable main

deb http://security.debian.org/debian/ stable/updates main
deb-src http://security.debian.org/debian/ stable/updates main[/code]

comme ca lors du glisement de etch en stable, il n’y aura qu’a faire un petit

apt-get update apt-get upgrade

j’ai bon ou j’ai dit une connerie ?

une connerie.
lors de la stabilisation de la sarge, le glissement ne s’est pas fait correctement partout, et stable designait encore woody à certains endroits (mais c’est vrai que les mirroirs debian s’etaient synchronisés en même temps).
Par ailleurs, il vaut mieux garder le controle sur ce qu’on fait, et eviter de faire le grand saut sans le savoir, et de se retrouver tout bête parceque dujour au lendemain, il veut réinstaller x% du systême.
Donc, AMA, il vaut mieux preciser sarge qu’utiliser le terme stable.
En plus, pour passer d’une distrib à l’autre, en général, un upgrade est insuffisant, et le dist-upgrade s’avère necessaire (il est fait pour ça d’ailleurs).

merci pour la précision MattOTop :wink:
je me coucherai moins bête. je pensais que le passage d’une “oldstable” vers la stable actuelle ne posait pas de soucis majeur, vu qu’elle est censée être stable, mais c’est vrai que en y réflechissant un peu la passage de l’une à l’autre peut poser problème (notamment au niveau des dépendances ou du kernel si je comprend bien :unamused: )

non, pas spécialement le kernel. C’est surtout que le passage d’une version à une autre necessite souvent des desinstallation de paquets qui ont changé de nom entre temps. Le dist-upgrade normalement transpose d’une release à l’autre les paquets de remplacement, et fait des desinstalls, alors que l’upgrade simple ne fait jamais de suppression.