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 lazyvi...@gmx.com a écrit : On Thu, 5 Apr 2012 20:38:59 +0200 David BERCOT deb...@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. -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/20120424163236.207bf3bb@debian-david
Re: Conseils pour un dépôt Debian interne
On Tue, 24 Apr 2012 16:32:36 +0200 David BERCOT deb...@bercot.org wrote: Faites-vous cela à partir des repository officiels ? Ou à partir de dépôts internes ? Ça dépend du Nb de svrs; mais déjà à partir de 6-7 machines ça commence à faire chibaver et surtout à bouffer la B.P. pendant trop longtemps; sans compter que si les svrs sont derrière une même adresse IP, les connexions sont limitées à 2 en simultané. Comment gérez-vous les changements les versions (tests préalables) ? Les mises à jour de sécurité ? Perso, je n'ai jamais vu de PB lors des MàJ normales ni de celles de sécurité en stable (au pire une MàJ reportée à cause d'un mauvais reportbug); par contre le dist-upgrade nécessite un micro de test, histoire de pointer/résoudre tous les PBs qui pourraient survenir. Evidemment, avec backports, c'est une toute autre histoire. est-ce que vous faites systématiquement les mises à jour de sécurité sur vos serveurs ? C'est préférable, vu que la plupart du temps elles correspondent à des rustines de... sécurité:) 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 ? Ton exemple n'est pas bon: c'est une migration mineure qui ne nécessite aucune action particulière. Pour les migrations majeures, Pg a refondu son ancient script (pg_migrator, devenu maintenant pg_upgrade pg_upgrade_support) - il prend en charge les upgrades depuis 8sèpu vers la dernière mouture; cependant il vaut mieux s'abonner à la ML Pg et lire les posts avant la manip parce qu'il-y-a des glitches de temps en temps, mais rarement qq chose de très méchant. L'avantage, c'est que c'est bcp plus rapide qu'un backup/restore. -- If God doesn't destroy San Francisco, He should apologize to Sodom and Gomorrah. -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/20120424171134.317baea6@anubis.defcon1
Re: Conseils pour un dépôt Debian interne
Le 05/04/2012 15:35, David BERCOT a écrit : Bonjour, Bonjour, Des réponses là : (incomplètes ?) http://www.debian.org/mirror/ftpmirror David. J. -- Pour passer au message suivant appuyez sur # -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/4f7da579.6020...@lavignotte.org
Re: Conseils pour un dépôt Debian interne
Salut, Le 05/04/2012 09:35, David BERCOT a écrit : 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 ;-) Tu peux t'inspirer de ce qui est fait dans Debian (dak), et aussi dans les mélanges (« Blends ») qui utilisent parfois d'autres solutions un peu moins élaborées, toutes les sources sont publiquement accessibles a priori. Amicalement David signature.asc Description: OpenPGP digital signature
Re: Conseils pour un dépôt Debian interne
On Thu, 5 Apr 2012 15:35:15 +0200 David BERCOT deb...@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... -- X-rated movies are all alike ... the only thing they leave to the imagination is the plot. -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/20120405173636.50570219@osiris.defcon1
Re: Conseils pour un dépôt Debian interne
Le Thu, 5 Apr 2012 17:36:36 +0200, Bzzz lazyvi...@gmx.com a écrit : On Thu, 5 Apr 2012 15:35:15 +0200 David BERCOT deb...@bercot.org wrote: J'ai un faible pour debmirror (voire ftpmirror): facile à configurer et à lancer 1/24 par un cron. Bon, il faut que je regarde comment il fonctionne... 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? 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 ? 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. Difficile de faire sans backports pour certains besoins, PostgreSQL 9 par exemple... 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... Parce que ce n'est pas du vrai testing ;-) David. -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/20120405203859.115a88ca@debian-david
Re: Conseils pour un dépôt Debian interne
On Thu, 5 Apr 2012 20:38:59 +0200 David BERCOT deb...@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. -- Does he treat your breasts like unripe grapefruit? Who needs him? -- `J', The Sensuous Woman -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/2012040521.5bee3248@osiris.defcon1
