Re: Conseils pour un dépôt Debian interne
Bonjour,
Je reprends ce thread car, si techniquement, ça ne pose pas beaucoup de
problème, au niveau organisationnel, j'avoue ne pas trop savoir comment
procéder.
Je suppose que vous êtes nombreux à gérer des serveurs Debian en
production et à devoir les mettre à jour.
Faites-vous cela à partir des repository officiels ? Ou à partir de
dépôts internes ?
Comment gérez-vous les changements les versions (tests préalables) ?
Les mises à jour de sécurité ?
Ainsi, si je pars du principe que j'héberge un dépôt en interne (ne
serait-ce que pour éviter que tous les serveurs sortent sur Internet),
est-ce que vous faites systématiquement les mises à jour de sécurité
sur vos serveurs ?
Et quand une nouvelle version de PostgreSQL sort (exemple, passage de
la 9.1.3 à la 9.1.4), comment gérez-vous cette mise à jour ?
Merci d'avance.
David.
Le Thu, 5 Apr 2012 22:22:21 +0200,
Bzzz <lazyvirus@gmx.com> a écrit :
>On Thu, 5 Apr 2012 20:38:59 +0200
>David BERCOT <debian@bercot.org> wrote:
>> Bon, il faut que je regarde comment il fonctionne...
>
>Il-y-a qq bons HOWTOs sur le net pour la conf; avec sûrement qq
>modifs à faire pour que ça colle à tes besoins, mais c'est
>relativement facile (du temps de potato, il fallait compter ~38GB
>par branche, une fois le ménage fait).
>
>> >Heu, on parle bien d'un repo pour les SERVEURS là, hein?
>>
>> Tout à fait. Mais ce que j'appelle "testing", ce n'est pas Debian
>> Testing mais une zone de validation de notre côté avant la mise à
>> disposition pour les serveurs...
>
>Ah, ok, alors c'est une test area.
>
>> Quand il y a des mises à jour, même sur le repository "stable", il
>> faut d'abord qu'on valide que ça n'a aucun impact sur nos applis.
>> De ton côté, sur les serveurs, tu fais directement les mises à jour
>> fournies par Debian ? Sans validation préalable ?
>
>Wai, mais je n'ai pas 50 servers qui tournent avec des applis
>maison non-plus; les seuls endroits où ça pourrait bloquer sont
>AMA java et/ou des libs particulières de bas niveau.
>
>>
>> Difficile de faire sans backports pour certains besoins, PostgreSQL 9
>> par exemple...
>
>Effectivement, il te faut une zone de test parce que même ces
>backports ont subis des évolutions depuis leur portage.
Reply to: