Bonjour,
David.
Bonjour,
David.
Bonjour,
David.
Sachant que je ne suis certainement pas le premier à me poser ces
questions, je me suis dit que certains d'entre-vous auront certainement
des conseils à me donner sur ce type de démarche ;-)
Sachant que je ne suis certainement pas le premier à me poser ces
questions, je me suis dit que certains d'entre-vous auront certainement
des conseils à me donner sur ce type de démarche ;-)
Sachant que je ne suis certainement pas le premier à me poser ces
questions, je me suis dit que certains d'entre-vous auront certainement
des conseils à me donner sur ce type de démarche ;-)
A priori, j'ai prévu deux branches, l'une, stable (pas besoin de
développer) et l'autre, testing, qui servira à valider de
nouveaux paquets avant de les mettre dans stable.
Maintenant, je me demande comment alimenter au mieux ces deux
branches car plusieurs outils sont disponibles comme reprepro
ou apt-mirror, voire de façon "manuelle". Il y a aussi les
aspects "sécurité" et "backports" par exemple...
Enfin, quand la version stable évolue (changement de version
majeure par exemple), comme gérer tout ça au mieux.
A priori, j'ai prévu deux branches, l'une, stable (pas besoin de
développer) et l'autre, testing, qui servira à valider de
nouveaux paquets avant de les mettre dans stable.
Maintenant, je me demande comment alimenter au mieux ces deux
branches car plusieurs outils sont disponibles comme reprepro
ou apt-mirror, voire de façon "manuelle". Il y a aussi les
aspects "sécurité" et "backports" par exemple...
Enfin, quand la version stable évolue (changement de version
majeure par exemple), comme gérer tout ça au mieux.
A priori, j'ai prévu deux branches, l'une, stable (pas besoin de
développer) et l'autre, testing, qui servira à valider de
nouveaux paquets avant de les mettre dans stable.
Maintenant, je me demande comment alimenter au mieux ces deux
branches car plusieurs outils sont disponibles comme reprepro
ou apt-mirror, voire de façon "manuelle". Il y a aussi les
aspects "sécurité" et "backports" par exemple...
Enfin, quand la version stable évolue (changement de version
majeure par exemple), comme gérer tout ça au mieux.
On Thu, 5 Apr 2012 15:35:15 +0200
David BERCOT wrote:
J'ai un faible pour debmirror (voire ftpmirror): facile Ã
configurer et à lancer 1/24 par un cron.
A priori, j'ai prévu deux branches, l'une, stable (pas besoin de
développer) et l'autre, testing, qui servira à valider de
nouveaux paquets avant de les mettre dans stable.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Heu, on parle bien d'un repo pour les SERVEURS là , hein?
Maintenant, je me demande comment alimenter au mieux ces deux
branches car plusieurs outils sont disponibles comme reprepro
ou apt-mirror, voire de façon "manuelle". Il y a aussi les
aspects "sécurité" et "backports" par exemple...
^^^^^^^^^^^
Bis Repetita.
securité & backports sont mutuellement exclusifs dans le sens où
backports a 99% de chances de contenir des trous de sécu &| des
bugs.
Enfin, quand la version stable évolue (changement de version
majeure par exemple), comme gérer tout ça au mieux.
Facile: n'importer les branches que par leurs petits noms, puis
créer les symlinks voulus (stable & testing).
Je ne vois pas ce que du testing viendrait faire sur des serveurs
en prod...
On Thu, 5 Apr 2012 15:35:15 +0200
David BERCOT <debian@bercot.org> wrote:
J'ai un faible pour debmirror (voire ftpmirror): facile Ã
configurer et à lancer 1/24 par un cron.
A priori, j'ai prévu deux branches, l'une, stable (pas besoin de
développer) et l'autre, testing, qui servira à valider de
nouveaux paquets avant de les mettre dans stable.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Heu, on parle bien d'un repo pour les SERVEURS là , hein?
Maintenant, je me demande comment alimenter au mieux ces deux
branches car plusieurs outils sont disponibles comme reprepro
ou apt-mirror, voire de façon "manuelle". Il y a aussi les
aspects "sécurité" et "backports" par exemple...
^^^^^^^^^^^
Bis Repetita.
securité & backports sont mutuellement exclusifs dans le sens où
backports a 99% de chances de contenir des trous de sécu &| des
bugs.
Enfin, quand la version stable évolue (changement de version
majeure par exemple), comme gérer tout ça au mieux.
Facile: n'importer les branches que par leurs petits noms, puis
créer les symlinks voulus (stable & testing).
Je ne vois pas ce que du testing viendrait faire sur des serveurs
en prod...
On Thu, 5 Apr 2012 15:35:15 +0200
David BERCOT wrote:
J'ai un faible pour debmirror (voire ftpmirror): facile Ã
configurer et à lancer 1/24 par un cron.
A priori, j'ai prévu deux branches, l'une, stable (pas besoin de
développer) et l'autre, testing, qui servira à valider de
nouveaux paquets avant de les mettre dans stable.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Heu, on parle bien d'un repo pour les SERVEURS là , hein?
Maintenant, je me demande comment alimenter au mieux ces deux
branches car plusieurs outils sont disponibles comme reprepro
ou apt-mirror, voire de façon "manuelle". Il y a aussi les
aspects "sécurité" et "backports" par exemple...
^^^^^^^^^^^
Bis Repetita.
securité & backports sont mutuellement exclusifs dans le sens où
backports a 99% de chances de contenir des trous de sécu &| des
bugs.
Enfin, quand la version stable évolue (changement de version
majeure par exemple), comme gérer tout ça au mieux.
Facile: n'importer les branches que par leurs petits noms, puis
créer les symlinks voulus (stable & testing).
Je ne vois pas ce que du testing viendrait faire sur des serveurs
en prod...
Bon, il faut que je regarde comment il fonctionne...
>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...
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 ?
Difficile de faire sans backports pour certains besoins, PostgreSQL 9
par exemple...
Bon, il faut que je regarde comment il fonctionne...
>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...
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 ?
Difficile de faire sans backports pour certains besoins, PostgreSQL 9
par exemple...
Bon, il faut que je regarde comment il fonctionne...
>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...
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 ?
Difficile de faire sans backports pour certains besoins, PostgreSQL 9
par exemple...
On Thu, 5 Apr 2012 20:38:59 +0200
David BERCOT 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 mis e Ã
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.
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 mis e Ã
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.
On Thu, 5 Apr 2012 20:38:59 +0200
David BERCOT 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 mis e Ã
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.
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é ?
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 à j our ?
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é ?
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 à j our ?
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é ?
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 à j our ?