Koji/Installation

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.

• 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.
• Kojid
  kojid 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
  koji-web 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
  koji-client est une CLI écrit en Python qui fournit de nombreux hooks à Koji. Il permetl'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
  kojira 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 <path>/mnt/koji</path>. De plus Mock en utilisera beaucoup aussi sur les répertoires <path>/var/lib/mock</path> et <path>/var/cache/mock</path>. 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 créée par Steve Traylen du CERN.

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_python ( Pour les versions de Koji < 1.7 )
• MySQL-python

Sur les constructeurs ( koji-builder alias kojid )

• mock
• setarch
• rpm-build
• createrepo

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 : <path>/etc/pki/koji/ssl.cnf</path>

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              = md5
preserve                = no
policy                  = policy_match

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

[req] 
default_bits            = 1024
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     = Paca
localityName                    = Locality Name (eg, city)
localityName_default            = Cavaillon
0.organizationName              = Organization Name (eg, company)
0.organizationName_default      = B2PWeb
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

Although it is not required, it is recommended that you edit the default values in the [req_distinguished_name] section of the configuration to match the information for your own server. This will allow you to accept most of the default values when generating certificates later. The other sections can be left unedited.

Generate CA

The CA is the Certificate Authority. It's the key/cert pair used to sign all the other certificate requests. When configuring the various koji components, both the client CA and the server CA will be a copy of the CA generated here. The CA certificate will be placed in the /etc/pki/koji directory and the certificates for the other components will be placed in the /etc/pki/koji/certs directory. The index.txt file which is created is a database of the certificates generated and can be used to view the information for any of the certificates simply by viewing the contents of index.txt.

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

The last command above will ask you to confirm a number of items about the certificate you are generating. Presumably you already edited the defaults for the country, state/province, locale, and organization in the ssl.cnf file and you only needed to hit enter. It's the organizational unit and the common name that we will be changing in the various certs we create. For the CA itself, these fields don't have a hard requirement. One suggestion for this certificate is to use the FQDN of the server.

Generate the koji component certificates and the admin certificate

Each koji component needs its own certificate to identify it. Two of the certificates (kojihub and kojiweb) are used as server side certificates that authenticate the server to the client. For this reason, you want the common name on both of those certs to be the fully qualified domain name of the web server they are running on so that clients don't complain about the common name and the server not being the same. You can set the OU for these two certificates to be kojihub and kojiweb for identification purposes.

For the other certificates (kojira, kojid, the initial admin account, and all user certificates), the cert is used to authenticate the client to the server. The common name for these certs should be set to the login name for that specific component. For example the common name for the kojira cert should be set to kojira so that it matches the username. The reason for this is that the common name of the cert will be matched to the corresponding user name in the koji database. If there is not a username in the database which matches the CN of the cert the client will not be authenticated and access will be denied.

When you later use koji add-host to add a build machine into the koji database, it creates a user account for that host even though the user account doesn't appear in the user list. The user account created must match the common name of the certificate which that component uses to authenticate with the server. When creating the kojiweb certificate, you'll want to remember exactly what values you enter for each field as you'll have to regurgitate those into the /etc/koji-hub/hub.conf file as the ProxyDNs entry.

When you need to create multiple certificates it may be convenient to create a loop or a script like the on listed below and run the script to create the certificates. You can simply adjust the number of kojibuilders and the name of the admin account as you see fit. For much of this guide, the admin account is called "kojiadmin".

#!/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 2048

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

Generate a PKCS12 user certificate (for web browser) This is only required for user certificates.

#!/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

When generating certs for a user, the user will need the ${user}.pem, the ${caname}_ca_cert.crt, and the ${user}_browser_cert.p12 files which were generated above. The ${user}.pem file would normally be installed as ~/.fedora.cert, the ${caname}_ca_cert.crt file would be installed as both ~/.fedora-upload-ca.cert and ~/.fedora-server-ca.cert, and the user would import the ${user}_brower_cert.p12 into their web browser as a personal certificate.

Nom du certificat	CN (commonName)	OU (organizationalUnitName)
kojihub	didier.b2pweb.com (FQDN)	kojihub
kojiweb	didier.b2pweb.com (FQDN)	kojiweb
kojira	kojira	SRS
didier ( utilisateur koji admin )	didier@didier.b2pweb.com ( ici c'est le user et non le nom d'hôte de la machine et le domaine servira pour l'envoi d'email )	SRS
gilles ( utilisateur koji )	gilles@didier.b2pweb.com ( le domaine servira pour l'envoi d'email )	SRS
bastien ( utilisateur koji )	bastien@didier.b2pweb.com ( le domaine servira pour l'envoi d'email )	SRS
builder-didier	builder-didier.b2pweb.com	kojibuilder
builder-gilles	builder-gilles.b2pweb.com	kojibuilder

