Mettre en place un système de construction de RPM Koji

Présentation

Koji est une suite logicielle de construction de RPM. Il utilise mock pour créer des environnements chrootés et y effectuer les builds.

Architecture du koji

• Koji-Hub
  C'est le centre nerveux de toutes les opérations Koji. Il s'agit d'un serveur XML-RPC fonctionnant sous mod_python pour Apache. koji-hub est passif : il ne reçoit que les appels XML-RPC et s'appuie sur les autres outils de la suite pour la construction. koji-hub est le seul composant qui a un accès direct à la base de données et est l'un des deux composants qui ont un accès en écriture au système de fichiers.
• Kojid ou Koji-builder
  C'est le démon de compilation qui s'exécute sur chacune des machines de construction. Sa principale responsabilité est de scruter les demandes de construction entrantes et de les exécuter. Pour cela, kojid interroge koji-hub. Kojid est également responsable d'autres tâches que la construction : la création d'images d'installation par exemple. kojid utilise Mock pour la construction. Il crée également un buildroot vierge pour chaque génération. kojid est écrit en Python et communique avec koji-hub par l'intermédiaire de XML-RPC.
• Koji-Web
  C'est un ensemble de scripts qui s'exécutent avec mod_python et utilise le moteur de templates Cheetah pour fournir une interface web à Koji. Il agit comme un client à koji-hub en offrant une interface d'aministration limitée. koji-Web expose un grand nombre d'informations et fournit également un moyen pour certaines opérations, telles que l'annulation de builds.
• Koji-client
  C'est une interface en ligne de commande ( CLI = Command Line Interface ) écrit en Python qui fournit de nombreux hooks à Koji. Il permet à l'utilisateur d'interroger la plupart des données ainsi que d'effectuer des actions telles que l'ajout d'utilisateurs et de lancer la construction des demandes.
• Kojira
  C'est un démon qui garde la racine de construction repodata à jour. Il est responsable de l'enlèvement des racines redondantes et du nettoyage après une demande de construction est terminée.

Les composants de Koji peuvent être installés sur des serveurs différents. La seule obligation est d'autoriser la communication entre les différents composants de la suite.

Koji supporte nativement l'authentification par serveur Kerberos et par certificat SSL. Seul koji-client supporte l'authentification par mot de passe. De ce fait, l'authentification par mot de passe ne sera même pas abordée.

La méthode d'authentification doit être choisie dès le début de l'installation. Dans la suite de ce document, nous mettrons en place la méthode SSL.

Koji utilise beaucoup d'espace disque dans son répertoire primaire /mnt/koji. De plus Mock en utilisera beaucoup aussi sur les répertoires /var/lib/mock et /var/cache/mock. Il vaut mieux prévoir des partitions dédiées à ces répertoires ( les répertoires de Mock doivent appartenir au groupe mock et avoir les permissions 02755 ).

Pour un aperçu rapide des outils utilisés : yum, mock, Koji (et tous ses composants), mash, et comment ils fonctionnent ensemble, il existe une excellente présentation ^[1] créée par Steve Traylen du CERN.

Le dépôt git de RussianFedora avec les fichiers de configuration de Koji ^[2]

Connaissances requises

• Connaissances basiques de l'authentification par certificat SSL.
• Connaissances basiques de création de base de données PostgreSQL and d'importation de structure de base
• Connaissances basiques de l'outil psql
• Connaissances basiques de configuration d'Apache
• Connaissances basiques des outils yum/createrepo/mock
• Connaissances basiques de la ligne de commandes
• Connaissances basiques sur la construction de RPM

Dépendances

Sur le serveur (koji-hub / kojiweb )

• httpd
• mod_ssl
• postgresql-server
• mod_wsgi
• MySQL-python

Sur les constructeurs ( kojid )

• mock
• setarch
• rpm-build
• createrepo

Si le mode d'authentification choisie est Kerberos, il faudra aussi que le réseau local ait un serveur DNS et une dépendance supplémentaire est à installer sur le serveur et les constructeurs.

