Journal Debian: comment en sortir ?

Posté par  .
Étiquettes :
0
4
avr.
2005
Je précise avant toute chose qu'il ne s'agit aucunement ici de troller.

Cela n'a échappé à personne, la Debian n'a pas été mise à jour depuis (beaucoup trop) longtemps.
Je désire donc passer mon serveur maison (qui fait tout et plus encore) à une autre distribution, car j'ai besoin de fonctionnalités qu'on ne trouve ni dans la woody, ni dans des "backports" raisonnablement maintenus. Par ailleurs, s'agissant d'un serveur connecté en 24/7 sur internet, je souhaite conserver une certaine stabilité. Je pense installer une WBEL ou une CentOS.

D'un autre coté, je n'ai pas envie de perdre le temps considérable investi dans la configuration et la paramétrage de la bête (postfix, amavis, clamav, spamassassin, apache, firewall, etc.).

Quelqu'un a-t-il déjà eu une expérience de migration réussie ? Des conseils ? Des pointeurs ?

Merci par avance !
  • # Installeur <> paquets

    Posté par  (site web personnel, Mastodon) . Évalué à 1.

    Cela n'a échappé à personne, la Debian n'a pas été mise à jour depuis (beaucoup trop) longtemps.

    Pour l'installeur oui, mais les paquets sont régulièrement mis à jour.
    J'ai une Debian unstable pour mon serveur depuis 2 ans, je n'ai jamais eu un seul pépin et je fais des mises à jours très régulières (au moins 3 ou 4 fois par semaine). Le nom "unstable" peut faire peur, mais c'est très stable ;)

    WeeChat, the extensible chat client

    • [^] # Re: Installeur <> paquets

      Posté par  (site web personnel) . Évalué à 6.


      > Le nom "unstable" peut faire peur, mais c'est très stable ;)


      Humm ? Le nom unstable indique que c'est.... unstable. - au sens de Debian -

      Maintenant, toutes les distributions n'ont pas les mêmes critères de qualité. Certaines veulent être stables avant tout, et c'est long. D'autres veulent être raisonnablement stables (et c'est moins long). D'autres encore veulent être récentes. Une fois ces critères posés, chacun appelle "stable" ce qui lui convient.
    • [^] # Re: Installeur <> paquets

      Posté par  (site web personnel, Mastodon) . Évalué à 2.

      On a un serveur testing et il n'est plus stable à cause d'un bug dans apache ou openssl ou squirrelmail ou php-imap ou libc ou un peu dans tous. Enfin bref, /etc/init.d/apache reload ou restart fait planter apache avec des "child pid ##### exit signal Segmentation fault (11)" plein dans le error.log. C'est très ennuyeux.

      Je passe mon temps à éplucher les rapports de bugs de Debian mais sans avoir trouvé de solution. Je suis juste rassuré que je ne suis pas le seul à rencontrer ce problème.

      Le truc bien avec stable, c'est que tu n'es pas obligé de faire 3 à 4 mises à jour par semaine, c'est plutôt confortable.
      • [^] # Re: Installeur <> paquets

        Posté par  . Évalué à 4.

        > On a un serveur testing et il n'est plus stable à cause d'un bug dans apache ou openssl ou squirrelmail ou php-imap ou libc ou un peu dans tous.

        pour être plus précis, tu devrais dire :
        On a un serveur testing et il n'est plus stable car NOUS avons fait une mise à jour sans prendre garde aux bugs éventuels annoncés sur le BTS Debian ou par apt-listbugs.


        > Je passe mon temps à éplucher les rapports de bugs de Debian

        faut les lire avant une mise à jour...
        • [^] # Re: Installeur <> paquets

          Posté par  (site web personnel, Mastodon) . Évalué à 2.

          en fait, ce n'est pas exactement ça: on a installé un serveur testing il y à moins de 3 semaines avec les paquets du moment..... sans prendre en garde les annonce de BTS debian ou apt-listbugs.

          Sinon je prends bonne note de ta remarque.
    • [^] # Re: Installeur <> paquets

      Posté par  (site web personnel) . Évalué à 3.

      Sous debian, le qualificatif "stable/unstable" correspond non pas a la stabilite des programmes, mais a la stabilite des paquets: les releases unstable ont des paquets qui changent souvent, alors que les releases stable rarement.

      La debian sid "unstable" est donc relativement stable au sens que ses programmes ne plantent pas tout le temps.

      http://l-lang.org/ - Conception du langage L

      • [^] # Re: Installeur <> paquets

        Posté par  . Évalué à -10.

        Sous debian, le qualificatif "stable/unstable" correspond non pas a la stabilite des programmes, mais a la stabilite des paquets.

        C'est bien, Debian arrive donc à faire des paquets pas stables à partir de logiciels stables. Balaise...

        La debian sid "unstable" est donc relativement stable au sens que ses programmes ne plantent pas tout le temps.

        relativement, pas tout le temps... ça fait rudement envie.
        • [^] # Re: Installeur <> paquets

          Posté par  . Évalué à 7.

          > C'est bien, Debian arrive donc à faire des paquets pas stables à partir de logiciels stables. Balaise...

          eh oui, un paquet (deb ou rpm d'ailleurs) n'est pas juste un "tar c" du logiciel, c'est un tout petit peu plus évolué...

          > relativement, pas tout le temps... ça fait rudement envie.

          "unstable" = "relativement stable"...
          on parle de la version "unstable" donc... pas de la stable...
          dire qu'unstable est relativement stable, je vois pas trop ce qu'il y a de choquant...

          pffff... un troll et je saute dedans les deux pieds en avant... désolé...
  • # Sarge

    Posté par  (site web personnel) . Évalué à 7.

    Je serais toi, j'utiliserais sarge.
    Même si elle n'est pas considérée stable, et à la condition que tu y trouves tout ce dont tu as besoin, je le tenterais. Cà te fera économiser pas mal de temps il me semble.

    De plus, et je l'espère vraiment, elle devrait - finalement - enfin peut-être, disons que j'ai un peu d'espoir, mais enfin rien n'est moins sûr, en gardant toute retenue, et en prenant cette information avec des pincettes - sortir bientôt. Donc tu peux espérer une période transitoire plutôt courte, enfin pas trop longue. Cela me parait être un bon compromis.

    Perso, sur ma machine sous woody, j'utilise les sources du noyau de sarge (vu que les sources des noyaux de woody n'ont pas vraiment l'air maintenus (ou me trompe-je?). Mais c'est vrai que ton mes besoins sont comblés par woody. Il ne me manque que subversion et une version plus récente de python...
    • [^] # Re: Sarge

      Posté par  . Évalué à 4.

      Et pour les mises a jour se secu pour sarge ? ( la source secu n'existe toujours pas )
      Parce que si il faut attendre 2 semaines , le temps que le paquet arrive de SID , je vois vraiment pas l'interet de mettre une sarge sur un serveur 24/24 , un truc de prod donc .
      • [^] # Re: Sarge

        Posté par  . Évalué à 1.

        deb http://security.debian.org/(...) sarge/updates main contrib non-free

        moi j'ai une source pour les maj de secu .. . ..
        • [^] # Re: Sarge

          Posté par  . Évalué à 4.

          Bon dakor, j'ai verifié le contenu de cette source seulement apres avoir posté le commentaire :> il *semblerait* que cette source soit a peu pres completement _vide_ pour ne pas dire qu'elle ne sert .. . . a rien :]

          mes excuses
      • [^] # Re: Sarge security

        Posté par  . Évalué à 3.

        Déjà les mises à jour security de sid arrivent plus vite dans testing que les 2 semaines habituelles.
        Et il y a maintenant un embryon de debian security team pour testing qui liste les bugs et les versions de sid correspondantes: http://secure-testing.alioth.debian.org/(...) ( mais le serveur alioth a des problemes de temps en temps...)
        Leur objectif final est bien-sûr de tenir à jour le
        deb http://security.debian.org/(...) testing/updates main contrib non-free
        qui existe déjà.
        J'explique sur ma page comment installer temporairement un paquet de sid sans causer trop de problèmes:
        http://free2.org/d/(...)
    • [^] # Re: Sarge

      Posté par  (site web personnel) . Évalué à 1.


      elle devrait - finalement - enfin peut-être, disons que j'ai un peu d'espoir, mais enfin rien n'est moins sûr, en gardant toute retenue, et en prenant cette information avec des pincettes - sortir bientôt.


      Voir le journal deux lignes en dessous :http://linuxfr.org/~tinodeleste/17696.html(...)
  • # OpenBSD?

    Posté par  (site web personnel) . Évalué à 3.

    Pour ma part, je suis en train de procéder également de la sorte (en test) pour une migration Debian Woody vers OpenBSD.

    Je n'en suis qu'en phase de test (le serveur de prod' tourne tjrs. sous Debian Woody), et rédige peu à peu ce qui se passe au sujet de la bête. Mais pour ma part, avec un serveur Apache + Postgresql + PerlCGI, la migration vers OpenBSD s'est passée sans encombre. J'ai juste dû un peu me renseigner en ce qui concernait le fonctionnement en mode chroot d'Apache.

    Sur un troisième serveur de test, j'évalue aussi une Gentoo pour le même but. A l'heure actuelle, ma conclusion est de la sorte : Gentoo n'est pas envisageable directement sur un serveur de production, mais par contre, si on dispose d'une deuxième machine de test pour mettre à jour les "paquets" et les tester, puis une fois le tout réussi, les transférer sur le serveur de production, c'est tout à fait envisageable. C'est un comportement qu'on pourrait appliquer également à une Sarge, mais auquel OpenBSD et Debian Woody ne m'avait pas habitué (à tord?).
    • [^] # Re: OpenBSD?

      Posté par  (site web personnel) . Évalué à 6.

      oui mais avec OpenBSD et son cycle de 6 mois c'est la maj ou la réinstall obligatoire tous les 6 mois....pas glop pour un serveur de prod !
      ils ne font pas le maintien des anciennes releases donc t'est obligé d'upgrader !
      • [^] # Re: OpenBSD?

        Posté par  (site web personnel) . Évalué à 3.

        En effet, mais tout dépend de l'uptime requis pour ce type de serveur.
        Dans la boîte où je suis en train de mener ces tests, tous les serveurs sont dédoublés, et se synchronisent l'un l'autre, de manière à ce qu'un serveur prenne le relais de l'autre en cas de problème (matériel ou autre).

        Lors de l'upgrade, nous fonctionnons de la sorte :
        - test de la version de prod' durant 15 jours mini' (sur une troisième machine de test, upgradée par exemple de la version X à la version Y, soit avec un apt-get, mais maintenant avec la procédure d'upgrade d'OpenBSD)
        - lorsque les applications sont qualifiées, retrait d'un des 2 serveurs de prod' du réseau, et mise à jour via l'upgrade (en croisant les doigts que l'autre serveur ne tombe pas en rade pendant ce temps)
        - mise en route du serveur upgradé
        - basculement transparent du trafic réseau sur le serveur upgradé
        - mise à jour de l'autre serveur
        - mise en route du deuxième serveur upgradé

        Ce mode de mise à jour est défini pour tous nos serveurs, que ce soit du Windows, de l'OpenBSD (déjà utilisé en prod' ici depuis le 3.4, mais pas encore massivement déployé), ou du Linux Debian Woody.

        Mais c'est vrai que ce que dit ce document :
        http://www.openbsd.org/faq/upgrade36.html(...)

        N'est pas très encourageant : c'est upgrade en effet obligatoire.
  • # Réponse

    Posté par  (site web personnel) . Évalué à 1.

    Passer de woody à sarge :

    http://debian-administration.org/?article=95(...)

    La migration d'une debian à une autre est facile, c'est stable et maintenu, on a bien plus que les backports pour woody. Donc ça devrait résoudre correctement le problème de ce journal.
    • [^] # Re: Réponse

      Posté par  . Évalué à 0.

      non, c'est pas stable parce que ça bouge. Une maj peut changer le comportement d'un programme, casser un script, introduire des gros bugs (les maj d'une stable aussi, mais c'est moins risqué et plus facile à gérer vu que ça bouge beaucoup moins)... on ajoute l'absence de vrai suivi de sécurité et on conlu que personne de serieux ne mettra une testing en production, aussi stable (dans le sens ça marche) soit-elle.
      • [^] # Re: Réponse

        Posté par  (site web personnel) . Évalué à 7.

        Faudrais savoir, avoir des trucs a jour ou des trucs stables....
        Bonjour monsieur, je voudrais un truc sécurisé, moderne, a jour, et surtout qui ne change jamais, mais avec les mises a jour de sécu....
        • [^] # Re: Réponse

          Posté par  . Évalué à 3.

          Moi je demande rien, je rappelle pourquoi on utilise pas de version de dev en production.
          Maintenant, y a surment un juste milieu entre une nouvelle version tout les 5 ans et risquer d'exploser son serveur tout les 2 jours, enfin j'imagine =)
    • [^] # Commentaire supprimé

      Posté par  . Évalué à 1.

      Ce commentaire a été supprimé par l’équipe de modération.

      • [^] # Re: Réponse

        Posté par  (site web personnel) . Évalué à 0.

        En même temps, l'utilisation de Firefox et Thunderbird sur une machine antérieure au P2 ne relèverait-il pas du pur masochisme ? Et Mozilla sur un 486 ça me paraît encore pire.

        Je dis ça, mais à vue de nez, je ne vois pas de navigateurs web relativement récents et suffisemment légers pour fonctionner là dessus. Opera peut être, mais sépalibre...
        Konqueror, ou Epiphany à la rigueur, mais utiliser Gnome ou KDE sur une vieille machine c'est un coup à devenir chauve avant l'heure...

        Mais après tout, les applications pour lesquelles il est crucial de garder une compatibilité pré-i686 ne sont elles pas spécifiques et probablement pas liées au Desktop ?
  • # Ubuntu ?

    Posté par  . Évalué à 1.

    Personne n'a encore osé prononcer ce mot ? Ubuntu ?
    En tout cas, mon serveur tourne sous Ubuntu depuis Octobre/Novembre et franchement, aucun problème ...
    Maintenant, tout est question de goût, et je sais que ce n'est pas la vocation première d'Ubuntu, mais comme ça fonctionne, pourquoi s'en priver ?
  • # Pas une réponse, ou presque !

    Posté par  . Évalué à -7.

    Je suis vraiment déçu.

    Merci quand même à celui qui m'a conseillé de passer à OpenBSD, c'est le seul à ne pas avoir été complètement hors sujet.

    Dois-je en déduire qu'il n'y a personne pour m'aider ou pour répondre à ma question ?
    • [^] # Re: Pas une réponse, ou presque !

      Posté par  . Évalué à 6.

      > Dois-je en déduire qu'il n'y a personne pour m'aider ou pour répondre à ma question ?

      Tu veux l'impossible. Tu veux différent de Debian mais tu veux Debian. Il n'y a pas de solution à ça.

      Il y a toujours moyen de s'organiser. J'utilise Fedora par exemple. Les mises à jours automatiques ne marchent pas toujours comme espérées. Donc, je fais des installations fraiches toutes les six mois. Avec un peu d'organisation j'arrive à faire ça relativement vite. En gros, une journée pour basculer de la FC version n à la version n+1.

      Donc, avec un peu de bonne volonté tu peux passer à ce que tu veux comme distribution. Mais tu ne veux pas. Donc restes sous Debian.
    • [^] # Re: Pas une réponse, ou presque !

      Posté par  (site web personnel) . Évalué à 5.

      Précise peut-etre mieux ta question. Question précise, réponses précise...
      • [^] # Re: Pas une réponse, ou presque !

        Posté par  . Évalué à 0.

        Je l'ai fait plus bas, mais je pense que ça ne sert à rien, quand je poste je suis auto-noté à -1.... probablement à cause du commentaire noté à -5.

        Je ne sais pas trop quoi penser de ce site, je l'avoue... ça fait des années que je viens, et ça a changé je trouve, et pas en bien. J'ai l'impression que c'est plein de haine maintenant.... J'avais pourtant précisé dans le journal que je ne voulais pas troller non ? Alors pourquoi ça s'est barré en sucette illico ? Et toujours pratiquement aucune réponse à ma question.... Les mecs qui ont migré depuis Debian, ils sont juste interviewés en contre jour avec leur voix masquée, c'est ça ? C'est la honte des temps modernes de changer de distribution ?
        • [^] # Re: Pas une réponse, ou presque !

          Posté par  (site web personnel) . Évalué à 0.

          C'est la honte des temps modernes de changer de distribution ?
          Ouais, codons au lieu de réinstaller !
        • [^] # Re: Pas une réponse, ou presque !

          Posté par  (site web personnel) . Évalué à 3.

          C'est inconcevable que personne ne t'ai donné de réponse tout simplement parceque personne n'en a à te donner ?

          Tu demandes quand même un retour d'expérience sur un truc pas banal...
          Sur les serveur pas important on prends le temps de tout réinstaller from scratch pour changer complètement de distrib. Sur les serveurs en prod ou il ne doit pas y avoir d'interruption de service prolongé, et bien personne ne s'amuse à faire ce que tu demandes.
    • [^] # Re: Pas une réponse, ou presque !

      Posté par  (site web personnel) . Évalué à 3.

      Ba a part sauvegrader ton /etc et a prier pour qu'il fonctionne comme ca, ce dont je doute, je be vois pas trop quoi te proposer.

      Quel que soit la distro que tu choisiras, tu devras revoir ta conf ne serait ce qu'un minimum genre :
      - verifier que les fichiers de conf sont au meme endroit
      - verifier qu'ils sont compatibles avec une version plus recente du logiciel
      - verifier en vrac : droits des fichiers / log / chroot / group / login /comptes logiciel
      - verifier la presence des differentes options

      Perso je te conseillerais bien Gentoo.
      Tu peut preciser la version des logiciel que tu veux si je ne m'abuse et par consequent suivre les mises a jours d'une version du logiciel juste au niveau secu.
      Je l'utilise sur mes machines pro et perso avec succes. Il faut quand meme faire attention lors des mises a jour à la modifications des fichier de conf (eviter les etc-update tot le mation ou tard le soir est recommandé). Il est cependant possible de les proteger via un fichier de conf.

      Mais pour le probleme en lui meme qui concerne la migration il n'y a pas a mon avis de recette miracle.
      • [^] # Re: Pas une réponse, ou presque !

        Posté par  (site web personnel) . Évalué à 2.

        Quel que soit la distro que tu choisiras, tu devras revoir ta conf ne serait ce qu'un minimum genre :
        - verifier que les fichiers de conf sont au meme endroit
        - verifier qu'ils sont compatibles avec une version plus recente du logiciel
        [...]


        Perso', ce que j'ai le plus apprécié avec Debian, lors du passage à Woody depuis Potato, ce fut la gestion tout en douceur de ce problème : je n'ai eu à me concentrer sur les fichiers de conf' que pour très peu d'applications, Debconf (si je ne dis pas de bêtise, je suppose que c'était lui) gérant tout cela à merveille, en douceur.
        Les seules applications qui ont posé problème : Postgresql (à cause d'un changement de la gestion des fichiers, et donc l'obligation de dumper les bases et les recréer), et Inn (à cause d'un changement de la gestion du spool).
        • [^] # Re: Pas une réponse, ou presque !

          Posté par  (site web personnel) . Évalué à 2.

          Oui mais tu es rester sur la meme distro (avec une version differente mais la meme distro). Perso je parle de passage d'une distro a une autre.
          D'autant plus pour lui qu'il veux passer d'une woody qui est freezé depuis un certain temps a une distro plus recente ce qui rsique d'inclure de nombreux changement de version de logiciels.
          • [^] # Re: Pas une réponse, ou presque !

            Posté par  (site web personnel) . Évalué à 2.

            D'autant plus pour lui qu'il veux passer d'une woody qui est freezé depuis un certain temps a une distro plus recente ce qui rsique d'inclure de nombreux changement de version de logiciels.

            C'est clair que je ne m'y risquerais pas sur un serveur de production avant d'avoir testé sur un serveur de test!
            Même lors de cette migration (Potato -> Woody), j'ai attendu que Woody soit déjà considérée comme stable (au sens Debian du terme) pendant 3 mois avant de tenter le grand saut : je me souviens encore des premiers rapports qui signalaient des problèmes de migration. Alors quand on voit l'attention qu'accorde Debian à la propreté d'une mise à jour entre deux versions stables, je ne m'y risquerais même pas entre une stable et une en préparation de stabilisation.
      • [^] # Re: Pas une réponse, ou presque !

        Posté par  (site web personnel) . Évalué à 2.

        > (eviter les etc-update tot le mation ou tard le soir est recommandé)

        Et en retour de virée aussi...
        Sinon l'idéal c'est de laisser tomber etc-update pour dispatch-conf qui est bien plus puissant et inclut un système d'archive avec rcs.
        Bien utile quand on a oublié la règle d'or. :)
      • [^] # Re: Pas une réponse, ou presque !

        Posté par  . Évalué à 1.

        Je te remercie de ta réponse.

        En fait mon problème, en essayant de le préciser, c'est que la Debian a (notamment) une structure de fichiers de configuration bien différente de la plupart des autres distributions, et notamment des distributions basées sur RedHat (ce qui en inclus un paquet, Mandrake compris - oui je sais Mandrake n'est plus basée sur RedHat).

        Par conséquent, je me demandais si quelqu'un d'autre avait eu une telle expérience réussie, et si il avait des conseils/pointeurs/liens à me donner.

        En détail:
        - installation via "upgrade" en live via yum/apt ? ou au contraire sauvegarde de tout /etc et réinstallation depuis le début de la nouvelle distro, en la paramétrant avec les fichiers sauvegardés ?
        - des problèmes à craindre avec les données (mailboxes, etc) ?
        - des problèmes avec le boot loader (lilo -> grub) ?
        - ...

        Je pourrais toujours m'en sortir tout seul j'imagine, mais si quelqu'un s'est déjà pris de grosses gamelles, j'aimerais autant le savoir afiin de ne pas rééditer les mêmes.... Et puis ça me servira aussi pour la suite, car j'aurai surement 5-6 autres serveurs à "convertir" de Debian vers autre chose (comme je disais probablement vers un clone RHEL).

        Sinon, pour Gentoo, je peux pas, c'est sur un Via C3, donc la compilation on oublie, et distCC pas possible.

        Je m'excuse aupès des Debianneux pour avoir oser leur pointer que leur distro chérie ne me convient pas, promis, c'est de ma faute, je le referai plus, je suis trop con. Mais merci quand même de m'aider ;-)
    • [^] # Re: Pas une réponse, ou presque !

      Posté par  . Évalué à 2.

      Sur LinuxFr les Debianeux sont une majorité pas franchement silencieuse qui ne supporte pas que l'on ne veuille plus de leur distro fétiche.

      Cela dit en restant technique. Je suis devant un problème similaire. Sarge n'étant toujours pas stable (et pas près de l'être!) je doit migrer mon serveur de VoIP de la perpetuelle Beta a autre chose pourvu que se soit officielement stable !!

      Hélas Debian est comme toutes les autres distributions (différentes des autres!!). Sa configuration est particulière. Tout changement de distribution surtout pour un serveur de production ne peut (ne doit !) être automatique. Alors bon courage.

      Pour ma part je vais d'abord faire un éssai a blanc sur Fedora et si cela marche je passerai à RHEL



      • [^] # Re: Pas une réponse, ou presque !

        Posté par  . Évalué à 1.

        J'ai eu le même problème. debian woody ce faisant vielle il à fallut que je cherche une solution pour migrer.

        Mon choix c'est portée sur gentoo.

        Le seul problème de gentoo c'est les mises à jours de paquet qui sont à mon gout trop fréquent. Il faut donc faire attention à ce que l'on fait.

        Mais si une mise à jour ne marche pas, il est trés facile de revenir à la verison précédente.

        En plus rien ne vous empeche de forker l'arbre de portage ainsi vous gérerez vous même vos mises à jour.

        D'ailleurs j'ai une idée depuis un petit moment faire un fork de l'arbre de portage et faire la maitenance de sécu et ce synchroniser avec l'arbre offciel tous les 6 mois.

        Qu'en pensez vous ?
        • [^] # Re: Pas une réponse, ou presque !

          Posté par  (site web personnel) . Évalué à 2.

          D'ailleurs j'ai une idée depuis un petit moment faire un fork de l'arbre de portage et faire la maitenance de sécu et ce synchroniser avec l'arbre offciel tous les 6 mois.

          C'est ce que je fais pour ma part en ce moment pour les serveurs que nous envisageons de passer sous Gentoo.

          En gros, un "freeze" à une date t.
          Si un bug de sécurité ou autre (critique) apparaît, mise à jour de cette version "freezée" et déploiement sur les serveurs après tests, voire nouvelle upgrade (via le processus que j'explique plus haut) dans le cas où trop de dépendances soient touchées (noyau ou libc par exemple).
        • [^] # Re: Pas une réponse, ou presque !

          Posté par  (site web personnel) . Évalué à 4.

          Rien n'empêche non plus de participer à la stabilisation de Sarge...
      • [^] # Re: Pas une réponse, ou presque !

        Posté par  (site web personnel) . Évalué à 3.

        Cela dit en restant technique. Je suis devant un problème similaire. Sarge n'étant toujours pas stable (et pas près de l'être!) je doit migrer mon serveur de VoIP de la perpetuelle Beta a autre chose pourvu que se soit officielement stable !!

        Pour rebondir sur une autre remarque évoquée dans ce journal : qu'est ce qui te fait dire qu'une autre distribution qualifiée de stable serait comparable avec une Debian Stable?
        La Debian Sarge peut, à certains égards, être qualifiée de stable si on prend les critères d'autres distributions. Le seul "détail" qui me gènerait dans un environnement de production : le non-suivi de la sécurité (du moins si j'en crois le site web de Debian), alors qu'est souvent le cas pour d'autres distributions.
        • [^] # Re: Pas une réponse, ou presque !

          Posté par  . Évalué à 3.

          Je tiens à mettre les choses au point :

          Sarge est concernant les plantages surement stable.
          MAIS en ce qui concerne les paquets et configurations Sarge est encore en mouvement (donc INSTABLE au mieux PAS STABLE)

          Concrètement (et ceci n'est surement qu'un exemple):

          En Decembre 2004 l'option de boot linux26 installait le kernel linux-2.6.8-1.....
          En Février 2005 la même option installait :
          linux-2.6.8-smp-...... En clair le kernel multi-processeur, que l'on en ait ou pas....

          Ce genre de surprise rend Sarge inutilisable en production (surtout dans une grosse boite ou le parc de machines ne se limite pas à 2 ou 3 serveurs dans la cave.....




    • [^] # Re: Pas une réponse, ou presque !

      Posté par  . Évalué à 0.

      tu peux tenter une migration vers ubuntu, en touchant juste à ton souce.list, mais ne t'attend pas à des miracles, surtout sur une machine de prod... La sauvegarde de /etc/, et peut-être de /var/www, /usr/lib/cgi-bin, /var/lib/mysql, etc. est de toute façon fortement conseillée. Ne peux-tu pas installer une nouvelle machine, migrer les données, vérifier que tout marche, et ensuite basculer les IPs ?
    • [^] # Re: Pas une réponse, ou presque !

      Posté par  . Évalué à 1.

      Il y a 6 mois environ, j'ai migré ma passerelle-serveur_a_tout_faire chez moi de Mandrake 9.1 (qui n'était plus maintenue) en Gentoo.
      Je n'ai eu aucun pb, particulier. J'ai même pu faire l'installation depuis mon ancien os (=> coupure minimale).

      Oui c'est un peu long de compiler au depart, ensuite il suffit de mettre à jour dans les cas suivant :
      - pour la secu (glsa-check est ton ami)
      - les bugs constatés dans le fonctionnement
      - les besoins de fonctionnalités

      Sur un serveur web par exemple, le nombre de packages est limité et on ne fait pas bcp de mise à jour finalement.

      Et quand bien même. Sur ma station la liste des trucs que j'ai à mettre à jour fait plus de deux pages, et alors ! Franchement, passer de la version x.x-r1 à la r2 parce que l'option truc-machin marche pas je m'en tape un peu. Et au pire, si j'ai besoin d'un gros truc (xorg, oo, kde) je compile la nuit et voila.

      Au final c'est quand même sympa de profiter des nouveautes en stable assez vite après leurs sorties quand on en a besoin (ie firefox à jour 15 jours après la sortie).

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.