Monthly Archives: April 2015

Installation d’un système Koji

Tuturial de mise en place d’un système Koji complet avec authentification SSL. L’authentification Kerberos fera l’objet d’une mise à jour, et la configuration initiale, ainsi que Sigul (signature de RPM) fera l’objet d’autres posts.

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

IconTextFile16.png /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
IconNote48.png
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

IconTextFile16.png /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

IconTextFile16.png /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
Nom du certificat CN (commonName) OU (organizationalUnitName)
kojihub koji.didier-linux.eu (FQDN) kojihub
kojiweb koji.didier-linux.eu (FQDN) kojiweb
kojira kojira Admin
didier ( utilisateur koji admin ) didier ( ici c'est le user et non le nom d'hôte de la machine ) Admin
kojibuilder.didier-linux.eu kojibuilder.didier-linux.eu builder

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
IconNote48.png
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.
Principal Utilisation
host/kojihub@DIDIER-LINUX.EU Utiliser par koji-hub pour communiquer avec le client koji
HTTP/kojiweb@DIDIER-LINUX.EU Utiliser par koji-web pour négotier une authentifiaction avec le navigateur web. C'est le principal pour l'authentification Apache mod_auth_kerb.
koji/kojiweb@DIDIER-LINUX.EU Utiliser par koji-web pour communiquer avec koji-hub. C'est le principal qui va authentifier koji-web sur Kerberos comme "koji/kojiweb@EXAMPLE.COM". Koji-web relayera aussi le nom d'utilisateur (authentification Apache) vers koji-hub (koji-hub config option ProxyPrincipals).
koji/kojira@DIDIER-LINUX.EU Utiliser par kojira pour communiquer avec koji-hub
compile/builder1@DIDIER-LINUX.EU Utiliser par le constructeur koji pour communiquer avec koji-hub

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.

IconTextFile16.png /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
IconIdea48.png
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.

IconBug48.png
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

IconTextFile16.png /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.

IconTextFile16.png /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>);
IconIdea48.png
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.

IconBug48.png
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.

IconTextFile16.png /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.

IconTextFile16.png /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>
IconTextFile16.png /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>
IconTextFile16.png /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>
IconTextFile16.png /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
IconTextFile16.png /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.

IconNote48.png
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
IconImportant48.png
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.

IconTextFile16.png /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.

IconTextFile16.png /etc/httpd/conf.d/kojiweb.conf
<Location /koji/login>
SSLOptions +StdEnvVars
</Location>
IconTextFile16.png /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.

IconTextFile16.png /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)

IconTextFile16.png /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.

IconTextFile16.png /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
IconImportant48.png
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.

IconImportant48.png
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.

IconTextFile16.png /etc/kojira/kojira.conf
; The URL for the xmlrpc server
server=http://koji.didier-linux.eu/kojihub
IconImportant48.png
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

IconTextFile16.png /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.

IconTextFile16.png /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
source: https://wiki.tartarefr.eu/index.php/Koji/Installation

Générer de l’entropie

Sur les stations de travail, l’entropie est générée à partir du bruit de fond du matériel: clavier, souris, disque dur, carte son. Mais sur des systèmes virtuels, la génération d’entropie peut être beaucoup plus longue avec les interface virtuelles. Pour générer plus rapidement de l’entropie, il suffut d’installer le paquet haveged depuis le dépôt EPEL.

yum install haveged
Le lancement se fait comme d’habitude avec service ou systemctl.
On peut mesurer l’entropie disponible avec la commande:
cat /proc/sys/kernel/random/entropy_avail

Installation d’un serveur Kerberos

Tuturial de mise en place d’un serveur Kerberos et de configuration des clients: PAM, SSH et authentification Apache. La partie introduction et fonctionnement est largement inspiré de Wikipedia.

Introduction

Le protocole Kerberos est issu du projet « Athena » du MIT, mené par Miller et Neuman. La version 5 du protocole Kerberos a été normalisée par l'IETF dans les RFC 1510 (septembre 1993) et 1964 (juin 1996). Le nom « Kerberos » provient provient de la mythologie grecque et correspond au nom du chien (en français « Cerbère ») protégeant l'accès aux portes d’Hadès.

L'objet de Kerberos est la mise en place de serveurs d'authentification (AS pour Authentication Server), permettant d'identifier des utilisateurs distants, et des serveurs de délivrement de tickets de service (TGS, pour Ticket Granting System), permettant de les autoriser à accéder à des services réseau. Les clients peuvent aussi bien être des utilisateurs que des machines. La plupart du temps, les deux types de services sont regroupés sur un même serveur, appelé Centre de Distribution des Clés (ou KDC, pour Key Distribution Center).

Fonctionnement

Le protocole Kerberos repose sur un système de cryptographie à base de clés secrètes (clés symétriques ou clés privées), avec l'algorithme DES. Kerberos partage avec chaque client du réseau une clé secrète faisant office de preuve d'identité.

Le principe de fonctionnement de Kerberos repose sur la notion de « tickets »  :

KerberosSimple.svg

  1. Afin d'obtenir l'autorisation d'accès à un service, un utilisateur distant doit envoyer son identifiant au serveur d'authentification.
  2. Le serveur d'authentification vérifie que l'identifiant existe et envoie un ticket initial au client distant, chiffré avec la clé associée au client. Le ticket initial contient :
    • un clé de session, faisant office de mot de passe temporaire pour chiffrer les communications suivantes ;
    • un ticket d'accès au service de délivrement de ticket.
  3. Le client distant déchiffre le ticket initial avec sa clé et obtient ainsi un ticket et une clé de session.
  4. Grâce à son ticket et sa clé de session, le client distant peut envoyer une requête chiffrée, afin de demander l'accès à un service.

Par ailleurs, Kerberos propose un système d'authentification mutuelle permettant au client et au serveur de s'identifier réciproquement.

L'authentification proposée par le serveur Kerberos a une durée limitée dans le temps, ce qui permet d'éviter à un pirate de continuer d'avoir accès aux ressources : on parle ainsi d'anti re-jeu.

  • Les comptes sont appelé principal pour kerberos. Ce peut être un utilisateur (ex: didier@TARTAREFR.EU), un hôte (ex: kerberos.tartarefr.eu@TARTAREFR.EU), un service (ex: http/kerberos.tartarefr.eu@TARTAREFR.EU), etc...
  • Un keytab (trousseau de clé) est un fichier où est encodé avec plusieurs algorithmes un ou plusieurs mots de passe.

Pré-requis

  • Les clients doivent avoir un nom d'hôte pleinement qualifié et resolvable via un serveur DNS ou via le fichier /etc/hosts
  • Les heures doivent être synchronisées entre les serveurs (via chronyd ou ntpd)

Installation du serveur

Installation

yum install krb5-server krb5-workstation 

Configuration

IconIdea48.png
Rappel des conventions d'écriture
  • le nom de domaine est en minuscule (didier.tartarefr.eu)
  • le nom du royaume est en majuscule (DIDIER.TARTAREFR.EU)

Remplacement du domaine example.com par le notre dans les fichiers de configuration.

sed -i -e 's/EXAMPLE.COM/DIDIER.TARTAREFR.EU/g' -e 's/example.com/didier.tartarefr.eu/g' /etc/krb5.conf
sed -i -e 's/EXAMPLE.COM/DIDIER.TARTAREFR.EU/g' /var/kerberos/krb5kdc/kdc.conf
sed -i -e 's/EXAMPLE.COM/DIDIER.TARTAREFR.EU/g' /var/kerberos/krb5kdc/kadm5.acl
IconTextFile16.png /etc/krb5.conf
[logging]
 default = FILE:/var/log/krb5libs.log
 kdc = FILE:/var/log/krb5kdc.log
 admin_server = FILE:/var/log/kadmind.log

[libdefaults]
 dns_lookup_realm = false
 ticket_lifetime = 24h
 renew_lifetime = 7d
 forwardable = true
 rdns = false
 default_realm = DIDIER.TARTAREFR.EU
 default_ccache_name = KEYRING:persistent:%{uid}

[realms]
 DIDIER.TARTAREFR.EU = {
 kdc = kerberos.didier.tartarefr.eu
 admin_server = kerberos.didier.tartarefr.eu
}

[domain_realm]
 .didier.tartarefr.eu = DIDIER.TARTAREFR.EU
 didier.tartarefr.eu = DIDIER.TARTAREFR.EU
IconTextFile16.png /var/kerberos/krb5kdc/kdc.conf
[kdcdefaults]
 kdc_ports = 88
 kdc_tcp_ports = 88

[realms]
 DIDIER.TARTAREFR.EU = {
  master_key_type = aes256-cts
  #database_name = /var/kerberos/krb5kdc/principal
  acl_file = /var/kerberos/krb5kdc/kadm5.acl
  dict_file = /usr/share/dict/words
  admin_keytab = /var/kerberos/krb5kdc/kadm5.keytab
  supported_enctypes = aes256-cts:normal aes128-cts:normal des3-hmac-sha1:normal arcfour-hmac:normal camellia256-cts:normal camellia128-cts:normal des-hmac-sha1:normal des-cbc-md5:normal des-cbc-crc:normal
  #default_principal_flags = +preauth
 }
IconTextFile16.png /var/kerberos/krb5kdc/kadm5.acl
*/admin@DIDIER.TARTAREFR.EU       *

Les droits d'administration sont fixés dans le fichier /var/kerberos/krb5kdc/kadm5.acl et sont sous la forme

principal  permissions  [target_principal  [restrictions] ]

exemple

*/admin@DIDIER.TARTAREFR.EU *
admin                         *

Chaque champs peut avoir un joker ( astérisque *)

  • principal: Il spécifie tout ou partie d'un nom du compte kerberos
  • permissions: voir le tableau Permissions d'administration
  • target_principal: paramètre optionnel. Il spécifie tout ou partie de domaine Kerberos
  • restrictions: paramètre optionnel. C'est une chaine de caractère représentant les options. Les options possibles sont:
    • {+|-}flagname: l'option est forcée à la valeur indiquée. Les options admissibles ici sont les mêmes que les permissions préfixés du signe + ou - (voir le tableau Permissions d'administration)
    • clearpolicy: la politique est forcé avec un paramètre vide (pas de politique)
    • policy pol: la politique est forcé au paramètre pol
    • -{expire, pwexpire, maxlife, maxrenewlife} time: l'option est forcée à la valeur indiquée.
Permissions d'administration
Permission Commentaire
a [Dis]allows the addition of principals or policies
c [Dis]allows the changing of passwords for principals
d [Dis]allows the deletion of principals or policies
i [Dis]allows inquiries about principals or policies
l [Dis]allows the listing of principals or policies
m [Dis]allows the modification of principals or policies
p [Dis]allows the propagation of the principal database (used in Incremental database propagation)
s [Dis]allows the explicit setting of the key for a principal
x Short for admcil. All privileges
* Same as x.

Initialisation

On créer la base de données. Cette étape peut être très longue s'il n'y a pas assez d'entropie. Pour s'assurer qu'il y en ai assez, on peut lancer la commande @find / 1>/dev/null 2>&1@ dans un autre shell afin d'en générer. A la fin, la commande demande la futur mot de passe de la base (xk0un7mysx)

kdb5_util create -s

On ouvre le firewall pour kerberos (port 88)

firewall-cmd --permanent --add-service=kerberos
firewall-cmd --reload

On démarre les services

systemctl start krb5kdc
systemctl start kadmin
systemctl enable kadmin
systemctl enable krb5kdc

Tests

On va lister les principals déjà disponibles

kadmin.local
Authenticating as principal root/admin@DIDIER.TARTAREFR.EU with password.
kadmin.local: listprincs
K/M@DIDIER.TARTAREFR.EU
kadmin/admin@DIDIER.TARTAREFR.EU
kadmin/changepw@DIDIER.TARTAREFR.EU
kadmin/kerberos.didier.tartarefr.eu@DIDIER.TARTAREFR.EU
krbtgt/DIDIER.TARTAREFR.EU@DIDIER.TARTAREFR.EU
kadmin.local:  exit

Puis ajouter un principal pour l'utilisateur didier

kadmin.local
kadmin.local: ank didier
WARNING: no policy specified for didier@DIDIER.TARTAREFR.EU; defaulting to no policy
Enter password for principal "didier@DIDIER.TARTAREFR.EU": 
Re-enter password for principal "didier@DIDIER.TARTAREFR.EU": 
Principal "didier@DIDIER.TARTAREFR.EU" created.
kadmin.local:  exit

