Re: Questions sur les outils de gestion d'un dépôt privé apt

[randy11]

> From: "Olivier" <oza.4...@gmail.com>
> To: "ML Debian User French" <debian-user-french@lists.debian.org>
> Sent: Wednesday, 13 December, 2017 6:08:08 PM
> Subject: Questions sur les outils de gestion d'un dépôt privé apt

> J'ai survolé la description de d'aptly qui a l'air de bien répondre
> mais un retour d'expérience serait le bienvenu.

Bonjour, 
J'ai mis en place un Aptly pour Jessie, Stretch et Ubuntu Xenial. Un vrai 
bonheur ! 

J'utilise la version du site d'origine et pas celle de la distribution qui est 
plus 
ancienne. Un seul bémol : les sources ne sont pas gérés quand la 
compression est faite avec "bzip". 

Le scénario classique : 
- aptly repo create ... (à faire une seule fois) 
- aptly repo add ... 
- aptly snapshot create ... from repo ... 
- aptly publish snapshot  (à faire une seule fois) 
- aplty publish switch   

Si je ne fais pas le ménage dans mon dépôt, je conserve toutes les 
version de mes paquets. 
Les snapshots sont utiles quand tu t’aperçois qu'une erreur a été 
commise et qu'il faut très rapidement faire marche arrière. Dans 
ce cas : 
- aptly snapshot list 
- aptly publish switch   

> Le point qui me semble le plus obscur est la maîtrise, avec aptly ou
> autre chose, de la version des paquets installés:
> 1. le dépôt de Debian/Stetch héberge le logiciel toto.1.1,
> 2. tant bien que mal, je crée un paquet 1.1.3 que je pousse dans mon
> dépôt privé,
> 3. un apt-get upgrade sur un serveur utilisant exclusivement ce dépôt
> privé, installe le paquet toto-1.1.3
> 4. après une commande magique je peux obtenir un retour arrière si
> besoin (au besoin en falsifiant un paquet 1.1.4 qui aurait dans les
> faits le même contenu qu'un paquet 1.1.X antérieur
> 5. comment se prémunir d'une mise à jour dans le dépôt officiel de
> Debian

> Qu'en pensez-vous ?

> Slts

Mon utilisation pour l'instant consiste à installer des paquets 
"maison", donc avec un nom absent des paquets Debian. Aucun 
risque de conflit. 

Comme cela a été proposé, s'inspirer de ce qui est fait pour "backports" 
et l'utilisation de "/etc/apt/preferences" est une très bonne idée. 
Mais cela dépend avant tout de ce que tu veux faire et non pas 
de l'outil (Aptly) pour le miroir. 

Si tu te contente de rajouter une source qui est ton miroir privé dans 
"/etc/apt/sources.list.d/" et changeant seulement le numéro de version, 
quand un nouveau paquet avec un numéro de version supérieur sera 
disponible; il sera toujours installé. 

En jouant avec "/etc/apt/preferences", tu peux (à choisir) mettre ton 
dépôt comme source prioritaire ou des paquets (en les nommants) 
comme ne pouvant être mis à jour que par ton dépôt. 

Ton problème de mise à jour existera tant qu'un paquet aura le même 
nom dans plusieurs dépôt. 

Par exemple, les "backports" utilise l'extension "bpo" dans le nom de 
version. La comparaison par défaut se fait sur une comparaison de 
chaîne de caractère classique : 1.2.3 < 1.2.3.aaa < 1.2.3.aab 

Re: Questions sur les outils de gestion d'un dépôt privé apt

[Gabriel Moreau]

Ça ne devrait pas se produire car les versions des logiciels dans la branche
stable ne changent pas (ça c’est l’ancienne théorie, car dans la pratique, il
arrive que certains changent, Firefox par exemple).


Ou le noyau qui a pété il y a quelques jours une bonne partie des 
machines bi-proc !


gaby
--
Gabriel Moreau - IR CNRShttp://www.legi.grenoble-inp.fr
LEGI (UMR 5519) Laboratoire des Ecoulements Geophysiques et Industriels
Domaine Universitaire, CS 40700, 38041 Grenoble Cedex 9, France
mailto:gabriel.mor...@legi.grenoble-inp.fr  tel:+33.476.825.015

Re: Questions sur les outils de gestion d'un dépôt privé apt

[Sébastien NOBILI]

Le mercredi 13 décembre 2017 à 19:08, Olivier a écrit :
> 2. de centraliser l'accès à des dépôts apt de plusieurs serveurs afin que
> ces serveurs n'aient plus directement besoin d'accéder à Internet pour
> installer de nouveaux paquets ou mettre des paquets anciens (un mirroir me
> semble bien répondre à ce besoin puisque seul le mirroir a besoin
> d'Internet pour remplir son office).

« apt-cacher-ng » peut peut-être répondre à ce besoin.

> Le point qui me semble le plus obscur est la maîtrise, avec aptly ou autre
> chose, de la version des paquets installés:
> 1. le dépôt de Debian/Stetch héberge le logiciel toto.1.1,
> 2. tant bien que mal, je crée un paquet 1.1.3 que je pousse dans mon dépôt
> privé,
> 3. un apt-get upgrade sur un serveur utilisant exclusivement ce dépôt
> privé, installe le paquet toto-1.1.3
> 4. après une commande magique je peux obtenir un retour arrière si besoin
> (au besoin en falsifiant un paquet 1.1.4 qui aurait dans les faits le même
> contenu qu'un paquet 1.1.X antérieur
> 5. comment se prémunir d'une mise à jour dans le dépôt officiel de Debian

Ça ne devrait pas se produire car les versions des logiciels dans la branche
stable ne changent pas (ça c’est l’ancienne théorie, car dans la pratique, il
arrive que certains changent, Firefox par exemple).

Sébastien

Re: Questions sur les outils de gestion d'un dépôt privé apt

[yamo']

Salut,
Olivier a écrit le 13/12/2017 à 19:10 :

> Qu'en pensez-vous ?


Est-ce que la solution décrite sur la page ci-dessous répond au besoin?


-- 
Stéphane

Re: Questions sur les outils de gestion d'un dépôt privé apt

[Daniel Caillibaud]

Le 13/12/17 à 19:08, Olivier  a écrit :
O> Bonjour,
O> 
O> J'ai un double besoin :
O> 
O> 1. empaqueter puis distribuer pour Stretch des logiciels, en version un
O> peu plus récente, que celle actuellement dans les dépôts publics de
O> Debian,

Je suppose que tu connais stretch-backports et que ça ne répond pas à ton
besoin…

O> 2. de centraliser l'accès à des dépôts apt de plusieurs serveurs afin que
O> ces serveurs n'aient plus directement besoin d'accéder à Internet pour
O> installer de nouveaux paquets ou mettre des paquets anciens (un mirroir
O> me semble bien répondre à ce besoin puisque seul le mirroir a besoin
O> d'Internet pour remplir son office).
O> 
O> Quel outils/architecture recommander pour couvrir ces 2 besoins ?
O> 
O> J'ai survolé la description de d'aptly qui a l'air de bien répondre mais
O> un retour d'expérience serait le bienvenu.

Dsl connaît pas…

O> Le point qui me semble le plus obscur est la maîtrise, avec aptly ou
O> autre chose, de la version des paquets installés:
O> 1. le dépôt de Debian/Stetch héberge le logiciel toto.1.1,
O> 2. tant bien que mal, je crée un paquet 1.1.3 que je pousse dans mon
O> dépôt privé,
O> 3. un apt-get upgrade sur un serveur utilisant exclusivement ce dépôt
O> privé, installe le paquet toto-1.1.3
O> 4. après une commande magique je peux obtenir un retour arrière si besoin
O> (au besoin en falsifiant un paquet 1.1.4 qui aurait dans les faits le
O> même contenu qu'un paquet 1.1.X antérieur

Tu peux forcer la réinstallation d'un paquet antérieur (en précisant sa
version quand tu l'installe) et le bloquer à cette version (hold).

O> 5. comment se prémunir d'une mise à jour dans le dépôt officiel de Debian
O> 
O> Qu'en pensez-vous ?

Tu peux pour tout ça jouer avec apt-preferences, mettre une priorité plus
élevée pour ton dépôt privé (cherche aussi "debian package pinning" sur le
net pour voir les façons de faire et les risques à maîtriser).

Mais pour éviter une màj auto dans une version antérieure mise à jour sur
le dépôt debian officiel, le mieux est d'adapter pour tes paquets privés une
numérotation qui suit la version des sources, ce que fait debian (en
ajoutant éventuellement un suffixe), ainsi un n° de version de paquet plus
élevé correspondra toujours à une version plus récente du source (donc
créer une 1.1.4 qui serait une 1.1.2 pour forcer un downgrade de 1.1.3 me
semble une mauvaise idée)

man apt_preferences
man apt-cache # commande policy pour vérifier que tes préférences donnent le
  # résultat attendu

-- 
Daniel

Il est vrai qu'on ne peut trouver la pierre philosophale, 
mais il est bon qu'on la cherche.
Bernard Fontenelle

Questions sur les outils de gestion d'un dépôt privé apt

[Olivier]

Bonjour,

J'ai un double besoin :

1. empaqueter puis distribuer pour Stretch des logiciels, en version un peu
plus récente, que celle actuellement dans les dépôts publics de Debian,

2. de centraliser l'accès à des dépôts apt de plusieurs serveurs afin que
ces serveurs n'aient plus directement besoin d'accéder à Internet pour
installer de nouveaux paquets ou mettre des paquets anciens (un mirroir me
semble bien répondre à ce besoin puisque seul le mirroir a besoin
d'Internet pour remplir son office).

Quel outils/architecture recommander pour couvrir ces 2 besoins ?

J'ai survolé la description de d'aptly qui a l'air de bien répondre mais un
retour d'expérience serait le bienvenu.

Le point qui me semble le plus obscur est la maîtrise, avec aptly ou autre
chose, de la version des paquets installés:
1. le dépôt de Debian/Stetch héberge le logiciel toto.1.1,
2. tant bien que mal, je crée un paquet 1.1.3 que je pousse dans mon dépôt
privé,
3. un apt-get upgrade sur un serveur utilisant exclusivement ce dépôt
privé, installe le paquet toto-1.1.3
4. après une commande magique je peux obtenir un retour arrière si besoin
(au besoin en falsifiant un paquet 1.1.4 qui aurait dans les faits le même
contenu qu'un paquet 1.1.X antérieur
5. comment se prémunir d'une mise à jour dans le dépôt officiel de Debian

Qu'en pensez-vous ?

Slts