Ajout des utilisateurs Koji aux alias du serveur de mail local

Edition du fichier <path>/etc/aliases</path> for appairer les utilisateurs Koji aux véritables adresses mail.

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

# Person who should get root's mail
root:           dfabert@b2pweb.com

didier:         dfabert@b2pweb.com
bastien:        bhermitte@b2pweb.com
gilles:         ggaudin@b2pweb.com

Copy certificates into ~/.koji for kojiadmin

You're going to want to be able to send admin commands to the kojihub. In order to do so, you'll need to use the newly created certificates to authenticate with the hub. Create the kojiadmin user then copy the certificates for the koji CA and the kojiadmin user to ~/.koji:

kojiadmin@localhost$ mkdir ~/.koji
kojiadmin@localhost$ cp /etc/pki/koji/kojiadmin.pem ~/.koji/client.crt
kojiadmin@localhost$ cp /etc/pki/koji/koji_ca_cert.crt ~/.koji/clientca.crt
kojiadmin@localhost$ cp /etc/pki/koji/koji_ca_cert.crt ~/.koji/serverca.crt

Note: See /etc/koji.conf for the current system wide koji client configuration. Copy /etc/koji.conf to ~/.koji/config if you wish to change the config on a per user basis.

PostgreSQL Server

Once the authentication scheme has been setup your will need to install and configure a PostgreSQL server and prime the database which will be used to hold the koji users.

Configuration Files:

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

Install PostgreSQL:

root@localhost$ yum install postgresql-server

Initialize PostgreSQL DB:

The following commands will initialize PostgreSQL and will start the database service

root@localhost$ service postgresql initdb
root@localhost$ service postgresql start

initdb on Fedora 16
The PostgreSQL init script has been converted to systemd in Fedora 16, so the initdb function has been removed. To run initdb directly:

su - postgres -c "PGDATA=/var/lib/pgsql/data initdb"

Setup User Accounts:

The following commands will setup the koji account and assign it a password

root@localhost$ useradd koji
root@localhost$ passwd -d koji

Setup PostgreSQL and populate schema:

The following commands will create the koji user within PostgreSQL and will then create the koji database using the schema within the /usr/share/doc/koji*/docs/schema.sql directory

root@localhost$ su - postgres
postgres@localhost$ 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
postgres@localhost$ createdb -O koji koji
postgres@localhost$ logout
root@localhost$ su - koji
koji@localhost$ psql koji koji < /usr/share/doc/koji*/docs/schema.sql
koji@localhost$ exit

NOTE: When issuing the command to import the psql schema into the new database it is important to ensure that the directory path /usr/share/doc/koji*/docs/schema.sql remains intact and is not resolved to a specific version of koji. In test it was discovered that when the path is resolved to a specific version of koji then not all of the tables were created correctly

Authorize Koji-web and Koji-hub resources: In this example, Koji-web and Koji-hub are running on localhost.

/var/lib/pgsql/data/pg_hba.conf: These settings need to be valid and inline with other services configurations. Please note, the first matching auth line is used so this line must be above any other potential matches. Add:

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

You can also use UNIX socket access. The DBHost variable must be unset to use this method. Add:

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

Make auth changes live:

The following commands let postgreSQL know that changes have been made and forces it to reload its configuration so that changes become active

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

Bootstrapping the initial koji admin user into the PostgreSQL database:

The initial admin user must be manually added to the user database using sql commands. Once they are added and given admin privilege, they may add additional users and change privileges of those users via the koji command line tool's administrative commands. However, if you choose to use the simple user/pass method of authentication, then any password setting/changing must be done manually via sql commands as there is no password manipulation support exposed through the koji tools.

SSL Certificate authentication: there is no need for either a password or a Kerberos principal, so this will suffice:

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

Give yourself admin permissions

The following command will give the user admin permissions. In order to do this you will need to know the ID of the user.

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

Note: If you do not know the ID of the admin user, you can get the ID by running the query:

koji=> select * from users;

You can't actually log in and perform any actions until kojihub is up and running in your web server. In order to get to that point you still need to complete the authentication setup and the kojihub configuration. If you wish to access koji via a web browser, you will also need to get kojiweb up and running.

Koji Hub

Koji-hub is the center of all Koji operations. It is an XML-RPC server running under mod_python in Apache. koji-hub is passive in that it only receives XML-RPC calls and relies upon the build daemons and other components to initiate communication. Koji-hub is the only component that has direct access to the database and is one of the two components that have write access to the file system.

Configuration Files:

• /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

Install koji-hub:

root@localhost$ yum install koji-hub httpd mod_ssl mod_python

Required Configuration

/etc/httpd/conf/httpd.conf:

The apache web server has two places that it sets maximum requests a server will handle before the server restarts. The xmlrpc interface in kojihub is a python application, and mod_python can sometimes grow outrageously large when it doesn't reap memory often enough. As a result, it is strongly recommended that you set both instances of MaxRequestsPerChild in httpd.conf to something reasonable in order to prevent the server from becoming overloaded and crashing (at 100 the httpd processes will grow to about 75MB resident set size before respawning).

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

You'll need to make /mnt/koji/packages web-accessible, either here on the hub, or on koji-web, or on another web server altogether. This URL will later go into the builders' pkgurl config option.

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

/etc/koji-hub/hub.conf:

This file contains the configuration information for the hub. You will need to edit this configuration to point Koji Hub to the database you are using and to setup Koji Hub to utilize the authentication scheme you selected in the beginning.

DBName = koji
DBUser = koji
DBHost = db.example.com
KojiDir = /mnt/koji
LoginCreatesUser = On
KojiWebURL = http://kojiweb.example.com/koji

/etc/koji-hub/hub.conf: If using SSL auth, these settings need to be valid and inline with other services configurations for kojiweb to allow logins. ProxyDNs should be set to the DN of the kojiweb certificate.

DNUsernameComponent = CN
ProxyDNs = /C=US/ST=Massachusetts/O=Example Org/OU=Example User/CN=example/emailAddress=example@example.com

/etc/httpd/conf.d/kojihub.conf: If using SSL auth, uncomment these lines for kojiweb to allow logins."

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

/etc/httpd/conf.d/ssl.conf: If using SSL you will also need to add the needed SSL options for apache. These options should point to where the certificates are located on the hub.

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

SELinux Configuration

If running in Enforcing mode, you will need to allow apache to connect to the postgreSQL server. Even if you are not running currently running in Enforcing mode it is still recommended to run the following command to ensure that there are no future issues with SELinux if Enforcing mode is later enabled.

root@localhost$ setsebool -P httpd_can_network_connect_db 1

Koji filesystem skeleton

Above in the kojihub.conf file we set KojiDir to /mnt/koji. For certain reasons, if you change this, you should make a symlink from /mnt/koji to the new location (note: this is a bug and should be fixed eventually). However, before other parts of koji will operate properly, we need to create a skeleton filesystem structure for koji as well as make the file area owned by apache so that the xmlrpc interface can write to it as needed.

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

At this point, you can now restart apache and you should have at least minimal operation. The admin user should be able to connect via the command line client, add new users, etc. It's possible at this time to undertake initial administrative steps such as adding users and hosts to the koji database.

Ensure that your client is configured to work with your server. The system-wide koji client configuration file is /etc/koji.conf, and the user-specific one is in ~/.koji/config. You may also use the "-c" option when using the Koji client to specify an alternative configuration file. The following command will test your login to the hub:

koji call getLoggedInUser

If you are using SSL for authentication, you will need to edit the Koji client configuration to tell it which URLs to use for the various Koji components and where their SSL certificates can be found.

[koji]

;url of XMLRPC server
server = http://hongkong.proximity.on.ca/kojihub

;url of web interface
weburl = http://hongkong.proximity.on.ca/koji

;url of package download site
pkgurl = http://hongkong.proximity.on.ca/packages

;path to the koji top directory
topdir = /mnt/koji

;configuration for SSL athentication
;client certificate
cert = ~/.koji/client.crt

;certificate of the CA that issued the client certificate
ca = ~/.koji/clientca.crt

;certificate of the CA that issued the HTTP server certificate
serverca = ~/.koji/serverca.crt

It is important to note that the kojira component needs repo privileges, but if you just let the account get auto created the first time you run kojira, it won't have that privilege, so you should pre-create the account and grant it the repo privilege now.

kojiadmin@localhost$ koji add-user kojira
kojiadmin@localhost$ koji grant-permission repo kojira

For similar technical reasons, you need to add-host each build host prior to starting kojid on that host the first time and could also do that now.

kojiadmin@localhost$ koji add-host kojibuilder1 x86_64 i386
kojiadmin@localhost$ koji add-host kojibuilder2 ppc ppc64
kojiadmin@localhost$ koji add-host kojibuilder3 ia64

Koji Web - Interface for the Masses

Koji-web is a set of scripts that run in mod_python and use the Cheetah templating engine to provide an web interface to Koji. koji-web exposes a lot of information and also provides a means for certain operations, such as cancelling builds.

Configuration Files:

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

Install Koji-Web:

root@localhost$ yum install koji-web mod_ssl

Required Configuration

/etc/httpd/conf.d/kojiweb.conf: You will need to edit the kojiweb configuration file to tell kojiweb which URLs it should use to access the hub, the koji packages and its own web interface. You will also need to tell kojiweb where it can find the SSL certificates for each of these components. If you are using SSL authentication, the "PythonOption WebCert" line below must contain both the public and private key. You will also want to change the last line in the example below to a unique password.

