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 JJD . Évalué à 4.
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 Nitchevo (site web personnel) . Évalué à 3.
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 mururoa69 . Évalué à 2.
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 Nitchevo (site web personnel) . Évalué à 2.
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 mururoa69 . Évalué à 1.
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 peck (site web personnel) . Évalué à 4.
[^] # Re: Snapshot
Posté par bat13 . Évalué à 1.
deb http://snapshots.debian.net/archive/xxxx/yy/zz/debian stable main contrib non-free
deb http://snapshots.debian.net/archive/xxxx/yy/zz/debian-securi(...) stable/updates main contrib non-free
ensuite, un apt-get update, apt-get install etc ...
[^] # Re: Snapshot
Posté par mururoa69 . Évalué à 1.
[^] # Re: Snapshot
Posté par bat13 . Évalué à 2.
deb http://snapshot.debian.net/archive/xxxx/yy/zz/debian stable main contrib non-free
deb http://snapshot.debian.net/archive/xxxx/yy/zz/debian-securit(...) stable/updates main contrib non-free
(sans s après snapshot)
Où xxxx est l'année,
yy est le mois
zz est le jour
que tu souhaites pour ton dépôt
[^] # Re: Snapshot
Posté par mururoa69 . Évalué à 1.
Reste 1% que je peux faire moi-même avec un peu de temps et d'efforts.
T'avais trouvé l'information sur ce serveur où ?
C'est dingue, on rentre n'importe quelle date et ça marche ...
[^] # Re: Snapshot
Posté par bat13 . Évalué à 1.
J'apprends plein de choses par ce biais là ;-)
[^] # Re: Snapshot
Posté par bat13 . Évalué à 1.
J'ai cependant eu du mal à joindre le site quelques fois.
# Master ?
Posté par Obsidian . Évalué à 3.
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 mururoa69 . Évalué à 2.
[^] # Re: Master ?
Posté par BAud (site web personnel) . Évalué à 4.
- 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 mururoa69 . Évalué à 2.
[^] # Re: Master ?
Posté par BAud (site web personnel) . Évalué à 3.
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 mururoa69 . Évalué à 1.
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 pi6Lohe . Évalué à 1.
Mon miroir est fait avec debmirror et ftp.fr.debian.org comme source.
[^] # Re: Master ?
Posté par Kerro . Évalué à 2.
Et il n'est pas question de tout récupérer. On tombe facilement à moins de 10 Go.
[^] # Re: Master ?
Posté par Obsidian . Évalué à 3.
# figé les versions
Posté par NeoX . Évalué à 2.
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 mururoa69 . Évalué à 1.
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 NeoX . Évalué à 2.
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.