Modifications entre les versions 7 et 25 (s'étendant sur 18 versions)
Version 7 à la date du 2008-01-16 08:53:33
Taille: 7633
Éditeur: ThomasNoël
Commentaire: un ptit schéma et un todo
Version 25 à la date du 2008-11-07 15:45:38
Taille: 5879
Éditeur: ThomasNoël
Commentaire: mental, pas rience
Texte supprimé. Texte ajouté.
Ligne 1: Ligne 1:
Cette page présente le dépôt de paquets Debian/Ubuntu spécifiques à l'AUF. Cette page présente le dépôt de paquets pour Debian et Ubuntu spécifiques à l'AUF.
Ligne 3: Ligne 3:
 ||<#ffaa00> Il s'agit d'un système en cours de mise en place, ne pas utiliser pour l'instant merci !||  /* Bientôt ici du blabla pour dire à quoi ça sert, qui peut s'en servir, etc... */
Ligne 7: Ligne 7:
D'abord installer la clé publique GPG qui signe certains fichiers du dépôt : == Ajout de la clé GPG utilisée pour signer le dépôt ==

Il faut d'abord installer la clé publique GPG qui signe ce dépôt. Pour cela, ajouter dans le `sources.list` le dépôt AUF concernant votre distribution :
Ligne 9: Ligne 11:
$ wget -qO - http://apt.auf.org/B7520EF5BF4CCF4D.asc | sudo apt-key add - # à ajouter dans /etc/apt/sources.list (ou créer un /etc/apt/sources.list.d/auf)
# remplacer "distribution" par etch, lenny, hardy, intrepid, ... selon votre système.
deb http://apt.auf.org/ distribution-debian-ou-ubuntu auf
Ligne 11: Ligne 15:

Puis installer le paquet `auf-keyring` :
 {{{
# aptitude update
# aptitude install auf-keyring
}}}

'''Note''' : lors de la première installation de `auf-keyring` ''aptitude'' va vous demander de confirmer l'installation car il ne juge pas encore la source "sûre". Confirmez l'installation, la clé sera ajoutée : ''aptitude'' fera désormais confiance au dépôt AUF.

== Configuration des sources de paquets (sources.list) ==
Ligne 14: Ligne 28:
# format d'une source Debian :
Ligne 16: Ligne 31:
Exemples (non fonctionnels à l'heure de la rédaction) :
Exemples de sources à ajouter :
Ligne 18: Ligne 34:
# paquets pour la mise en place d'un serveur VoIP Asterisk AUF :
deb http://apt.auf.org/ etch voip
# paquets spécifiques à Dakar pour les postes clients Ubuntu Feisty :
deb http://apt.auf.org/ feisty sn
# Paquets AUF pour Ubuntu Hardy
# A utiliser sur tout poste client AUF (mais ne contient rien à ce
# jour -- 7 nov 2008)
deb http://apt.auf.org/ hardy auf

# Paquets en cours de tests (validation) pour Ubuntu Hardy
# A utiliser quand vous désirez/devez participer à un test d'un
# futur paquet AUF...
deb http://apt.auf.org/ hardy-test auf

# Paquets en cours d'expérimentation pour Ubuntu Hardy
# Attention : forte potentialité de crash ;)
deb http://apt.auf.org/ hardy-experimental auf
Ligne 24: Ligne 49:
= Pour ajouter ses petits paquets = Après un `aptitude update`, vous pouvez installer les nouveaux paquets.
Ligne 26: Ligne 51:
Il faut : = Pour ajouter ses petits paquets dans le dépôt =

Si vous savez fabriquer des paquets Debian ou Ubuntu, vous pouvez les mettre à disposition de vos collègue sur ce dépôt.

Pour cela, il faut :
Ligne 28: Ligne 57:
 * savoir à quelle distribution sont destinés les paquets : etch, lenny, feisty, gutsy, hardy, ...
 * trouver un nom pour le composant : voip, rpv2, auf-desktop, votre-iso-pays, votre-nom, ...
 * avoir un compte ''ssh'' sur la machine `apt.auf.org` (demander à Moussa)
 * avoir un répertoire (''incoming'' ou tout autre nom poétique) configuré pour recevoir les paquets (fichiers changes, deb, dsc et sources)
 * savoir à quelle distribution sont destinés les paquets : etch, lenny, hardy, intrepid, ...
Ligne 33: Ligne 59:
Pour envoyer un paquet, on utilise '''dput''' (`aptitude install dput`) que l'on configure ainsi dans son ~/.dput.cf : Pour envoyer un paquet, on utilise '''dput''' (`aptitude install dput`) que l'on configure ainsi (dans `~/.dput.cf`) :
Ligne 35: Ligne 61:
# extrait de ~/.dput.cf (inspiré de /etc/dput.cf) : # Exemple de configuration de dput. Ce dput est prévu pour envoyer des paquets
# pour Ubuntu "Hardy" (8.04) dans les sections "experiences" et "tests".
Ligne 37: Ligne 64:
method = rsync
hash = md5
allow_unsigned_uploads = 0
run_lintian = 0
run_dinstall = 0
check_version = 0
default_host_main = voip
fqdn = apt.auf.org
hash = md5
allow_unsigned_uploads = 1
run_dinstall = 0
scp_compress = 1
default_host_main = section-a-preciser
fqdn = apt.auf
method = ftp
login = anonymous
Ligne 46: Ligne 73:
# par défaut on envoie ici :
[voip]
incoming = ~/incoming/voip
# paquets pour "hardy-tests auf"
[test]
incoming = test/hardy
Ligne 50: Ligne 77:
# mais on peut aussi envoyer ici (en ajoutant voip-test après dput) :
[voip-test]
incoming = ~/incoming/voip-test
# paquets pour "hardy-experimental auf"
[experimental]
incoming = experimental/hardy
Ligne 56: Ligne 83:
 {{{$ dput nom-du-paquet.changes  {{{
$ dput experimental le-nom-du-paquet.changes
Ligne 59: Ligne 87:
Si tout va bien le paquet sera ajouté dans le dépôt 5 minutes plus tard. Sinon un courriel sera envoyé à qui de droit, qui vous informera de la fin de votre contrat à l'AUF. Si tout va bien le paquet sera ajouté dans le dépôt 5 minutes plus tard (par cron). Si la version expérimentale fonctionne, envoyez dans `test` et demandez à des collègues de tester. Une fois que tout est ok, il sera ajouté (manuellement) dans le dépôt officiel "auf".
Ligne 61: Ligne 89:
= Comment ça marche à l'intérieur = = Pour les curieux : comment ça marche à l'intérieur =
Ligne 63: Ligne 91:
attachment:reprepro-apt-auf-org.png {{attachment:reprepro-apt-auf-org.png}}
Ligne 65: Ligne 93:
Le système est basé sur [http://mirrorer.alioth.debian.org/ reprepro] ([http://packages.debian.org/etch/reprepro version etch]). C'est ce logiciel qui gère le dépot, un serveur ''apache2'' le propose en HTTP. Notez que la version etch de reprepro ne gère pas la notion de répertoires "incoming", j'ai donc écrit cette partie. Une version plus récente semble savoir le faire, je l'étudierais plus tard. Le système est basé sur [[http://mirrorer.alioth.debian.org/|reprepro]] ([[http://packages.debian.org/etch/reprepro|version etch]]). C'est ce logiciel qui gère le dépot : on lui dit quel paquet ajouter à quel composant de quelle distribution, et il gère le pool, les fichiers Release, Packages, Sources, etc. A côté, un serveur ''apache2'' propose le dépôt en HTTP.
Ligne 67: Ligne 95:
Le principe : il y a un utilisateur virtuel "reprepro" sur le système, qui gère le dépôts. C'est cet utilisateur qui va lancer le logiciel "reprepro" avec les bons arguments, régulièrement (via cron). Le principe : il y a un utilisateur virtuel "reprepro" sur le système, qui gère le dépôts. C'est cet utilisateur qui va lancer le logiciel "reprepro" avec les bons arguments. Il est le seul à avoir accès en écriture sur le dépôt.
Ligne 73: Ligne 101:
Un script lance le logiciel reprepro en lui disant d'aller chercher les paquets de tel composant pour telle distribution dans tel répertoire. La liste de ces triplets est dans `~reprepro/incomings` : Un script shell appelé `reprepro-incoming` lance le logiciel reprepro en lui disant d'aller chercher les paquets de tel composant pour telle distribution dans tel répertoire. La liste de ces paramètres est dans `~reprepro/incomings` :
Ligne 75: Ligne 103:
# (... extrait de ~reprepro/incomings ...)
# voip : la config AUF d'asterisk 1.2 pour etch
etch voip /home/thomas/voip
# voip-test : backport de asterisk 1.4 en cours
etch voip-test /home/thomas/voip-test
# Fichier ~reprepro/incomings

# Format d'une ligne :
# distrib composant repertoire email-pour-rapport

etch-test auf /home/ftp/test/etch root@auf.org
etch-experimental auf /home/ftp/experimental/etch thomas.noel@auf.org
Ligne 82: Ligne 112:
Le script (version du 15 janvier 22h TU) :
 {{{$ cat ~reprepro/reprepro-incoming
#!/bin/bash
Le script `reprepro-incoming` gère l'envoie de rapport par mail (dernier paramètre de chaque ligne d'appel). Il est lancé par '''cron toutes les 5 minutes'''.
Ligne 86: Ligne 114:
# reprepro-incoming <dist> <component> [<repertoire>]
# - se place dans le repertoire indiqué, y regarde les fichiers .changes
# - pour chaque fichier .change, analyse si les fichiers correspondants sont présents
# (pour le cas d'un upload en cours)
# - si oui, envoie les paquets dans le dépot, sur la distrib et selon le composant indiqué
# La configuration est dans /etc/reprepro/options et /etc/reprepro/distributions (cf man reprepro)
# Exemple :
# $ reprepro-incoming etch voip /home/thomas/voip/

# Note : reprepro-incoming est destiné à tourner en cron, il ne dit rien s'il
# n'a rien à faire. Exemple de configuration en cron :
# */5 * * * * reprepro cd /home/reprepro && ./reprepro-incoming
# Attention, reprepro ne gère sans doute pas les accès concurrents à un même dépôt !

# Note : si on lance "reprepro-incoming" sans argument, il va lire le fichier ~/incomings
# qui contient un triplet "<dist> <component> [<repertoire>]" par ligne. r-i se lance
# alors autant de fois que de ligne, avec ces arguments à chaque fois... Ces lancements
# séquentiels évitent d'avoir à ce soucier des accès concurrents...
if [ $# -eq 0 -a -r ~/incomings ]; then
        sed '/^\s*#/d;/^\s*$/d' ~/incomings | while read ARGS; do
                ~/reprepro-incoming $ARGS # le script s'appelle lui-même ici
                if [ $? -ne 0 ]; then
                        echo " ^^ erreur lors de $0 $ARGS ^^ "
                        echo ""
                fi
        done
        exit 0
fi

if [ $# -lt 2 ]; then
        echo "syntaxe: $0 distribution component [repertoire]" >&2
        exit 1
fi
DISTRIB=${1}
COMPONENT=${2}

# s'il existe un 3ème argument c'est un repertoire, on va dedans
if [ -n "${3}" ]; then
        cd "${3}" || exit 2
fi

# pas de fichier .changes : on s'arrete ici (silencieusement car ça peut être normal)
ls *.changes > /dev/null 2>&1 || exit 0

export REPREPRO_CONFIG_DIR=${REPREPRO_CONFIG_DIR:-~/conf}

# on analyse chaque fichier changes
for fc in *.changes; do
        # les md5sum sont-ils ok ?
        sed '0,/^Files:\s*$/d' ${fc} | while read MD5 SIZE SECT PRIO FILE; do
                echo $MD5" "$FILE
        done | md5sum --check --status > /dev/null 2>&1
        if [ $? -ne 0 ]; then
                echo "warn: fichier ${fc}, echec de la verification des sommes md5"
                sed '0,/^Files:\s*$/d' ${fc} | while read MD5 SIZE SECT PRIO FILE; do
                        echo $MD5" "$FILE
                done | md5sum --check
                # md5 pas bon : on passe au .change suivant
                continue
        fi
        echo "traitement de ${fc} :"
        echo "$ reprepro --component $COMPONENT include $DISTRIB $fc"
        # on envoie dans le dépôt (et si ça passe pas, on va pas plus loin !)
        reprepro -V --component $COMPONENT include $DISTRIB $fc || exit 3
        # et on efface les fichiers, ils sont dans le pool maintenant
        sed '0,/^Files:\s*$/d' ${fc} | while read MD5 SIZE SECT PRIO FILE; do
                rm -f $FILE
        done
        rm -f ${fc}
        echo ""
done
}}}
Pour info, le script dans sa version du 11 février 15h TU : [[attachment:reprepro-incoming]]
Ligne 161: Ligne 118:
 * tester un peu plus !... et mettre en place le cron... et dire que "ça marche" ;)
 * envoi d'un courriel à l'auteur quand un reprepro a eu lieu sur un repertoire donné (ajout d'un champ mail dans ~reprepro/incomings), avec rapport d'erreur le cas échéant
 * regarder le [http://packages.debian.org/etch-backports/reprepro backport de reprepro] et notamment son "processincoming"
 * créer un paquet auf-keyring pour mettre toutes les clés gpg utiles à l'AUF (différents dépôts), selon un modèle du genre http://packages.debian.org/debian-keyring
 * regarder le [[http://packages.debian.org/etch-backports/reprepro|backport de reprepro]] et notamment son "processincoming"
 * mettre tout le code sur git.auf.org

= Multi-architecture =

Pour proposer un paquet binaires dans plusieurs architectures (typiquement i386 et amd64) :
  * il faut compiler d'abord une architecture classiquement et inclure les sources dans l'upload (donc `dpkg-buildpackage` avec l'option `-sa`)
  * envoyer par `dput` le `...changes`
  * puis compiler la ou les autres architectures avec l'option `-b` qui ne construit ''que'' le paquet binaire...
  * envoyer par `dput` le ou les `...changes` obtenus

------
Notes de bas de page :

Cette page présente le dépôt de paquets pour Debian et Ubuntu spécifiques à l'AUF.

Accès aux paquets disponibles

Ajout de la clé GPG utilisée pour signer le dépôt

Il faut d'abord installer la clé publique GPG qui signe ce dépôt. Pour cela, ajouter dans le sources.list le dépôt AUF concernant votre distribution :

  • # à ajouter dans /etc/apt/sources.list (ou créer un /etc/apt/sources.list.d/auf) 
    # remplacer "distribution" par etch, lenny, hardy, intrepid, ... selon votre système.
    deb http://apt.auf.org/ distribution-debian-ou-ubuntu auf

Puis installer le paquet auf-keyring :

  • # aptitude update
    # aptitude install auf-keyring

Note : lors de la première installation de auf-keyring aptitude va vous demander de confirmer l'installation car il ne juge pas encore la source "sûre". Confirmez l'installation, la clé sera ajoutée : aptitude fera désormais confiance au dépôt AUF.

Configuration des sources de paquets (sources.list)

Ensuite ajouter les sources qui vous conviennent en fonction de ce que vous avez à mettre en place. Les lignes à ajouter dans le sources.list sont de la forme :

  • # format d'une source Debian :
    deb http://apt.auf.org/ distribution composant

Exemples de sources à ajouter :

  • # Paquets AUF pour Ubuntu Hardy
    # A utiliser sur tout poste client AUF (mais ne contient rien à ce
    # jour -- 7 nov 2008)
    deb http://apt.auf.org/ hardy auf
    
    # Paquets en cours de tests (validation) pour Ubuntu Hardy
    # A utiliser quand vous désirez/devez participer à un test d'un
    # futur paquet AUF...
    deb http://apt.auf.org/ hardy-test auf
    
    # Paquets en cours d'expérimentation pour Ubuntu Hardy
    # Attention : forte potentialité de crash ;)
    deb http://apt.auf.org/ hardy-experimental auf

Après un aptitude update, vous pouvez installer les nouveaux paquets.

Pour ajouter ses petits paquets dans le dépôt

Si vous savez fabriquer des paquets Debian ou Ubuntu, vous pouvez les mettre à disposition de vos collègue sur ce dépôt.

Pour cela, il faut :

  • savoir faire des beaux paquets Debian : dpkg-buildpackage, dh-make, retroportages, ...

  • savoir à quelle distribution sont destinés les paquets : etch, lenny, hardy, intrepid, ...

Pour envoyer un paquet, on utilise dput (aptitude install dput) que l'on configure ainsi (dans ~/.dput.cf) :

  • # Exemple de configuration de dput. Ce dput est prévu pour envoyer des paquets
    # pour Ubuntu "Hardy" (8.04) dans les sections "experiences" et "tests".
    [DEFAULT]
    hash                    = md5
    allow_unsigned_uploads  = 1
    run_dinstall            = 0
    scp_compress            = 1
    default_host_main       = section-a-preciser
    fqdn                    = apt.auf
    method                  = ftp
    login                   = anonymous
    
    # paquets pour "hardy-tests auf"
    [test]
    incoming                = test/hardy
    
    # paquets pour "hardy-experimental auf"
    [experimental]
    incoming                = experimental/hardy

Pour envoyer un paquet il suffit de faire :

  • $ dput experimental le-nom-du-paquet.changes

Si tout va bien le paquet sera ajouté dans le dépôt 5 minutes plus tard (par cron). Si la version expérimentale fonctionne, envoyez dans test et demandez à des collègues de tester. Une fois que tout est ok, il sera ajouté (manuellement) dans le dépôt officiel "auf".

Pour les curieux : comment ça marche à l'intérieur

reprepro-apt-auf-org.png

Le système est basé sur reprepro (version etch). C'est ce logiciel qui gère le dépot : on lui dit quel paquet ajouter à quel composant de quelle distribution, et il gère le pool, les fichiers Release, Packages, Sources, etc. A côté, un serveur apache2 propose le dépôt en HTTP.

Le principe : il y a un utilisateur virtuel "reprepro" sur le système, qui gère le dépôts. C'est cet utilisateur qui va lancer le logiciel "reprepro" avec les bons arguments. Il est le seul à avoir accès en écriture sur le dépôt.

  • /srv/www/apt.auf.org/pool et .../dists : le dépôt lui-même

  • ~reprepro/conf/ : configuration de reprepro, voir man reprepro pour explication :

  • ~reprepro/db/ : contient les bases de données internes de reprepro

Un script shell appelé reprepro-incoming lance le logiciel reprepro en lui disant d'aller chercher les paquets de tel composant pour telle distribution dans tel répertoire. La liste de ces paramètres est dans ~reprepro/incomings :

  • # Fichier ~reprepro/incomings
    
    # Format d'une ligne :
    # distrib composant repertoire email-pour-rapport
    
    etch-test           auf     /home/ftp/test/etch              root@auf.org
    etch-experimental   auf     /home/ftp/experimental/etch      thomas.noel@auf.org

Le script reprepro-incoming gère l'envoie de rapport par mail (dernier paramètre de chaque ligne d'appel). Il est lancé par cron toutes les 5 minutes.

Pour info, le script dans sa version du 11 février 15h TU : reprepro-incoming

Il reste à faire

  • regarder le backport de reprepro et notamment son "processincoming"

  • mettre tout le code sur git.auf.org

Multi-architecture

Pour proposer un paquet binaires dans plusieurs architectures (typiquement i386 et amd64) :

  • il faut compiler d'abord une architecture classiquement et inclure les sources dans l'upload (donc dpkg-buildpackage avec l'option -sa)

  • envoyer par dput le ...changes

  • puis compiler la ou les autres architectures avec l'option -b qui ne construit que le paquet binaire...

  • envoyer par dput le ou les ...changes obtenus


Notes de bas de page :

DépôtAPT/EnvoyerSesPaquets (dernière édition le 2011-03-11 03:14:48 par JeanChristopheAndré)