Mise à jour

Pause Café
#1

…

…

Sous sarge, personnellement et justement pour éviter un gros plantage qui serait catastrophique pour moi, j’ai plutôt tendance à ne faire des mises à jour qu’à la main, avec deux-trois heures devant moi et en ayant prévu le downgrade éventuel (avec dpkg-repack). Sur les serveurs surtout, je ne fait aucune mise à jour automatique. Quand un noyau fonctionne, je le garde et je n’ai à l’heure actuelle qu’une machine sous noyau 2.6 (2.6.12), celle des enfants, familiale donc, j’ai des serveurs sous 2.0, 2.2 et un 2.4 qui tournent parfaitement, la remarque de Ricardo (à propos d’un pbm de ssh), outre qu’elle est injustifiée (il n’y a pas de noyau trop vieux: sarge et etch marche très bien sur un noyau 2.2, seul le noyau 2.0 est désormais trop vieux), est à l’opposé de ce que je fais.

Bref, je suis prudent mais j’ai l’impression d’agir à l’inverse de tout le monde. Quelle est votre stratégie de mise à jour (chez vous comme sur un serveur en production)? Entre autres cherchez vous systématiquement à avoir la dernière version même au prix de la stabilité et même si les éventuelles fonctionnalités ne vous intéressent pas?

#2

bah perso :

  • sur mon portable (Debian Sid) et sur mon poste pricipal (Debian Sid) les mises à jour sont faites tous les jours manuellement (via synaptic).
  • sur mon “serveur” (Debian Sarge) je fais les mises à jour une à deux fois par mois, enfin je devrais dire je regarde s’il y a des mises à jour et je les fais s’il y en a. pas de précautions particulières.
    je sais pas si c’est la meilleure des choses à faire, mais vu que le serveur n’a rien de critique, juste un blog et 2-3 BDD sans importance, je m’en fous un peu :laughing:
    ca me permet de tester beaucoup de choses, car je n’en suis qu’au début de mon apprentissage Linux :wink:

[mode troll on]
ca dois me venir de cette me**e de Windows cette habitude de faire les MAJ sans arret :smt098
[/mode troll off]

P.S. : t’as vu Matt, j’ai pas oublié les balises cette fois :wink:

#3

  • Ma machine perso est une machine ou je teste en permanence: je fais plus qu’un update par jour, et je rebuild plein de paquets, je passe mon temps à la bidouiller.
    Pour ce qui est du noyau, j’en ai entre 5 et 10 versions différentes (avec patchs, sans patch, etc…), et j’ai toujours le dernier noyau debian (jamais un vanilla).
    Mon pire ennui en 4 ans: plus de X pendant trois jours.
    -L’ubuntu de ma femme que j’avais oubliée de mettre à jour pendant un an, gros plantage, j’en suis à 4 aprés midi d’update en me connectant avec le livecd en chroot, et elle n’est toujours pas revenu à un état opérationnel.

  • mes routeurs en production (les interruptions courtes ne sont pas critiques chez moi):
    mise à jour systêmatique des noyaux (compilés ailleurs).
    J’ai un apt-watch pour faire les update en auto, et apt-listbugs.
    Une fois par trimestre en moyenne quand j’ai du temps (j’aimerais le faire plus souvent pour que ce soit moins long), je fais un ‘apt-get -s dist-upgrade’, je sauve les /var/cache/apt/*.deb concernés (mais je penserais désormais au dpkg-repack), et j’installe ensuite un à un les paquets qui touchent aux fonctionnalités spécifiques au routeur, puis je fais en auto les paquets restants. Parfois, je laisse des mises à jours en suspend parceque les bugs signalés sont trop inquiètants. Jamais un soucis.

  • mes mailhubs:
    même pratique, à la différence prés que je recompiles certains paquets quand ils ont besoin d’une M.à.J.

Pour résumer: je suis plus sensible sur les serveurs en prod, mais je ne m’arrète pas à “ça marche, donc pourquoi changer”: je sais que normalement c’est pas bien, mais je prends le risque de suivre les versions pour profiter d’un maximum de mises à jours de sécurité.
Avec un autre linux, je serais peut être plus conservateur, mais pour un serveur debian, je ne suis rarement inquiet des M.à.J.

Sinon, on sait que debian fonctionne. Si on ne s’amusait pas à y mettre nous même un peu d’entropie, qu’est ce qu’on s’ennuirait !
Vive les mises à jours hasardeuses ! vive l’experimental. Remontons les bugs !!!

#4

Mon portable est sous sid (update tous les jours, jamais de problème depuis 1 an et des brouettes). Les serveurs auquels j’ai accès (je ne suis pas admin) sont sous une autre distrib (Suse… eh oui je suis en Allemagne) et ils ne sont jamais mis à jour, trop risqué. Ils sont derriere une batterie de firewalls.
C’est sale mais ca fonctionne, pourquoi changer (allez dire ca a micro$oft…)
Biensur tout est sauvegardé quotidiennement, il faut quelques heures pour tout remettre en place.

#5

Pour ma part, je suis prudent donc jamais d’essais hasardeux sur ma Sid opérationnelle.
J’ai tjrs en réserve un Sarge qui n’a pas été MAJ depuis >1 an. + un rack/DD dédié à d’autres Linux (Fedora, Mandriva et Kubuntu) qui “dorment” depuis longtemps aussi.
J’ai deux Sid, identiques ou presque quant au noyau.
Mon principe est simple :
Noyau changé env. 2x/an (passé du 2.6.12 au 2.6.17), je ne cours pas après le dernier.
Paquets =
– update des deux sid ~ ts les mois.
– upgrade de la seule sid “test” (synaptic + dist-upgrade) et essais des principaux logiciels et matos pendant qq jours.
Si tt est bon, je n’upgrade ma Sid fonctionnelle que pour FF, KDE, etc. et au besoin des logiciels.
Voilou !
Bonne idée que ce sondage !

#6

Utilisation personelle + openoffice pour le travail

  • pour le travail j’ai depuis quelques mois une sid 32 que je mets à jour tous les jours : un seul problème une fois avec openoffice
  • une deuxième debian etch 64 que je met à jour moins souvent qui est une roue de secours sur un autre disque (en cas de problème sur sid, en espérant que les deux n’aient pas un problème simultané
    Le tout mis à jour avec aptitude (qui continue à fonctionner si problème de serveur X)
#7

Je n’ai qu’une machine, avec 2 installations de debian (et le /home en commun)

  • une en testing, que je mets à jour 1 fois par semaine environ. J’ai dû récemment installer un nouveau noyau à cause de udev, mais sinon j’étais en 2.6.8
  • une sous sarge ‘au cas où’

Je n’aime pas trop mettre à jour tout le temps, aussi je pense que quand etch sortira, je resterai sous etch, même si je n’ai pas un serveur.

#8

Sarge : mise à jour de sécurité qd j’ai des paquets installés concernés.

Sid : le moins possible, s’il me faut absolument un truc. Inconvénient : j’ai de + en + de mal à régler les dépendances (comme je m’éloigne du véritable état de “Sid”)

:wink:

#9

[quote=“Bluenote”]Sarge : mise à jour de sécurité qd j’ai des paquets installés concernés.

Sid : le moins possible, s’il me faut absolument un truc. Inconvénient : j’ai de + en + de mal à régler les dépendances (comme je m’éloigne du véritable état de “Sid”)

:wink:[/quote]C’est ça le problême: quand on a un systême stable, AMA, l’ajout du moindre paquet nécessiterait au moins d’homogeneiser avec les version à jour des paquets dont il dépend récursivement, et des paquets liés (autrement dit, quasi tout le systême pour la majorité des installs).
J’ai eu je ne sais pas combien de problêmes à installer des nouvelles fonctionnalités sur des machines inchangées depuis des lustres, et à chaque fois, la seul solution à été un violent dist-upgrade qui a remis les paquets au même niveau.
Autrement dit, à part sur une machine VRAIMENT immuable, je suis arrivé à la conclusion qu’on a interet à rester homogène, et à suivre en terme de version, pour éviter le drâme d’une grosse migration quand l’install d’une nouvelle fonctionnalité devient nécessaire (nouvel antispam, meilleur vpn, etc…).
Je me dis qu’en plus la surveillance d’un parc nécessitant de mettre le nez dans tout tout le temps pour voir si ça marche bien comme on s’y attend, autant que ça se fasse lors de mises à jour au fil de l’eau.
Enfin, ce que j’en pense va à l’inverse des habitudes communes, alors je ne le dis pas trop fort, mais mes serveurs sont à jour :wink: .
Je précise que je parle de mes serveurs DEBIAN ! Je ne fais pas ça avec mes windoobes, et je ne faisais pas ça aussi allègrement quand j’étais sous redhat.

#10

[quote=“MattOTop”]
J’ai eu je ne sais pas combien de problêmes à installer des nouvelles fonctionnalités sur des machines inchangées depuis des lustres, et à chaque fois, la seul solution à été un violent dist-upgrade qui a remis les paquets au même niveau.
Autrement dit, à part sur une machine VRAIMENT immuable, je suis arrivé à la conclusion qu’on a interet à rester homogène, et à suivre en terme de version, pour éviter le drâme d’une grosse migration quand l’install d’une nouvelle fonctionnalité devient nécessaire (nouvel antispam, meilleur vpn, etc…).[/quote]
Un de mes serveurs est juste un serveur d’impirmante (486 SX 25MHz, 12M RAM et HD de 150M :slightly_smiling:):

[quote]$ cat /etc/debian_version
2.0
$ ls -l /b
$ uname -a
Linux bic 2.0.38 #6 sam jui 1 16:42:18 CEST 2000 i486 unknown
$[/quote]
Qui est d’une stabilité redoutable et qui est immuable :smiley:

Pour l’ajout de fonctionnalités, soit je backporte (typiquement clamav, exiscan, spamassassin) soit je profite d’une période de vacances pour mettre à jour. Ma stratégie dans ce cas consiste à faire le nouveau sources.list, puis à mettre à jour la libc6, 2-3 paquets fondamentaux (et dépendances donc) puis installation de la nouvelle fonctionnalité. J’ai fait cela depuis la hamm jusqu’à woody sans aucun souci jusqu’à présent mais si je regarde bien, j’ai des paquets hamms cohabitant avec des paquets woody. J’ai adopté cette stratégie depuis le passage de bo à hamm. J’ai un souvenir cauchemardesque de cette mise à jour (pas de apt-get, que dpkg ou dselect et une connexion par modem 28800 bauds (partagée sur 2 salles de 15 postes :slightly_smiling:)): Je n’ai pas réinstallé (je n’ai jamais réinstallé) mais l’upgrade sauvage avait posé tous les pbms en même temps et résoudre pluseiurs pbms mélangés n’est pas simple.

#11

[quote]
Pour l’ajout de fonctionnalités, soit je backporte (typiquement clamav, exiscan, spamassassin) [/quote]

Je m’y connais pas en serveur, alors je sais pas si ça te concerne ou pas (et tu connais sans doute déjà), mais juste au cas où, il existe le projet volatile :

Some packages aim at fast moving targets like spam filtering and virus scanning, and even via using updated virus patterns, this doesn’t really work for the full time of a stable release. The main issue of volatile is to allow system administrators to update their systems in a nice, consistent way[…]

volatile.debian.net/

#12

[quote=“ciol”][quote]
Pour l’ajout de fonctionnalités, soit je backporte (typiquement clamav, exiscan, spamassassin) [/quote]
(…)
volatile.debian.net/[/quote]Effectivement, c’est une source importante pour plusieurs paquets. Ce sont effectivement des backports incontournables pour les paquets qui doivent imperativement rester à la dernière version (av, antispam, etc), justement pour ceux que tu cites, fran…
Et AMA, ces paquets là méritent d’être mis à jour quotidiennement (même manuellement).

#13

quote="fran.b"Je n’ai pas réinstallé (je n’ai jamais réinstallé) [/quote]Moi, si: j’ai reinstallé ma config 32bits en 64 au bureau sur ma machine perso. Mais j’ai reinstallé ce qui passait de mon ‘dpkg --get-selections’ et mon etc et roule, ça m’a pris une heure.[quote=“fran.b”]mais l’upgrade sauvage avait posé tous les pbms en même temps et résoudre pluseiurs pbms mélangés n’est pas simple.[/quote]C’est pkoi j’installe un à un les màj de paquets qui me semblent dangereuses, avant de finir à la pelle en upgrade.

#14

[quote=“ciol”]…

volatile.debian.net/[/quote]

N’existe pas en woody (2 serveurs chez moi)…

#15

[quote=“fran.b”][quote=“ciol”]…

volatile.debian.net/[/quote]

N’existe pas en woody (2 serveurs chez moi)…[/quote]et si:
volatile.debian.net/debian-volatile/dists/

[quote]Welcome to volatile.debian.net

Please just use woody/volatile (…) with
deb volatile.debian.net/debian-volatile woody/volatile main contrib non-free
(…)[/quote]

#16

Merci de l’information, pourtant j’avais cherché à l’époque. Il faut dire que j’ai installé clamav depuis la version 0.3 je crois sur un serveur qui était encore en slink/potato je crois bien. Ça m’a permis d’apprendre à faire des paquets :slightly_smiling: