Re: [SLIS] mise en place d'un repository
Le Mercredi 15 Mars 2006 20:14, Eric Mercier a écrit :
> Merci de vos réponses,
>
> Raphael Hertzog a écrit :
> >On Wed, 15 Mar 2006, Eric Mercier wrote:
> >>C'est là que je sollicite vos compétences :
> >>
> >>- y a t-il une meilleure solution ?
> >
> >Je retourne la question, qu'est-ce qui ne te satisfait pas là-dedans ?
> >Ton raisonnement m'a paru logique et la démarche aussi...
>
> Merci :=) mais je préférais avoir confirmation avant de lancer les
> "grosses" manoeuvres...
>
> Et il nous reste à bosser sur le mechanisme de validation ... D'oû
> d'ailleurs, la necessité d'avoir 3 branches à notre dépôt SLIS (en
> réponse à huji) pour pouvoir facilement mettre en place des serveurs de
> test ...
>
> >Oui sarge est mise à jour à chaque "révision" (3.1r2 étant la prochaine).
> >http://wiki.debian.org/DebianReleases/PointReleases
> >
> >Ces révisions incluent la plupart des mises à jour de sécurité et d'autres
> >mises à jour importante. On est très conservateur au niveau de ce qui est
> >accepté mais cela pourrait évoluer à l'avenir maintenant que le
> >responsable de ces mises à jour a changé (notamment en intégrant des
> >paquets de "volatile").
> >
> >Les mises à jour à venir sont disponibles dans les répertoires
> >"stable-proposed-updates" des miroirs.
> >
> >Globalement les MAJ de sécurité ne doivent rien casser, mais il est déjà
> >arrivé que certains effets de bords soient gênants, cf la mise à jour de
> >sudo qui fait perdre tout l'environnement ou la MAJ du noyau qui va
> >nécessiter une mise à jour de l'installateur.
>
> Effectivement, tout cela nous conforte dans le principe indispensable de
> validation de ces mises à jour ! (et pour sarge et pour security)
>
> Nous souhaitons faire fonctionnel et *beau* quitte à retarder légèrement
> la mise en production, c'est pourquoi vos avis sont très importants !
>
> Cordialement
>
> Eric Mercier
Pour la validation, il me semblerai bon de faire une maquette de ce vous allez
déployez. Je m'explique :
Vous prenez 2 ou 3 machines.
* Une jour le rôle de dépôt des mises à jour,
* Une deuxième joue de rôle d'un poste client utilisé par un administrateur
s'il est différent des autres postes de travail,
* Une troisième pour simuler un poste de travail standard.
S'il y a plus de configuration alors c'est un poste par type de conf.
Il faut aussi une autre machine configurée comme celle qui joue le rôle de
dépôt.
Après il ne reste plus qu'a :
1 - Vérifier les package un à un (clés PGP, package cassés, ...)
2 - Tester l'installation des packages un à un et valider les fonctionnalités
mises en oeuvre par le poste mis à jour
3 - Si tous c'est bien passé, alors mettre à jour la machine qui joue le rôle
de dépôt (Et oui, faut pas l'oublier celle-là)
4 - Tester si le système de mise à jour fonctionne encore....
Et là si tout fonctionne, alors c'est que ça doit passer...
Ma petite contribution à la cause ;)
Librement
Laurent
--
Laurent
Registered as user #301590 with the Linux Counter
Reply to: