« Koji/Utilisation » : différence entre les versions

De TartareFR
Aller à la navigation Aller à la recherche
Aucun résumé des modifications
 
(17 versions intermédiaires par le même utilisateur non affichées)
Ligne 1 : Ligne 1 :
== Ajout d'un paquet au repository ==
[[Fichier:LogoKoji.svg|sans_cadre|droite]]
 
== Généralités ==
 
=== Ajout d'un paquet au repository ===
Un admin du koji ajoute le paquet et le place sous la responsabilité d'un utilisateur Koji
  koji add-pkg --owner didier centos-5 b2pweb
  koji add-pkg --owner didier centos-5 b2pweb
{{Admon/tip|Construction d'un paquet scratch|
Koji permet de construire des paquets sans qu'il soit nécessaire de les ajouter au repository: '''scratch'''
La commande de construction devient donc
<pre>koji build --scratch centos-5 b2pweb-1.1.0-8.fc17.src.rpm</pre>
Toutefois cette méthode n'est pas recommandé si on cherche à construire un paquet pour notre repository.}}


== Construction du paquet ==
=== Construction d'un paquet ===


=== Depuis un paquet source ===
==== Depuis un paquet source ====
  koji build centos-5 b2pweb-1.1.0-8.fc17.src.rpm
  koji build centos-5 b2pweb-1.1.0-8.fc17.src.rpm
Toutefois cette méthode n'est pas recommandé si on cherche à construire un paquet pour notre repository. Cependant elle est très utile pour vérifier que la compilation et le fichier spec est bien formaté.


Koji permet de construire des paquets sans qu'il soit nécessaire de les ajouter au repository: '''scratch'''
==== Depuis un système de contrôle de version ====
 
Il faut tout d'abord autoriser le serveur et le dépôt sur '''tous les constructeurs''' koji ( kojid ).
 
Ici on déclare deux dépôts de sources:
* dépôt '''GIT''': ''git://didier.b2pweb.com/rpm''
* dépôt '''SVN''': ''<nowiki>http://didier.b2pweb.com/svn/rpm</nowiki>''<br>Celui-ci étant composé d'un arbre SVN standard, on déclare le répertoire ''trunk''.
''
Extrait du fichier <path>/etc/kojid/kojid.conf</path>
; A space-separated list of hostname:repository[:use_common] tuples that kojid is authorized to checkout from (no quotes).
; Wildcards (as supported by fnmatch) are allowed.
; If use_common is specified and is one of "false", "no", "off", or "0" (without quotes), then kojid will not attempt to checkout
; a common/ dir when checking out sources from the source control system.  Otherwise, it will attempt to checkout a common/
; dir, and will raise an exception if it cannot.
allowed_scms=didier.b2pweb.com:/rpm:no didier.b2pweb.com:/svn/rpm/trunk:yes
{{Admon/warning|Paramètre ''use_common''|Il semble y avoir un bug avec le paramètre ''use_common'' et l'utilisation d'un dépôt git.


La commande de construction devient donc
En effet quelque soit la valeur de ce paramètre, un dépôt ''common'' sera téléchargé.
koji build --scratch centos-5 b2pweb-1.1.0-8.fc17.src.rpm


=== Depuis un système de contrôle de version ===
'''Work-Around''': Créer un dépôt ''common'' vide sur le serveur git.}}


Le système doit fournir un Makefile qui contient une cible sources, dont la tâche est de fournir les sources via une commande de téléchargement. Si celles-ci sont incluses dans SCM, la cible doit être vide.
Le système doit fournir un Makefile qui contient une cible sources, dont la tâche est de fournir les sources via une commande de téléchargement. Si celles-ci sont incluses dans le SCM, la cible doit être vide.


<syntaxhighlight lang="bash">
<syntaxhighlight lang="make">
# Common Makefile
sources:
sources:
</syntaxhighlight>
</syntaxhighlight>


Il ne reste plus qu'à lancer la construction depuis koji
Il ne reste plus qu'à lancer la construction depuis <app>koji</app>


  koji build centos-5 <nowiki>svn+http://guest@didier.b2pweb.com/svn/rpm/trunk?b2pweb#head</nowiki>
avec SVN
  koji build centos-5 <nowiki>svn+http://didier.b2pweb.com/svn/rpm/trunk?b2pweb-release#head</nowiki>
 
avec git
koji build centos-5 git://didier.b2pweb.com/rpm?b2pweb-release#5153396fc3bf204b74e745759eee33ed5dad0ffe
{{Admon/important|Différence entre les SCM|* Avec svn, le '''répertoire''' ''common'' sera téléchargé en plus de celui du paquet en cours
* Avec git c'est un '''dépôt''' ''common'' qui sera ajouté et l'intégralité du dépôt rpm sera téléchargé.}}
 
== Interface Web ==
[[Fichier:KojiwebScreenshot.png||800px]]
 
== Dépôt B2PWeb ==
 
=== Importer des paquets sources et binaires ===
{{Admon/warning|Import|Il est impératif d'importer les paquets RPM pour chaque architecture gérée (intel 32/64 bits, etc ...). De plus le paquet RPM source devra être importer en premier.
Il y a donc au minimum import de deux paquets RPM.}}
 
<package>Koji</package> '''n'accepte pas facilement l'import de paquet RPM binaire sans paquet RPM source correspondant.'''
 
==== Import standard ====
 
Sur le <package>Koji</package> B2PWeb, il n'y a que deux architectures définies :
* i386 ou i686 ( suivant la version de la distribution )
* x86_64
 
Afin de maintenir une certaine homogénéité dans le dépôt, il faudra importer les paquets RPM binaires pour les deux architectures.
 
Le SRPM est obligatoirement importé en premier.
 
# Import du paquet RPM source<pre>koji add-pkg centos-5 foo.src.rpm</pre>
# Import des paquets RPM binaires
#* Paquet 32 bits<pre>koji add-pkg centos-5 foo.i386.rpm</pre>
#* Paquet 64 bits<pre>koji add-pkg centos-5 foo.x86_64.rpm</pre>
 
==== Import sans SRPM ====
 
Exemple en intégrant les paquets pour une base Oracle.
# Téléchargement des RPM depuis le site Oracle dans le dossier <path>/mnt/koji/externals</path>
#* oracle-instantclient12.1-basic-12.1.0.1.0-1.i386.rpm
#* oracle-instantclient12.1-devel-12.1.0.1.0-1.i386.rpm
#* oracle-instantclient12.1-sqlplus-12.1.0.1.0-1.i386.rpm
#* oracle-instantclient12.1-basic-12.1.0.1.0-1.x86_64.rpm
#* oracle-instantclient12.1-devel-12.1.0.1.0-1.x86_64.rpm
#* oracle-instantclient12.1-sqlplus-12.1.0.1.0-1.x86_64.rpm
# Ajout des paquets au {{package|Koji}}
#* <pre>koji add-pkg centos-6 --owner didier oracle-instantclient12.1-basic</pre>
#* <pre>koji add-pkg centos-6 --owner didier oracle-instantclient12.1-devel</pre>
#* <pre>koji add-pkg centos-6 --owner didier oracle-instantclient12.1-sqlplus</pre>
# Import des paquets dans le {{package|Koji}}<pre>koji import --create-build /mnt/koji/externals/oracle*.rpm</pre>
# Comme les paquets sont juste importés, il est nécessaire de les taggués. On commmence par visualiser les paquets non taggués<pre>koji list-untagged</pre>Comme on s'y attend, trois paquets ne sont pas taggués
#* oracle-instantclient12.1-basic-12.1.0.1.0-1
#* oracle-instantclient12.1-devel-12.1.0.1.0-1
#* oracle-instantclient12.1-sqlplus-12.1.0.1.0-1
# Tag des paquets précédemment importés en centos-6-build
#* <pre>koji tag-pkg centos-6 oracle-instantclient12.1-basic-12.1.0.1.0-1</pre>
#* <pre>koji tag-pkg centos-6 oracle-instantclient12.1-devel-12.1.0.1.0-1</pre>
#* <pre>koji tag-pkg centos-6 oracle-instantclient12.1-sqlplus-12.1.0.1.0-1</pre>
# Régénération du dépôt<pre>koji regen-repo centos-6-build</pre>
 
=== Ajout de paquets sources ===
Il faut tout d'abord avoir une copie de travail du dépôt des sources, accessible en lecture/écriture.
 
Pour cela il faut disposer d'un compte associé à une paire de clés ( publique et privée ) <app>ssh</app>.
# Génération de la paire de clé
#* Sous GNU/Linux, il suffit de lancer la commande<pre> ssh-keygen -t rsa</pre>
#* Sous Windows il faut utiliser le programme <app>puttygen.exe</app> pour générer la paire de clé. La clé publique porte l'extension '''pub''' et la clé privé '''ppk'''.<br>Il faut ensuite utiliser un agent ( ex: <app>pageant.exe</app> )
#Puis il faut insérer le contenu de la clé publique ( à la suite des autres ) dans le fichier <path>/var/lib/git/.ssh/authorized_keys</path> sur le serveur.<br>Afin de tester avant le checkout, on doit pouvoir se connecter au serveur sans mot de passe<pre> ssh git@didier.b2pweb.com</pre>
# Si le login est possible, on peut alors obtenir une copie du dépôt<pre>git clone git@didier.b2pweb.com/rpm</pre>
 
=== Ajout d'un paquet ===
{{Admon/todo}}
=== Mise à jour d'un paquet ===
{{Admon/todo}}
 
== Mise à jour du koji ==
 
La mise à jour du koji est sensible. En effet, les versions doivent correspondre entre le hub, le web, et même les builders.
 
Procédure pour mettre à jour le koji
# '''Sauvegarde''' de l'existant
#* Copie du répertoire /mnt/koji sur le vbox4 en /mnt/koji2
#* Sauvegarde de la base si elle n'est pas locale à la VM
# Export de la VM pour tester la mise à jour
# Démarrage de la VM de test
#* Remontage du nfs vbox4 pour avoir /mnt/koji2 au lieu de /mnt/koji
# Mise à jour de la vm temporaire
# Validation de la mise à jour
# Si la mise à jour est validée
## Mise à jour du koji
## Suppression de la VM de test
## Suppression du répertoire /mnt/koji2 sur le vbox4
## '''Sur les builders''', télécharger les paquets correspondant à cette version de koji afin de conserver la bonne version pour la prochaine mise à jour.<pre>yumdownloader koji koji-builder</pre>
 
== F.A.Q. ==
 
=== Comment supprimer un paquet sans aucun build associé ===
Pour un problème de nom incorrect de paquet ou pour d'autre raisons, il est nécessaire de modifier directement la base de données, car aucune commande existe.
 
Si aucun build n'est associé à ce paquet, il n'est référencé que dans deux tables:
* package
* tag_packages
 
On se place sur le serveur <package>Koji</package> et on se loggue avec l'utilisateur koji
 
# su - koji
$ psql -U koji koji
 
Remplacer commit par rollback si quelque chose ne se passe pas bien, afin d'annuler la transaction.
<syntaxhighlight lang="sql">
begin;
delete from tag_packages where package_id = (select id from package where name = 'SOME-TYPO');
delete from package where name = 'SOME-TYPO';
commit;
</syntaxhighlight>
 
=== BuildrootError: could not init mock buildroot, mock exited with status 30 ===
 
Et dans le fichier <path>root.log</path> associé au build, on retrouve l'erreur: ''Package does not match intended download''
 
Il faut lancer manuellement la régénération du dépôt
koji regen-repo centos-6-build
 
=== Construction du SRPM en erreur ===
 
* Il faut regarder que le répertoire ne contient pas de fichier nommé <path>sources</path>, car koji télécharge les sources en faisant <pre>make sources</pre>et la cible du Makefile est donc à jour.
* Le paquet n'est pas inclus au dépôt. Il faut l'inclure comme ceci<pre>koji add-pkg centos-6 --owner didier <MON PAQUET></pre>


== Utilisation du repository ==
== Utilisation du repository ==


Il suffit de renseigné <package>yum</packages> pour qu'il pointe sur le repository
Il suffit de renseigné <package>yum</package> pour qu'il pointe sur le repository
  http://didier.b2pweb.com/kojifiles/repos/centos-5-build/latest/$arch
  <nowiki>http://koji.b2pweb.com/kojifiles/repos/centos-6-build/latest/$basearch</nowiki>
 
== Skins ==
Modification à partir du thème osg<ref>https://github.com/djw8605/osg-koji-theme</ref>
 
== Références ==
<references/>

Dernière version du 2 juillet 2013 à 08:16

LogoKoji.svg

Généralités

Ajout d'un paquet au repository

Un admin du koji ajoute le paquet et le place sous la responsabilité d'un utilisateur Koji 

koji add-pkg --owner didier centos-5 b2pweb
Idea.png
Construction d'un paquet scratch
Koji permet de construire des paquets sans qu'il soit nécessaire de les ajouter au repository: scratch

La commande de construction devient donc 

koji build --scratch centos-5 b2pweb-1.1.0-8.fc17.src.rpm
Toutefois cette méthode n'est pas recommandé si on cherche à construire un paquet pour notre repository.

Construction d'un paquet

Depuis un paquet source

koji build centos-5 b2pweb-1.1.0-8.fc17.src.rpm

Depuis un système de contrôle de version

Il faut tout d'abord autoriser le serveur et le dépôt sur tous les constructeurs koji ( kojid ).

Ici on déclare deux dépôts de sources:

  • dépôt GIT: git://didier.b2pweb.com/rpm
  • dépôt SVN: http://didier.b2pweb.com/svn/rpm
    Celui-ci étant composé d'un arbre SVN standard, on déclare le répertoire trunk.

Extrait du fichier <path>/etc/kojid/kojid.conf</path> 

; A space-separated list of hostname:repository[:use_common] tuples that kojid is authorized to checkout from (no quotes).
; Wildcards (as supported by fnmatch) are allowed.
; If use_common is specified and is one of "false", "no", "off", or "0" (without quotes), then kojid will not attempt to checkout
; a common/ dir when checking out sources from the source control system.  Otherwise, it will attempt to checkout a common/
; dir, and will raise an exception if it cannot.
allowed_scms=didier.b2pweb.com:/rpm:no didier.b2pweb.com:/svn/rpm/trunk:yes
Warning.png
Paramètre use_common
Il semble y avoir un bug avec le paramètre use_common et l'utilisation d'un dépôt git.

En effet quelque soit la valeur de ce paramètre, un dépôt common sera téléchargé.

Work-Around: Créer un dépôt common vide sur le serveur git.

Le système doit fournir un Makefile qui contient une cible sources, dont la tâche est de fournir les sources via une commande de téléchargement. Si celles-ci sont incluses dans le SCM, la cible doit être vide. 

# Common Makefile
sources:

Il ne reste plus qu'à lancer la construction depuis <app>koji</app>

avec SVN 

koji build centos-5 svn+http://didier.b2pweb.com/svn/rpm/trunk?b2pweb-release#head

avec git 

koji build centos-5 git://didier.b2pweb.com/rpm?b2pweb-release#5153396fc3bf204b74e745759eee33ed5dad0ffe
Important.png
Différence entre les SCM
  • Avec svn, le répertoire common sera téléchargé en plus de celui du paquet en cours
  • Avec git c'est un dépôt common qui sera ajouté et l'intégralité du dépôt rpm sera téléchargé.

Interface Web

KojiwebScreenshot.png

Dépôt B2PWeb

Importer des paquets sources et binaires

Warning.png
Import
Il est impératif d'importer les paquets RPM pour chaque architecture gérée (intel 32/64 bits, etc ...). De plus le paquet RPM source devra être importer en premier. Il y a donc au minimum import de deux paquets RPM.

<package>Koji</package> n'accepte pas facilement l'import de paquet RPM binaire sans paquet RPM source correspondant.

Import standard

Sur le <package>Koji</package> B2PWeb, il n'y a que deux architectures définies :

  • i386 ou i686 ( suivant la version de la distribution )
  • x86_64

Afin de maintenir une certaine homogénéité dans le dépôt, il faudra importer les paquets RPM binaires pour les deux architectures.

Le SRPM est obligatoirement importé en premier.

  1. Import du paquet RPM source
    koji add-pkg centos-5 foo.src.rpm
  2. Import des paquets RPM binaires
    • Paquet 32 bits
      koji add-pkg centos-5 foo.i386.rpm
    • Paquet 64 bits
      koji add-pkg centos-5 foo.x86_64.rpm

Import sans SRPM

Exemple en intégrant les paquets pour une base Oracle.

  1. Téléchargement des RPM depuis le site Oracle dans le dossier <path>/mnt/koji/externals</path>
    • oracle-instantclient12.1-basic-12.1.0.1.0-1.i386.rpm
    • oracle-instantclient12.1-devel-12.1.0.1.0-1.i386.rpm
    • oracle-instantclient12.1-sqlplus-12.1.0.1.0-1.i386.rpm
    • oracle-instantclient12.1-basic-12.1.0.1.0-1.x86_64.rpm
    • oracle-instantclient12.1-devel-12.1.0.1.0-1.x86_64.rpm
    • oracle-instantclient12.1-sqlplus-12.1.0.1.0-1.x86_64.rpm
  2. Ajout des paquets au Koji 
    • koji add-pkg centos-6 --owner didier oracle-instantclient12.1-basic
    • koji add-pkg centos-6 --owner didier oracle-instantclient12.1-devel
    • koji add-pkg centos-6 --owner didier oracle-instantclient12.1-sqlplus
  3. Import des paquets dans le Koji
    koji import --create-build /mnt/koji/externals/oracle*.rpm
  4. Comme les paquets sont juste importés, il est nécessaire de les taggués. On commmence par visualiser les paquets non taggués
    koji list-untagged
    Comme on s'y attend, trois paquets ne sont pas taggués
    • oracle-instantclient12.1-basic-12.1.0.1.0-1
    • oracle-instantclient12.1-devel-12.1.0.1.0-1
    • oracle-instantclient12.1-sqlplus-12.1.0.1.0-1
  5. Tag des paquets précédemment importés en centos-6-build 
    • koji tag-pkg centos-6 oracle-instantclient12.1-basic-12.1.0.1.0-1
    • koji tag-pkg centos-6 oracle-instantclient12.1-devel-12.1.0.1.0-1
    • koji tag-pkg centos-6 oracle-instantclient12.1-sqlplus-12.1.0.1.0-1
  6. Régénération du dépôt
    koji regen-repo centos-6-build

Ajout de paquets sources

Il faut tout d'abord avoir une copie de travail du dépôt des sources, accessible en lecture/écriture.

Pour cela il faut disposer d'un compte associé à une paire de clés ( publique et privée ) <app>ssh</app>.

  1. Génération de la paire de clé
    • Sous GNU/Linux, il suffit de lancer la commande
       ssh-keygen -t rsa
    • Sous Windows il faut utiliser le programme <app>puttygen.exe</app> pour générer la paire de clé. La clé publique porte l'extension pub et la clé privé ppk.
      Il faut ensuite utiliser un agent ( ex: <app>pageant.exe</app> )
  2. Puis il faut insérer le contenu de la clé publique ( à la suite des autres ) dans le fichier <path>/var/lib/git/.ssh/authorized_keys</path> sur le serveur.
    Afin de tester avant le checkout, on doit pouvoir se connecter au serveur sans mot de passe
     ssh git@didier.b2pweb.com
  3. Si le login est possible, on peut alors obtenir une copie du dépôt
    git clone git@didier.b2pweb.com/rpm

Ajout d'un paquet

Todo.png
TODO

Mise à jour d'un paquet

Todo.png
TODO


Mise à jour du koji

La mise à jour du koji est sensible. En effet, les versions doivent correspondre entre le hub, le web, et même les builders.

Procédure pour mettre à jour le koji

  1. Sauvegarde de l'existant
    • Copie du répertoire /mnt/koji sur le vbox4 en /mnt/koji2
    • Sauvegarde de la base si elle n'est pas locale à la VM
  2. Export de la VM pour tester la mise à jour
  3. Démarrage de la VM de test
    • Remontage du nfs vbox4 pour avoir /mnt/koji2 au lieu de /mnt/koji
  4. Mise à jour de la vm temporaire
  5. Validation de la mise à jour
  6. Si la mise à jour est validée
    1. Mise à jour du koji
    2. Suppression de la VM de test
    3. Suppression du répertoire /mnt/koji2 sur le vbox4
    4. Sur les builders, télécharger les paquets correspondant à cette version de koji afin de conserver la bonne version pour la prochaine mise à jour.
      yumdownloader koji koji-builder

F.A.Q.

Comment supprimer un paquet sans aucun build associé

Pour un problème de nom incorrect de paquet ou pour d'autre raisons, il est nécessaire de modifier directement la base de données, car aucune commande existe.

Si aucun build n'est associé à ce paquet, il n'est référencé que dans deux tables:

  • package
  • tag_packages

On se place sur le serveur <package>Koji</package> et on se loggue avec l'utilisateur koji 

# su - koji
$ psql -U koji koji

Remplacer commit par rollback si quelque chose ne se passe pas bien, afin d'annuler la transaction. 

begin;
delete from tag_packages where package_id = (select id from package where name = 'SOME-TYPO');
delete from package where name = 'SOME-TYPO';
commit;

BuildrootError: could not init mock buildroot, mock exited with status 30

Et dans le fichier <path>root.log</path> associé au build, on retrouve l'erreur: Package does not match intended download

Il faut lancer manuellement la régénération du dépôt 

koji regen-repo centos-6-build

Construction du SRPM en erreur

  • Il faut regarder que le répertoire ne contient pas de fichier nommé <path>sources</path>, car koji télécharge les sources en faisant 
    make sources
    et la cible du Makefile est donc à jour.
  • Le paquet n'est pas inclus au dépôt. Il faut l'inclure comme ceci
    koji add-pkg centos-6 --owner didier <MON PAQUET>

Utilisation du repository

Il suffit de renseigné <package>yum</package> pour qu'il pointe sur le repository 

http://koji.b2pweb.com/kojifiles/repos/centos-6-build/latest/$basearch

Skins

Modification à partir du thème osg[1]

Références

  1. ↑ https://github.com/djw8605/osg-koji-theme
Récupérée de « https://wikiold.home.tartarefr.eu/index.php?title=Koji/Utilisation&oldid=1837 »