On vérifie que l'utilisateur didier peut acquérir un jeton kerberos. Si la commande ne renvoie rien, c'est que ça s'est bien passé.

kinit didier

On liste les jetons distribués

klist
Ticket cache: KEYRING:persistent:0:0
Default principal: didier@DIDIER.TARTAREFR.EU

Valid starting       Expires              Service principal
25/02/2015 10:47:09  26/02/2015 10:47:06  krbtgt/DIDIER.TARTAREFR.EU@DIDIER.TARTAREFR.EU
        renew until 25/02/2015 10:47:09

On vérifie que l'utilisateur didier ne peut que changer son mot de passe (politique par défaut)

kadmin -p didier
Authenticating as principal didier with password.
Password for didier@DIDIER.TARTAREFR.EU: 
kadmin:  listprincs
get_principals: Operation requires ``list'' privilege while retrieving list.
kadmin:  cpw didier
Enter password for principal "didier@DIDIER.TARTAREFR.EU": 
Re-enter password for principal "didier@DIDIER.TARTAREFR.EU": 
Password for "didier@DIDIER.TARTAREFR.EU" changed.
kadmin:  exit

Pour chaque hôte devant être géré par Kerberos

  • on ajoute un principal avec un mot de passe aléatoire
  • on l'exporte dans un keytab local (celui-ci sera copié dans un deuxième temps sur l'hôte concerné)
kadmin.local
Authenticating as principal didier/admin@DIDIER.TARTAREFR.EU with password.

kadmin.local:  ank -randkey host/test.didier.tartarefr.eu@DIDIER.TARTAREFR.EU 
WARNING: no policy specified for host/test.didier.tartarefr.eu@DIDIER.TARTAREFR.EU; defaulting to no policy
Principal "host/test.didier.tartarefr.eu@DIDIER.TARTAREFR.EU" created.

kadmin.local:  ktadd -k /tmp/krb5.keytab host/test.didier.tartarefr.eu   
Entry for principal host/test.didier.tartarefr.eu with kvno 3, encryption type aes256-cts-hmac-sha1-96 added to keytab FILE:/tmp/krb5.keytab.
Entry for principal host/test.didier.tartarefr.eu with kvno 3, encryption type aes128-cts-hmac-sha1-96 added to keytab FILE:/tmp/krb5.keytab.
Entry for principal host/test.didier.tartarefr.eu with kvno 3, encryption type des3-cbc-sha1 added to keytab FILE:/tmp/krb5.keytab.
Entry for principal host/test.didier.tartarefr.eu with kvno 3, encryption type arcfour-hmac added to keytab FILE:/tmp/krb5.keytab.
Entry for principal host/test.didier.tartarefr.eu with kvno 3, encryption type camellia256-cts-cmac added to keytab FILE:/tmp/krb5.keytab.
Entry for principal host/test.didier.tartarefr.eu with kvno 3, encryption type camellia128-cts-cmac added to keytab FILE:/tmp/krb5.keytab.
Entry for principal host/test.didier.tartarefr.eu with kvno 3, encryption type des-hmac-sha1 added to keytab FILE:/tmp/krb5.keytab.
Entry for principal host/test.didier.tartarefr.eu with kvno 3, encryption type des-cbc-md5 added to keytab FILE:/tmp/krb5.keytab.

kadmin.local:  exit

On copie ensuite ce keytab local sur le client kerberos (serveur SSH, serveur web, etc...)

Installation sur les clients

On installe les outils kerberos

yum install krb5-workstation

On édite (ou on copie le fichier depuis le serveur) /etc/krb5.conf

On ajoute un utilisateur système didier

useradd -s /bin/bash -m didier
passwd didier

On vérifie que l'utilisateur didier peut acquérir un jeton kerberos depuis ce client.

kinit didier

Connexion locale (PAM)

Installation du PAM (Pluggable Authentication Modules) Kerberos et activation.

yum install pam_krb5
authconfig --enablekrb5 --update

Client SSH

Comme SSH utilise PAM par défaut, le paquet pam_krb5 doit être installé et activé.

IconIdea48.png
Utilisateurs pouvant se connecter au serveur
Seul les utilisateurs ayant un principal Kerberos et ayant un compte utilisateur sur le serveur SSH peuvent se connecter en SSH avec la méthode gssapi-with-mic.

Il est possible de se connecter en GSSAPI depuis un poste Windows

Sur le serveur Kerberos

On créé un principal qui aura accès à tous les serveurs. Il n'y a pas de nom mieux choisi que root.

  1. On créé le principal pour root
    kadmin.local -q "addprinc -randkey root"
  2. On s'assure que le fichier d'export n'existe pas encore
    rm -f /tmp/root.keytab
  3. On exporte ce principal
    kadmin.local -q "ktadd -k /tmp/root.keytab root"
  4. On copie dans /root du client l'export du principal root.

Pour chaque serveur SSH devant être géré par kerberos

  1. On créé un principal host/<FQDN>
    kadmin.local -q "addprinc -randkey host/server.tartarefr.eu"
  2. On s'assure que le fichier d'export n'existe pas encore
    rm -f /tmp/krb5.keytab
  3. On exporte ce principal (et uniquement lui pour des raisons de sécurité)
    kadmin.local -q "ktadd -k /tmp/krb5.keytab host/server.tartarefr.eu"
  4. On copie ce principal sur le serveur SSH
    scp /tmp/krb5.keytab server.tartarefr.eu:/etc/krb5.keytab
  5. On copie le fichier de configuration Kerberos sur le serveur SSH
    scp /etc/krb5.conf server.tartarefr.eu:/etc/krb5.conf

Sur le serveur SSH

  • On lui spécifie explicitement le propriétaire/groupe de l'export du principal
    chown root:root /etc/krb5.keytab
  • On lui spécifie les droits associés
    chmod 600 /etc/krb5.keytab

sur le client SSH

  • On copie dans /root l'export du principal root.

Test de connexion

Avant de le fixer dans le fichier /etc/ssh/ssh_config, on teste

  1. On acquiert un jeton kerberos
    kinit -k -t /root/root.keytab root
  2. On se connecte par ssh en forçant l'option GSSAPIAuthentication
    ssh root@server.tartarefr.eu -o "GSSAPIAuthentication yes" -o "PasswordAuthentication no"
  3. Si la connexion est un succès (sans mot de passe), on vérifie que le fichier /etc/ssh/ssh_config contient bien
    • GSSAPIAuthentication yes
    • GSSAPIDelegateCredentials yes

Debug

  1. Vérification de la synchronisation de l'heure
    date && hwclock
  2. Vérification des paramètres du fichier /etc/ssh/sshd_config
    • GSSAPIAuthentication yes
    • GSSAPIDelegateCredentials yes
  3. Vérification DNS
    • S'assurer que la résolution fonctionne correctement dans les deux sens
      getent hosts $(hostname) | awk '{print $1; exit}' | xargs getent hosts | awk '{print $2}'
    • Vérification du fichier /etc/hosts sur le serveur SSH.
      Il ne doit en aucun cas résoudre sur localhost.
      Le premier nom d'hôte qui suit l'adresse IP (LAN/WAN) doit être le nom d'hôte pleinement qualifié, suivi du nom d'hôte simple.
      Les alias (CNAME) ainsi que les noms d'hôte virtuels d'Apache peuvent être placé après.
  4. Vérification des fichiers
    • Vérification du fichier /etc/krb5.conf sur le serveur SSH
      • Le contenu attendu (c.a.d identique à celui du serveur Kerberos)
      • Le bon propriétaire et groupe
        chown root:root /etc/krb5.conf
      • Les bons droits
        chmod 644 /etc/krb5.conf
    • Vérification du fichier /etc/krb5.keytab sur le serveur SSH
      • Le contenu attendu, avec le nom d'hôte pleinement qualifié correspondant (préfixé par host/) et le bon lvno (le numéro d'export qui est incrémenté à chaque fois)
        klist -k /etc/krb5.keytab
      • Le bon propriétaire et groupe
        chown root:root /etc/krb5.conf
      • Les bons droits
        chmod 600 /etc/krb5.conf