• mod_auth_kerb

Espace disque

comme Koji utilise Mock, les répertoires /var/lib/mock et /var/cache/mock grossiront mais une purge de ces répertoires est mise en place par Koji.

Les répertoires qui vont grossir au fur et à mesure de l'utilisation sont ceux de:

• Mock:
• La base de données: /var/lib/psql
• Le répertoire principal de Koji: /mnt/koji
• Le répertoire des dépôts: /mnt/repo

Il sera donc judicieux de leur attribuer une partition spécifique avec une taille dynamique (lvm)

Génération des certificats SSL

Ces certificats serviront à l'authentification des éléments de Koji sur le koji-hub.

Création du répertoire des certificats

 mkdir /etc/pki/koji && cd /etc/pki/koji

Création du fichier de configuration de nos futurs certificats

/etc/pki/koji/ssl.cnf

HOME                    = .
RANDFILE                = .rand

[ca] 
default_ca              = ca_default

[ca_default] 
dir                     = .
certs                   = $dir/certs
crl_dir                 = $dir/crl
database                = $dir/index.txt
new_certs_dir           = $dir/newcerts
certificate             = $dir/%s_ca_cert.pem
private_key             = $dir/private/%s_ca_key.pem
serial                  = $dir/serial
crl                     = $dir/crl.pem
x509_extensions         = usr_cert
name_opt                = ca_default
cert_opt                = ca_default
default_days            = 3650
default_crl_days        = 30
default_md              = sha256
preserve                = no
policy                  = policy_match

[policy_match] 
countryName             = match
stateOrProvinceName     = match
organizationName        = match
organizationalUnitName  = optional
commonName              = supplied
emailAddress            = optional

[req] 
default_bits            = 4096
default_keyfile         = privkey.pem
distinguished_name      = req_distinguished_name
attributes              = req_attributes
x509_extensions         = v3_ca # The extentions to add to the self signed cert
string_mask             = MASK:0x2002

