Forum Linux.debian/ubuntu Mise à jour

Posté par  .
Étiquettes :
0
17
nov.
2008
Bonjour,
Je n'arrive pas à trouver une méthode pour faire une mise à jour debian jusqu'à une date donnée. J'ai cherché un peu partout dans preferences, apt-get, dpkg mais rien de concluant.
Le but c'est d'avoir des serveurs identiques quelle que soit leur date d'installation.
La seule astuce c'est d'avoir une liste de paquets par dpkg --get-selections et de les réappliquer ensuite mais c'est moyen parce que si on ajoute le moindre paquet il va forcement arriver à la dernière version à moins d'aller voir à la main les dates des différentes versions dans le repository et d'ajouter le paquet avec sa version et encore il va y avoir le problème des dépendances.
En bref je cherche l'équivalent de :

apt-get upgrade/install paquet-truc --to-date=01/01/2008

  • # Re: Mises à jour Debian

    Posté par  . Évalué à 4.

    Salut,

    Je n'ai jamais entendu parler de la possibilité dont tu parles. En revanche, il doit être possible de réaliser ce genre de chose en utilisant ton propre dépôt : comme ça c'est toi qui maîtrise l'entrée des paquets à distribuer sur tes serveurs.

    A+
    JJD

    • [^] # Re: Mises à jour Debian

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

      J'ai surtout du mal à comprendre pourquoi tu veux que tes serveurs ne soient pas à jour, ce qui n'a rien à voir avec la date d'installation mais avec la date à laquelle tu fais
      apt-get update
      apt-get upgrade

      ce qui n'est pas forcément inutile en terme de sécurité, disons une foi par semaine ou plus en cas d'alerte.

      • [^] # Re: Mises à jour Debian

        Posté par  . Évalué à 2.

        Euh, là je parie ma chemise que tu n'as pas à gérer des serveurs en production ;)
        En bref, un serveur en production est testé et validé avec une version particulière de l'OS associée à une version particulière des applications qui tournent dessus et il est hors de question de faire des mises à jour 'à l'arrache' en espérant que tout va continuer à tourner comme avant.
        Quand les développeurs ont validé une appli sur un serveur de dev il faut installer le serveur de production à l'identique du serveur de développement ou au plus proche sinon on a droit à repasser par une phase de validation.
        Chaque nouvelle version de l'application passe par la phase de validation. Chaque évolution de l'OS aussi.
        Le serveur que tu mets à jour toutes les semaines s'appelle un serveur de test ou une machine perso si tu aimes les ennuis.
        Personnellement j'ai eu le cas d'une application (non fournie par debian) qui ne fonctionnait plus du tout après une mise à jour d'une debian etch (pour des histoires de dépendances de librairies).

        • [^] # Re: Mises à jour Debian

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

          Touché, tu m'as parfaitement cerné, et mon commentaire n'avait pas pour but de t'apprendre ton métier mais au contraire de mieux comprendre ton problème.
          Comme indiqué dans un commentaire plus bas ta démarche soulève des questions en matière de sécurité.
          .

    • [^] # Re: Mises à jour Debian

      Posté par  . Évalué à 1.

      Ouais, un dépot debian complet mono version ça pèse dans les 50-60 GB ;)
      Autrement oui c'est une solution que j'utilise par exemple avec redhat mais là un dépot complet c'est genre 3-4 GB donc c'est jouable.

  • # Snapshot

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

    Il existe un serveur de snapshot debian qui garde toutes les versions des différents paquets debian. Et petite fonction sympathique, il permet de définir un dépôt debian pour une date donnée : http://snapshot.debian.net/

  • # Master ?

    Posté par  . Évalué à 3.

    Le but c'est d'avoir des serveurs identiques quelle que soit leur date d'installation.

    Je ne sais pas non plus, mais as-tu songé à générer un master à la place ? Là, pour le coup, ce sera vraiment des machines identiques.

    • [^] # Re: Master ?

      Posté par  . Évalué à 2.

      Oui j'y ai songé mais d'une part ça me complique sérieusement le processus de déploiement (preseed) et d'autre part ça pose problème avec l'installation après coup d'autres paquets debian qui risquent d'entraîner des mises à jour de librairies non souhaitées voire des mises à jour en chaîne.

      • [^] # Re: Master ?

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

        La bonne manière de gérer cela t'a été fournie dans le premier commentaire :
        - tu constitues un miroir à un instant t avec certaines versions disponibles (susceptibles d'évoluer par la suite)
        - tu mets à jour tout ton parc à partir de ce miroir, qui reste donc le même tant que tu n'as pas fini ton déploiement
        - lorsque tu rencontres un souci lié aux paquets sur ton miroir, tu sélectionnes les paquets concernés et tu reprends les versions sur les miroirs officiels (en tenant compte des autres dépendances nécessaires...).
        - le mois d'après ou 3 mois après, tu remets à jour tout ton miroir, tu identifies les paquets qui ont changé et tu repars dans les joies du déploiement

        C'est une procédure lourde, ne tenant pas bien compte des mises à jour de sécurité (qui elles devraient passer, au moins pour les failles critiques au moins, après tests de non régression au besoin).

        • [^] # Re: Master ?

          Posté par  . Évalué à 2.

          Cf mon commentaire plus haut. Le problème de cette méthode c'est la taille du miroir en question.

          • [^] # Re: Master ?

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

            ah bah on n'a rien sans rien de nos jours :-)

            Par rapport à une liste de paquets, il est peut-être possible d'en obtenir les dépendances pour avoir un ensemble cohérent et ne rapatrier que ces paquets. Regarder du côté des options de apt-mirror peut-être
            http://apt-mirror.sourceforge.net/
            Cela te permettra déjà de constituer le miroir maître au moins.

            Cela m'étonne tout de même ta taille de 50 Go, tu prends les sources et plusieurs architectures ?

            • [^] # Re: Master ?

              Posté par  . Évalué à 1.

              Là j'ai etch + lenny + etch security + lenny security avec une seule architecture et les sources et ça pèse 107 GB.
              Mais l'idée peut-être de ne pas prendre les sources oui. Reste à savoir si je peux m'en sortir sans.

              • [^] # Re: Master ?

                Posté par  . Évalué à 1.

                L'un de nous a un problème sur son miroir car pour etch+lenny+sid en i386 et amd64 avec les sources, ca ne me prend "que" 88 GB et je ne pense pas que security prenne autant de place. Tu prend aussi les images iso ?

                Mon miroir est fait avec debmirror et ftp.fr.debian.org comme source.

          • [^] # Re: Master ?

            Posté par  . Évalué à 2.

            Un disque de 80 Go coûte 40 € HT.
            Et il n'est pas question de tout récupérer. On tombe facilement à moins de 10 Go.

            • [^] # Re: Master ?

              Posté par  . Évalué à 3.

              D'autant plus qu'il n'a pas besoin d'être rapide (exploité principalement depuis le réseau, par des processus automatiques et non des utilisateurs, occasionnellement et pas en permanence ...) ni sécurisé : s'il casse au bout d'un moment, les données qu'il y a dessus sont toujours accessibles depuis l'endroit où on les a téléchargées initialement. Même un disque externe en Firewire ou USB2 ferait l'affaire.

  • # figé les versions

    Posté par  . Évalué à 2.

    il me semblait qu'on pouvait figer la version d'un logiciel avec dpkg ou dselect

    du coup sur ton server de dev, tu installes les versions qui t'interessent puis tu "figes" les versions

    puis dpkg --get-selections pour sortir les paquets installés
    et enfin dpkg --set-selections pour les remettre sur le serveur en question

    m'enfin perso au boulot on fait un master

    en gros un debootstrap ou un chroot qui contient le systeme,
    puis on a un script ou deux pour generer une iso qui va faire 3 choses :

    1°) faire une tarball du chroot
    2°) generer l'iso avec l'installeur et la tarball

    3°) l'installeur lui fera la chose suivante :
    - partitionner/formater le disque dur (machine identique)
    - decompresser la tarball sur les partitions precedemment créées
    - se chrooter dans le nouvelle environnement
    - mettre à jour grub
    - rebooter

    (au passage ca ressemble à pas mal d'installeur,
    et l'installation d'une gentoo se fait de la meme maniere)

    • [^] # Re: figé les versions

      Posté par  . Évalué à 1.

      J'ai indiqué mes soucis avec la méthode get-selections / set-selections plus haut.
      Ta méthode marche mais ça ne correspond pas à notre façon de déployer les serveurs ici (preseed).
      Voir plus, haut, mon problème est quasi-résolu avec les snapshots.

      • [^] # Re: figé les versions

        Posté par  . Évalué à 2.

        ben avec preseed on lui donne pas une liste de paquet justement ?
        avec les numeros de version souhaitée...

        je peux me tromper aussi :-/

Suivre le flux des commentaires

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