Authentification Apache

  • Installation d'apache, du module ssl et du module d'authentification kerberos pour apache
    yum install httpd mod_ssl mod_auth_kerb
  • Ajout d'un principal pour apache (mot de passe aléatoire)
    kadmin.local -q "addprinc -randkey http/didier.tartarefr.eu
  • Export du principal dans un keytab
    kadmin.local -q "ktadd -k /etc/httpd/conf.d/http.keytab http/didier.tartarefr.eu"
  • Modification du propriétaire du keytab car apache doit pouvoir lire ce fichier
    chown apache /etc/httpd/conf.d/http.keytab
  • Vérification de la bonne configuration en obtenant un ticket kerberos manuellement
    kinit -k -t /etc/httpd/conf.d/http.keytab http/didier.tartarefr.eu
  • Destruction du ticket avant de redémarrer le service httpd
    kdestroy

Exemple de configuration apache

<Directory /var/www/html/kerb>
    SSLRequireSSL
    AuthType Kerberos
    AuthName "Kerberos Authentication"
    KrbAuthRealms DIDIER.TARTAREFR.EU
    Krb5Keytab /etc/httpd/conf.d/http.keytab
    KrbServiceName http/didier.tartarefr.eu
    KrbMethodNegotiate Off
    KrbSaveCredentials Off
    KrbVerifyKDC Off
    Require valid-user
</Directory>

Récapitulatif des outils d'utilisation et d'administration

  • kinit: Acquiert un nouveau jeton kerberos pour l'utilisateur passé en argument.
  • kdestroy: Efface le jeton de l'utilisateur actif (le nom passé en argument à kinit)
  • klist: Affiche la liste des jetons pour l'utilisateur actif
  • kadmin: Commande d'administration de kerberos.

Sauvegarde / Restauration

L'utilitaire kdb5_util est utilisé pour la sauvegarde et la restauration: /usr/sbin/kdb5_util

  • Sauvegarde dans le fichier krbsave
    kdb5_util dump krbsave
  • Restauration à partir du fichier krbsave
    kdb5_util load krbsave
    On peut rajouter l'option --update pour mettre à jour uniquement une base existante à partir du la sauvegarde, au lieu de la vider.
source: https://wiki.tartarefr.eu/index.php/Services/Kerberos/Install

Certificats avec hash en md5

 Mon koji, qui est actuellement sur Centos 6, utilise MD5 pour le hash des certificats. Vu que le support md5 a été retiré sur Fedora 21 / CentOS 7, trois solutions s’offrent à moi pour résoudre définitivement le problème:

  • Migration complète du Koji vers CentOS 7 avec refonte des certificats, ce qui impliquerait de  résoudre le problème de sigul, qui ne veut ni générer de clé OpenGPG, ni en importer (sur el7), alors que tout est fonctionnel sur Centos 6.
  • Mise en place de Kerberos (Solution qui supprime cache tout problème SSL)
  • Simple refonte des certificats en SHA256 (SHA1 est encore supporté mais pas pour longtemps).

Mais en attendant, il faut bien faire tourner la boutique et pour se connecter en CLI depuis un client:

export OPENSSL_ENABLE_MD5_VERIFY=1

Mise à jour de mash

Après la mise à jour de koji et de mash (sur centos 6), les dépôts créés automatiquement avec mash ne sont plus lisibles

Error : xz compression not available

Mash compresse maintenant les meta-données des dépots avec xz et non gz ou bz2.

Heureusement les developpeurs de mash ont créé une option permettant de conserver l’ancienne compression. Il suffit de rajouter au fichier mash de définition du dépôt (dans /etc/mash/) le paramètre

compress_type = bz2

SSLCertificateChainFile obsolète

La directive de configuration d’apache SSLCertificateChainFile est maintenant dépréciée (à partir d’apache 2.4.8) pour spécifier un certificat intermédiaire. Le message d’avertissement nous demande de la remplacer par la directive SSLCertificateFile. Le problème est que cette directive est déjà renseignée avec notre certificat. La solution est triviale:

concaténer les deux fichiers

cat ssl.crt sub.class1.server.ca.pem > bundle.pem

faire pointer la directive SSLCertificateFile sur celui-ci.

SSLCertificateFile bundle.pem