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 [1] 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
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 2048
openssl req -config ssl.cnf -new -x509 -days 3650 -key private/koji_ca_cert.key \
-out koji_ca_cert.crt -extensions v3_ca
Generate the koji component certificates and the admin certificate
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.
/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 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
/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 de koji, on générera les certificats web comme ceci:
./generate-certificate.sh kojiweb
| 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 ( ici c'est le user et non le nom d'hôte de la machine ) | SRS |
| gilles ( utilisateur koji ) | gilles | SRS |
| bastien ( utilisateur koji ) | bastien | SRS |
| builder-didier | builder-didier | kojibuilder |
| builder-gilles | builder-gilles | 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
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
Pour modifier des paramètre d'un client sans modifier la configuration générale, il faut copier le fichier <path>/etc/koji.conf</path> dans le home de l'utilisateur <path>~/.koji/config</path> et y effectuer les modifications dans celui-ci.
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
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.
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
Installation de koji-hub
yum install koji-hub httpd mod_ssl mod_python
Configuration
Fichier /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>
Le répertoire <path>/mnt/koji/packages</path> doit être accessible par HTTP. On ajoute donc un alias.
Fichier /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>
Fichier /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>
Fichier /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>
Fichier /etc/koji-hub/hub.conf
[hub]
DBName = koji
DBUser = koji
DBHost = localhost
KojiDir = /mnt/koji
DNUsernameComponent = CN
ProxyDNs = /C=FR/ST=Paca/O=B2PWeb/OU=kojiweb/CN=didier.b2pweb.com/emailAddress=srs@b2pweb.com|/C=FR/ST=Paca/O=B2PWeb/OU=SRS/CN=didier/emailAddress=srs@b2pweb.com
LoginCreatesUser = On
KojiWebURL = http://didier.b2pweb.com/koji
EmailDomain = didier.b2pweb.com
NotifyOnSuccess = True
Fichier /etc/koji.conf
[koji]
server = http://didier.b2pweb.com/kojihub
weburl = http://didier.b2pweb.com/koji
topurl = http://didier.b2pweb.com/kojifiles
topdir = /mnt/koji
cert = ~/.koji/client.crt
ca = ~/.koji/clientca.crt
serverca = ~/.koji/serverca.crt
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.
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
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.
koji add-user kojira 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.
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 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
- 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é.