PythonOption KojiHubURL http://hub.example.com/kojihub
PythonOption KojiWebURL http://www.example.com/koji
PythonOption KojiPackagesURL http://server.example.com/mnt/koji/packages


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

PythonOption LoginTimeout 72
PythonOption Secret CHANGE_ME

Optional Configuration

You will also need to edit the /etc/httpd/conf.d/kojiweb.conf to configure it for the authentication scheme you have selected at the beginning of the setup.

/etc/httpd/conf.d/kojiweb.conf: If using SSL, these settings need to be valid and inline with other services configurations.

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

/etc/httpd/conf.d/ssl.conf: If you are using SSL you will need to add the needed SSL options for apache.

SSLVerifyClient require
SSLVerifyDepth  10

Web interface now operational

At this point you should be able to point your web browser at the kojiweb URL and be presented with the koji interface. Many operations should work in read only mode at this point, and any configured users should be able to log in.

Koji Daemon - Builder

Kojid is the build daemon that runs on each of the build machines. Its primary responsibility is polling for incoming build requests and handling them accordingly. Koji also has support for tasks other than building such as creating livecd images or raw disk images, and kojid is responsible for handling these tasks as well. kojid uses mock for creating pristine build environments and creates a fresh one for every build, ensuring that artifacts of build processes cannot contaminate each other. kojid is written in Python and communicates with koji-hub via XML-RPC.

Configuration Files:

• /etc/kojid/kojid.conf - Koji Daemon Configuration
• /etc/sysconfig/kojid - Koji Daemon Switches

Install kojid:

root@localhost$ yum install koji-builder

Required Configuration

/etc/kojid/kojid.conf: The configuration file for each koji builder must be edited so that the line below points to the URL for the koji hub. The user tag must also be edited to point to the username used to add the koji builder.

; 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

This item may be changed, but may not be the same as KojiDir on the kojihub.conf file (although it can be something under KojiDir, just not the same as KojiDir)

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

Optional Configuration (SSL certificates)

/etc/kojid/kojid.conf: If you are using SSL, these settings need to be edited to point to the certificates you generated at the beginning of the setup process.

;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

It is important to note that if your builders are hosted on seperate machines from koji hub and koji web, you will need to scp the certificates mentioned in the above configuration file from the /etc/kojid/ directory on koji hub to the /etc/koji/ directory on the local machine so that the builder can be authenticated.

Add the host entry for the koji builder to the database

You will now need to add the koji builder to the database so that they can be utilized by kojij hub. Make sure you do this before you start kojid for the first time, or you'll need to manually remove entries from the sessions and users table before it can be run successfully.

kojiadmin@localhost$ koji add-host kojibuilder1.example.com i386 x86_64

The first argument used after the add-host command should the username of the builder. The second argument is used to specify the architecture which the builder uses.

Add the host to the createrepo channel

Channels are a way to control which builders process which tasks. By default hosts are added to the default channel. At least some build hosts also needs to be added to the createrepo channel so there will be someone to process repo creation tasks initiated by kojira.

kojiadmin@localhost$ koji add-host-to-channel kojibuilder1.example.com createrepo

A note on capacity

The default capacity of a host added to the host database is 2. This means that once the load average on that machine exceeds 2, kojid will not accept any additional tasks. This is separate from the maxjobs item in the configuration file. Before kojid will accept a job, it must pass both the test to ensure the load average is below capacity and that the current number of jobs it is already processing is less than maxjobs. However, in today's modern age of quad core and higher CPUs, a load average of 2 is generally insufficient to fully utilize hardware. As there is not an option to set the capacity of the host via the command line tools, it must be done manually in psql.

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

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

Start Kojid

Once the builder has been added to the database you must start kojira

root@localhost$ /sbin/service kojid start

Check /var/log/kojid.log to verify that kojid has started successfully. If the log does not show any errors then the koji builder should be up and ready. You can check this by pointing your web browser to the web interface and clicking on the hosts tab. This will show you a list of builders in the database and the status of each builder.

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

Fichiers de Configuration:

• /etc/kojira/kojira.conf - Kojira Daemon Configuration
• /etc/sysconfig/kojira - Kojira Daemon Switches

Installation de kojira

yum install koji-utils

Configuration générale

/etc/kojira/kojira.conf: server a besoin de pointer sur le koji-hub.

; The URL for the xmlrpc server
server=http://didier.b2pweb.com/kojihub

Note importante

• Kojira a besoin d'un accès en lecture/écriture sur <path>/mnt/koji</path>.
• 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 <path>/mnt/koji</path>.

Configuration de l'authentification SSL

/etc/kojira/kojira.conf: If using SSL, these settings need to be valid.

;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

/etc/sysconfig/kojira: 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.

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 <path>/var/log/kojira/kojira.log</path> que kojira a bien démarré.