Logo GNT
Actualités Tests & Guides Bons Plans
Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11
Entraide Linux Autres OS Linux Debian Conseils pour un dépôt Debian interne

Conseils pour un dépôt Debian interne

7 réponses
Avatar
David BERCOT
Bonjour,

J'ai mis en place un d=C3=A9p=C3=B4t Debian interne sur lequel tous les ser=
veurs
de mon organisation sont appel=C3=A9s =C3=A0 se synchroniser.

A priori, j'ai pr=C3=A9vu deux branches, l'une, stable (pas besoin de
d=C3=A9velopper) et l'autre, testing, qui servira =C3=A0 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=C3=A7on "manuelle". Il y a aussi les aspects "s=C3=A9curit=C3=
=A9" et
"backports" par exemple...

Ensuite, sachant que ce sont des serveurs, je n'aurais pas besoin de
tous les paquets qui concernent les environnements graphiques.

Enfin, quand la version stable =C3=A9volue (changement de version majeure
par exemple), comme g=C3=A9rer tout =C3=A7a au mieux.

Sachant que je ne suis certainement pas le premier =C3=A0 me poser ces
questions, je me suis dit que certains d'entre-vous auront certainement
des conseils =C3=A0 me donner sur ce type de d=C3=A9marche ;-)

Merci d'avance.

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-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: http://lists.debian.org/20120405153515.2ebf3b67@debian-david
Signaler un problème avec ce contenu

7 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Avatar
jacques
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
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Avatar
David Prévot
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig265A3D9989ADDFE73F1824EA
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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 s olutions un
peu moins élaborées, toutes les sources sont publiquement acces sibles a
priori.

Amicalement

David



--------------enig265A3D9989ADDFE73F1824EA
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQIcBAEBCAAGBQJPfbgsAAoJELgqIXr9/gny6LcP/1IKAXEQxsXeWyetxbhY5oCp
ECBGcElul0ByFU5W5HJFZdk7b/IkMZJ28ywOJkwYENPNFRnffEsw0fco+wWU60+I
MrrGn94OBFKaQqvP8YMnuU990gI20Ieo8M9Uc7S/PHD3oW/vhsrplWk85fVTdoDc
2riAq6ss8R5eVKcESxcbQdcFMAbx7g3tioEfR5HnvIGrWHNc7KMF5XPnelNsoLOC
6CXFWSMET0UqoGkCAqq1rQ+T4cw1VJM5I1VLMpwF/vJD3JMoYWRmewF4FR5OuDje
xGyZwoxU9FmxP4i47BACmx4rocpUuxha1RwAC69kv5Ia5TBipv31XKvEDTBYE6F7
zsSVXlXQMonpI4GERIKJ1XWFWOZ59n7+77qjfghRo1RLw8paxXIwQ+WAChKpx+C+
QdrZwZcZIumdaFLaEDMZ58DZ7/V/XSNScF3rxXloVkxgXaMSqKHeDCDs1mIJl5uj
CtmP6dsoby2TFUQYTGzdlIz7Um3MIoRMsBLPg9h/Rq10d3CrylJbz7Z5vmd21WuJ
GoDtI3qBDzCY3YKeU1wcwk1EoyuQ9tOvWddaiQ1lRpntraZBAsLh0qkG+iLdKKgC
dAn8rObswCHXRQhPaJFSd8AUMLa2ue2cJtbdzUbVMT/0znEZDFoRjFgMCOQdGFsI
FBNJRqTLqg/v07JuKhzB
w3
-----END PGP SIGNATURE-----

--------------enig265A3D9989ADDFE73F1824EA--

--
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
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/jlkd7e$v94$
Avatar
Bzzz
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...

--
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
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Avatar
David BERCOT
Le Thu, 5 Apr 2012 17:36:36 +0200,
Bzzz a écrit :
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.



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", i l 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
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Avatar
Bzzz
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 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
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Avatar
David BERCOT
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 Debia n 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 inte rne (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 a écrit :
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.



--
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
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Avatar
Bzzz
On Tue, 24 Apr 2012 16:32:36 +0200
David BERCOT 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 tr op
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 à j our ?



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 mou ture;
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
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/