[req_distinguished_name] 
countryName                     = Country Name (2 letter code)
countryName_default             = FR
countryName_min                 = 2
countryName_max                 = 2
stateOrProvinceName             = State or Province Name (full name)
stateOrProvinceName_default     = Languedoc Roussilon
localityName                    = Locality Name (eg, city)
localityName_default            = Beaucaire
0.organizationName              = Organization Name (eg, company)
0.organizationName_default      = Home
organizationalUnitName          = Organizational Unit Name (eg, section)
commonName                      = Common Name (eg, your name or your server\'s hostname)
commonName_max                  = 64
emailAddress                    = Email Address
emailAddress_max                = 64

[req_attributes] 
challengePassword               = A challenge password
challengePassword_min           = 4
challengePassword_max           = 20
unstructuredName                = An optional company name

[usr_cert] 
basicConstraints                = CA:FALSE
nsComment                       = "OpenSSL Generated Certificate"
subjectKeyIdentifier            = hash
authorityKeyIdentifier          = keyid,issuer:always

[v3_ca] 
subjectKeyIdentifier            = hash
authorityKeyIdentifier          = keyid:always,issuer:always
basicConstraints                = CA:true

Modification du fichier ssl.cnf
Bien que cela ne soit pas obligatoire, il est recommandé d'éditer les champs suffixés par _default dans la section [req_distinguished_name], afin de coller aux informations du serveur en cours d'installation
Cela vous permettra d'accepter directement les valeurs proposées par défaut à la génération des certificats.
Les autres sections n'ont pas besoin d'être éditées.

Génération de l'autorité de certification

Toujours depuis le répertoire /etc/pki/koji, on initialise notre générateur et on génère l’autorité de certification. Celle-ci se compose d'une paire clé/certificat qui servira à signer tous les autres certificats.

Ici, le CN sera obligatoirement le nom d'hôte du serveur (FQDN), les autres renseignements ne sont pas bloquants pour la suite.

cd /etc/pki/koji/
mkdir {certs,private,confs}
touch index.txt
echo 01 > serial
openssl genrsa -out private/koji_ca_cert.key 4096
openssl req -config ssl.cnf -new -x509 -days 3650 -key private/koji_ca_cert.key \
-out koji_ca_cert.crt -extensions v3_ca

Générer les certificats des composants de Koji et le certificat de l'administrateur

Chaque composant de Koji a besoin d'un certificat. Kojihub et kojiweb ont besoin d'avoir le nome d'hôte pleinement qualifié (FQDN) en CN, on se servira de OU pour distinguer les certificats. Pour les autres certificats, le CN doit être le nom du composant ( kojira ), le login du compte administrateur ou le nom du builder qui sera définit avec koji-client. Par simplicité, on va se servir de ces scripts pour générer les certificats des composants et les certificats web.

Script de génération des certificats

/etc/pki/koji/generate-certificate.sh

#!/bin/bash
#if you change your certificate authority name to something else you will need to change the caname value to reflect the change.
caname=koji

# user is equal to parameter one or the first argument when you actually run the script
user=$1

if [[ "$user" == "" ]]
then
	echo "Usage: $(basename $0) USER"
	exit
fi

echo "Generate certificates for \"${user}\""

openssl genrsa -out certs/${user}.key 4096

cat ssl.cnf | sed 's/insert_hostname/'${user}'/'> ssl2.cnf

openssl req -config ssl2.cnf -new -nodes -out certs/${user}.csr -key certs/${user}.key

openssl ca -config ssl2.cnf -keyfile private/${caname}_ca_cert.key -cert ${caname}_ca_cert.crt \
	-out certs/${user}.crt -outdir certs -infiles certs/${user}.csr

cat certs/${user}.crt certs/${user}.key > ${user}.pem

mv ssl2.cnf confs/${user}-ssl.cnf

Script de génération des certificats pour les navigateurs Web

/etc/pki/koji/generate-web-certificate.sh

#!/bin/bash
#if you change your certificate authority name to something else you will need to change the caname value to reflect the change.
caname=koji

# user is equal to parameter one or the first argument when you actually run the script
user=$1

if [[ "$user" == "" ]]
then
	echo "Usage: $(basename $0) USER"
	exit
fi

echo "Generate web certificates for \"${user}\""

openssl pkcs12 -export -inkey certs/${user}.key -in certs/${user}.crt -CAfile ${caname}_ca_cert.crt \
	-out certs/${user}_browser_cert.p12

On génère les certificats comme cela pour tous les composants et users du tableau récapitulatif:

cd /etc/pki/koji/
./generate-certificate.sh kojiweb

Le user choisi pour être le koji admin est le user didier.

De plus pour les utilisateurs (réels) de koji, on générera les certificats web comme ceci:

./generate-web-certificate.sh didier

Copier les certificats dans le home de utilisateur admin

On copie le certificat correspondant à l'administrateur du Koji, et l'autorité de certification dans son home.

mkdir ~/.koji
cp /etc/pki/koji/didier.pem ~/.koji/client.crt
cp /etc/pki/koji/koji_ca_cert.crt ~/.koji/clientca.crt
cp /etc/pki/koji/koji_ca_cert.crt ~/.koji/serverca.crt

Modification des paramètres par défaut
Pour modifier des paramètre d'un client sans modifier la configuration générale, il faut copier le fichier /etc/koji.conf dans le home de l'utilisateur ~/.koji/config et y effectuer les modifications dans celui-ci.

Mise en place des principals Kerberos

Le serveur Kerberos doit pouvoir être trouvé grâce au DNS. Le point final indique que l'hôte est pleinement qualifié (FQDN).

_kerberos._udp    IN SRV  10 100 88 kerberos.didier-linux.eu.

Ajout des utilisateurs Koji aux alias du serveur de mail local

Bien évidemment, un serveur sendmail en local est déjà configuré et opérationnel.

Appairer les utilisateurs Koji aux véritables adresses mail.

/etc/aliases

# Person who should get root's mail
root:           didier@didier-linux.eu
didier:         didier@didier-linux.eu

Puis lancer la régénération des alias

# newaliases

Serveur PostgreSQL

Une fois l'autentification mise en place, nous avons besoin d'installer un serveur PostgreSQL, de le configurer et de mettre en place la structure de la base de données pour Koji. Fichiers de Configuration :

• /var/lib/pgsql/data/pg_hba.conf
• /var/lib/pgsql/data/postgresql.conf

Installation du serveur PostgreSQL

yum install postgresql-server

Initialisation de la base de données PostgreSQL

Les commandes suivantes initialise le serveur PostgreSQL et le démarre. Le script d'init a été converti à systemd sur les distributions Fedora 16 et supérieures et la cible initdb du script d'init a été supprimée. On initialise directement avec les commandes du SGBD.

su - postgres -c "PGDATA=/var/lib/pgsql/data initdb"
systemctl start postgresql.service

Initialisation du SGBD sur les distributions sysVinit

service postgresql initdb && service postgresql start

Compte utilisateur

Mise en place du compte koji sur le système (utilisateur unix) et mise en place d'un mot de passe.

useradd koji
passwd koji

Setup de PostgreSQL et import de la structure de la base

Création de l'utilisateur PostgreSQL koji et création de sa base de données, puis import de la structure.

Import de la structure
Il est important laisser le joker (*) afin de ne pas se restreindre à une version particulière de Koji. Durant des test, il a été découvert que la restriction à une version spécifique de Koji ne créé pas correctement toutes les tables.

su - postgres
createuser koji
Shall the new role be a superuser? (y/n) n
Shall the new role be allowed to create databases? (y/n) n
Shall the new role be allowed to create more new roles? (y/n) n
createdb -O koji koji
logout

su - koji
psql koji koji < /usr/share/doc/koji*/docs/schema.sql
exit

Autorisation de Koji-web et Koji-hub aux resources

Dans cet exemple, Koji-web et Koji-hub sont démarrés sur localhost.

Ces paramètres doivent être ajouter avant les autres. Fichier /var/lib/pgsql/data/pg_hba.conf

/var/lib/pgsql/data/pg_hba.conf

host    koji        koji        127.0.0.1/32          trust
host    koji        koji          ::1/128             trust

On peut aussi utiliser les sockets UNIX. La variable DBHost variable ne doit pas être renseigné avec cette méthode.

/var/lib/pgsql/data/pg_hba.conf

local   koji        apache                            trust
local   koji        apache      127.0.0.1/32          trust
local   koji        apache        ::1/128             trust
local   koji        koji                              trust

Application des changements à chaud

Informer postgreSQL que les fichiers de configuration doivent être relus.

root@localhost$ su - postgres
postgres@localhost$ pg_ctl reload
postgres@localhost$ exit

Ajout du premier administrateur du Koji à la base PostgreSQL

Le premier administrateur du Koji doit être ajouter à la main avec des commandes SQL. Une fois ajouté avec les droits administarteur, Il pourra gérer les autres utilisateurs de Koji avec l'outil d'administration en ligne de commande.

Pour l'authentifiaction SSL ou Kerberos, il n'y a pas besoin de mettre un mot de passe.

root@localhost$ su - koji
koji@localhost$ psql
koji=> insert into users (name, status, usertype) values ('admin-user-name', 0, 0);

Se donner les droits admin

Commande permettant de se donner les droits administrateur. Pour la lancer, on doit connaitre l'ID de l'utilisateur.

koji=> insert into user_perms (user_id, perm_id, creator_id) values (<ID of user inserted above>, 1, <ID of user inserted above>);

Connaitre l'ID des utilisateurs
Pour connaitre les IDs des utilisateurs du Koji, on doit lancer une commande SQL.

koji=> select * from users;

A ce stade, aucune action ne peut être démarrée tant que le kojihub n'est pas configuré et le serveur web démarré.

Koji Hub

koji-hub est le centre nerveux de toutes les opérations Koji. Il s'agit d'un serveur XML-RPC fonctionnant sous mod_python pour Apache. koji-hub est passif : il ne reçoit que les appels XML-RPC et s'appuie sur les autres outils de la suite pour la construction. koji-hub est le seul composant qui a un accès direct à la base de données et est l'un des deux composants qui ont un accès en écriture au système de fichiers.

Fichiers de Configuration

• /etc/httpd/conf/httpd.conf
• /etc/httpd/conf.d/kojihub.conf
• /etc/httpd/conf.d/ssl.conf (when using ssl auth)
• /etc/koji-hub/hub.conf
• /etc/koji.conf

Le répertoire de travail sera /mnt/koji.

Répertoire de travail de Koji
Si le répertoire de travail de Koji n'est pas /mnt/koji, il est impératif de créer un lien symbolique du répertoire de travail de Koji dans /mnt:

ln -s /path/to/koji/datadir /mnt/koji

Installation de koji-hub

yum install koji-hub httpd mod_ssl

Configuration

On bride tout d'abord le nombre maximum de requête sur le serveur apache à une valeur plus raisonnable afin de prévenir une saturation et/ou un crash du serveur web.

/etc/httpd/conf/httpd.conf

<IfModule prefork.c>
...
MaxRequestsPerChild  100
</IfModule>
<IfModule worker.c>
...
MaxRequestsPerChild  100
</IfModule>

Le répertoire /mnt/koji/packages doit être accessible par HTTP. On ajoute donc un alias.

/etc/httpd/conf.d/kojipackages.conf

Alias /packages "/mnt/koji/packages"
<Directory "/mnt/koji/packages">
        Options Indexes
        AllowOverride None
        Order allow,deny
        Allow from all
</Directory>

/etc/httpd/conf.d/ssl.conf

LoadModule ssl_module modules/mod_ssl.so

Listen 443

SSLPassPhraseDialog exec:/usr/libexec/httpd-ssl-pass-dialog

SSLSessionCache         shmcb:/var/cache/mod_ssl/scache(512000)
SSLSessionCacheTimeout  300

SSLMutex default

SSLRandomSeed startup file:/dev/urandom  256
SSLRandomSeed connect builtin

SSLCryptoDevice builtin

<VirtualHost _default_:443>
  ErrorLog logs/ssl_error_log
  TransferLog logs/ssl_access_log
  LogLevel warn

  SSLEngine on
  SSLProtocol all -SSLv2
  SSLCipherSuite RC4-SHA:AES128-SHA:ALL:!ADH:!EXP:!LOW:!MD5:!SSLV2:!NULL

  SSLCertificateFile /etc/pki/koji/certs/kojihub.crt
  SSLCertificateKeyFile /etc/pki/koji/certs/kojihub.key
  SSLCertificateChainFile /etc/pki/koji/koji_ca_cert.crt
  SSLCACertificateFile /etc/pki/koji/koji_ca_cert.crt
  SSLVerifyClient require
  SSLVerifyDepth  10

  <Files ~ "\.(cgi|shtml|phtml|php3?)$">
    SSLOptions +StdEnvVars
  </Files>
  <Directory "/var/www/cgi-bin">
    SSLOptions +StdEnvVars
  </Directory>

  SetEnvIf User-Agent ".*MSIE.*" \
         nokeepalive ssl-unclean-shutdown \
         downgrade-1.0 force-response-1.0

  CustomLog logs/ssl_request_log \
          "%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"
</VirtualHost>

/etc/httpd/conf.d/kojihub.conf

Alias /kojihub /usr/share/koji-hub/kojixmlrpc.py

<Directory "/usr/share/koji-hub">
    Options ExecCGI
    SetHandler wsgi-script
    Order allow,deny
    Allow from all
</Directory>

Alias /kojifiles "/mnt/koji/"

<Directory "/mnt/koji">
    Options Indexes SymLinksIfOwnerMatch
    AllowOverride None
    Order allow,deny
    Allow from all
</Directory>

<Location /kojihub/ssllogin>
        SSLVerifyClient require
        SSLVerifyDepth  10
        SSLOptions +StdEnvVars
</Location>

<Location /kojihub>
        SSLOptions +StdEnvVars
</Location>

/etc/koji-hub/hub.conf

[hub]
DBName = koji
DBUser = koji
DBHost = localhost
KojiDir = /mnt/koji

DNUsernameComponent = CN
ProxyDNs = C=FR,ST=Languedoc Roussillon,L=Beaucaire,O=Home,OU=kojiweb,CN=koji.didier-linux.eu,emailAddress=root@didier-linux.eu

LoginCreatesUser = On
KojiWebURL = http://koji.didier-linux.eu/koji
EmailDomain = didier-linux.eu
NotifyOnSuccess = True

/etc/koji.conf

[koji]
server = http://koji.didier-linux.eu/kojihub
weburl = http://koji.didier-linux.eu/koji
topurl = http://koji.didier-linux.eu/kojifiles
topdir = /mnt/koji
cert = ~/.koji/client.crt
ca = ~/.koji/clientca.crt
serverca = ~/.koji/serverca.crt

Configuration de SELinux

Si le mode enforcing est utilisé, on doit autoriser apache à acceder au serveur SGBD/PostgreSQL. Même si le mode est permissive, il est recommandé de lancer la commande suivante afin de se prémunir d'un changement de mode de SELinux.

setsebool -P httpd_can_network_connect_db 1

Squelette des fichiers Koji

Avant que les autres composants de Koji puissent fonctionner correctement, On doit créer la structure et modifié les droits de celui-ci.

cd /mnt
mkdir koji
cd koji
mkdir {packages,repos,work,scratch}
chown apache.apache *

Ici, apache peut être redémarré et on peut effectuer des opérations minimales sur notre serveur Koji via le client en ligne de commande: gestion des utilisateurs et des constructeurs.

Il faut s'assurer que le client est configuré par défaut ( fichier /etc/koji.conf et que les certificats sont en place dans le home de l'administrateur.

Fichier de configuration alternatif
Si un fichier de configuration personnel autre que ~/.koji/config est utilisé, il faut utilisé la commande koji avec l'option -c.

La commande suivante teste le login administrateur sur le serveur Koji.

koji call getLoggedInUser

Droit des daemons
Kojira a besoin du privilège repo avant le lancement du daemon. C'est pourquoi il est vivement recommandé de créer cet utilisateur maintenant et de lui ajouter le privilège

koji add-user kojira
koji grant-permission repo kojira

Pour des raisons similaires, les hôtes de constructions doivent être ajoutés avant le démarrage du daemon kojid.

koji add-host kojibuilder1 x86_64 i386
koji add-host kojibuilder2 ppc ppc64
koji add-host kojibuilder3 ia64

Koji Web - Interface for the Masses

Koji-web est un jeu de scripts qui tournent avec mod_wsgi et qui utilise le moteur de modèle Cheetah pour fournir une interface web à Koji. Koji-web affiche beaucoup d'informations et propose même quelques opérations comme l'abandon de tâche.

Fichiers de Configuration:

• /etc/kojiweb/web.conf
• /etc/httpd/conf.d/kojiweb.conf
• /etc/httpd/conf.d/ssl.conf

Installation de Koji-Web:

yum install koji-web mod_ssl

Configuration obligatoire

La configuration doit fournir à Koji-web les URLs d'accès à Koji-hub, aux paquets koji (builds) et à sa propre interface. Il est judicieux de modifier aussi le secret (directive PythonOption Secret.

Avec l'authentification SSL, elle doit aussi fournir le nom des certificats à utiliser et la directive PythonOption WebCert doit contenir la clé publique ET la clé privée.

/etc/kojiweb/web.conf

[web]
SiteName = koji
KojiTheme = didier

KojiHubURL http://koji.didier-linux.eu/kojihub
KojiFilesURL http://www.didier-linux.eu/kojifiles

WebCert /etc/pki/koji/kojiweb.pem
ClientCA /etc/pki/koji/koji_ca_cert.crt
KojiHubCA /etc/pki/koji/koji_ca_cert.crt

LoginTimeout 72
Secret CHANGE_ME

LibPath = /usr/share/koji-web/lib

Configuration Optionnelle

Il faut éditer le fichier /etc/httpd/conf.d/kojiweb.conf pour configurer l'authentification choisie.

/etc/httpd/conf.d/kojiweb.conf

<Location /koji/login>
SSLOptions +StdEnvVars
</Location>

/etc/httpd/conf.d/ssl.conf

SSLVerifyClient require
SSLVerifyDepth  10

Interface Web opérationnelle

L'interface Web du koji est maintenant accessible et la plupart des opérations de lecture doivent fonctionner et chaque utilisateur doit pouvoir se connecter.

Koji Daemon - Builder

Kojid est le daemon de construction qui tourne sur chaque constructeur. son rôle principale est de traiter les requêtes de construction. Koji ne se limite cependant pas aux tâches de construction puisqu'il peut aussi construire des images ISO, des disques virtuels (appliances). Kojid utilise mock pour créer des environnements de construction minimaliste et en créé pour chaque construction. Ceci permet le compartimentage des constructions et les constructions ne peuvent pas se gêner les unes les autres. Kojid est écrit en python et communique avec le hub via XML-RPC.

fichiers de Configuration

• Configuration du daemon Kojira: /etc/kojid/kojid.conf
• Variables de lancement du daemon: /etc/sysconfig/kojid

Installation de kojid:

yum install koji-builder

Configuration générale

Le fichier de configuration de chaque constructeur doit être édité afin que la directive server pointe sur l'hôte supportant le Koji-hub. La directive user doit contenir le nom d'hôte du constructeur.

/etc/kojid/kojid.conf

; The URL for the xmlrpc server
server=http://hub.example.com/kojihub

; the username has to be the same as what you used with add-host
; in this example follow as below
user = kojibuilder1.example.com

La directive workdir peut être différente entre les constructeurs mais elle ne doit pas être le répertoire de travail du Koji (/mnt/koji)

/etc/kojid/kojid.conf

; The directory root for temporary storage
workdir=/tmp/koji

Configuration des certificats SSL

Ces entrées doivent être éditées pour pointer sur les bons certificats générés précédemment.

/etc/kojid/kojid.conf

;client certificate
; This should reference the builder certificate we created above, for
; kojibuilder1.example.com
cert = /etc/kojid/kojid.pem

;certificate of the CA that issued the client certificate
ca = /etc/kojid/koji_ca_cert.crt

;certificate of the CA that issued the HTTP server certificate
serverca = /etc/kojid/koji_ca_cert.crt

Copie des certificats sur l'hôte
Les certificats SSL doivent être copiés depuis l'hôte abritant le Koji-hub sur les constructeurs dans le répertoire /etc/kojid pour que les constructeurs puissent s'authentifier.

Ajout d'un hôte à la base de données des constructeurs

Il faut maintenant ajouter l'hôte à la base de données des constructeurs afin qu'il puisse être utilisé par Koji-hub.

L'ajout doit être fait avant le premier démarrage du daemon de construction
Sinon, il faudra purger les entrées à la main dans les tables sessions et users avant de pouvoir démarrer avec succès le daemon.

koji add-host kojibuilder1.didier-linux.eu i386 x86_64

Le premier argument après la commande est le nom d'hôte du constructeur. Le second argument spécifie l'(les) architecture(s) utilisées par l'hôtes.

Ajout de l'hôte au canal de création

Les canaux sont un moyen de contrôler quel constructeur fait quoi. Par défaut les hôtes sont ajouté au canal default. Il faut qu'au moins quelques uns (1 au minimum) soient ajoutés au canal createrepo pour pouvoir lancer les travaux kojira sur les dépôts.

koji add-host-to-channel kojibuilder1.didier.eu createrepo

Capacité

La capacité d'un hôte par défaut est de 2, ce qui veut dire que le daemond econstruction n'acceptera pas de travail supplémentaire si le load average est supérieur à 2. Ce paramètre est différent de celui du nombre maximal de travaux (fichier de configuration). Avant que ledaemon de construction n'accepte un nouveau travail, il s'assure que le load average est inférieur à la capacité et que le nombre de travaux est inférieur au nombre maximal. Toutefois, à l'ère des CPU multi-coeurs, un load average de 2 est insuffisant pour consommer 100% des ressources du système. Il n'y a pas d'option pour définir la capacité en ligne de commande, cela doit être fait en base (psql).

koji@localhost$ psql koji
koji=# select (id, name, capacity) from host;
              row               
--------------------------------
 (1,kojibuilder1.didier-linux.eu,2)
 (2,kojibuilder2.didier-linux.eu,2)
(2 rows)

koji=# update host set capacity = 16 where id = 1;
UPDATE 1
koji=# 

Démarrage du daemon Kojid

Une fois le constructeur ajouté à la base de données, on peut démarrer son daemon de construction.

systemctl start kojid

On vérifie dans le fichier /var/log/kojid.log qur le daemon a bien démarré. Si aucune erreur n'est rapportée, c'est que le daemon doit être correctement configuré et démarré. On peut le vérifier sur l'interface Koji-web dans l'onglet hôtes. Cette page affiche le liste des constructeurs et leur status.

Kojira - Création et maintenance du dépôt

Fichiers de Configuration:

• Configuration du daemon Kojira: /etc/kojira/kojira.conf
• Variables de lancement du daemon: /etc/sysconfig/kojira

Installation de kojira

yum install koji-utils

Configuration générale

La directive server a besoin de pointer sur le koji-hub.

/etc/kojira/kojira.conf

; The URL for the xmlrpc server
server=http://koji.didier-linux.eu/kojihub

Note importante

• Kojira a besoin d'un accès en lecture/écriture sur /mnt/koji.
• Il ne devrait exister qu'une seule instance de kojira à la fois.
• Il n'est pas recommandé de lancer kojira sur les constructeurs, car ceux-ci n'ont besoin que d'un accès en lecture seule sur le répertoire /mnt/koji.

Configuration de l'authentification SSL

/etc/kojira/kojira.conf

;client certificate
; This should reference the kojira certificate we created above
cert = /etc/pki/koji/kojira.pem

;certificate of the CA that issued the client certificate
ca = /etc/pki/koji/koji_ca_cert.crt

;certificate of the CA that issued the HTTP server certificate
serverca = /etc/pki/koji/koji_ca_cert.crt

The local user kojira runs as needs to be able to read and write to /mnt/koji/repos/. If the volume that directory resides on is root-squashed or otherwise unmodifiable by root, you can set RUNAS= to a user that has the required privileges.

/etc/sysconfig/kojira

FORCE_LOCK=Y
KOJIRA_DEBUG=N
KOJIRA_VERBOSE=Y
RUNAS=root

Ajout de l'utilisateur kojira à Koji

Si cela n'a pas été déjà fait, création de l'utilisateur kojira et ajout du droit repo à celui-ci. Cela doit être fait avec le compte de l'administrateur de Koji.

koji add-user kojira
koji grant-permission repo kojira

Démarrage du deamon Kojira

systemctl start kojira.service

On vérifie dans le fichier /var/log/kojira/kojira.log que kojira a bien démarré.

SELinux

semanage fcontext -a -t httpd_sys_rw_content_t '/mnt/koji(/.*)?'
restorecon -Rv /mnt/koji

Notes

1. ↑ Présentation des outils de création/gestion des RPM | Version online
   Version offline: Fichier:MockKojiMash.pdf ( non mise à jour )
2. ↑ https://github.com/RussianFedora/koji-setup