Mock est un outil qui permet de construire des RPMs de manière fiable et reproductible. Pour ce faire, il crée en fait un chroot dans lequel il va installer un système de base que l'on peut choisir dans une liste de système epel/red Hat/Mangeia fournit dans /etc/mock.

Pour installer mock, on doit d'abord installer le référentiel EPEL (Extra Packages for Enterprise Linux) sur le système.

Pour installer EPEL sur CentOS, lancer les commandes suivantes:

sudo yum install epel-release 

yum install mock

Tout utilisateur qui exécutera mock doit être ajouté au groupe mock. Vous pouvez le faire en lançant la commande usermod .

Par exemple, l'utilisateur joe peut être ajouté au groupe fictif de la manière suivante:Ajouter l’utilisateur avec lequel on veut construire les RPM au groupe mock, puis le déconnecter et reconnecter pour que les modifications prennent effet.

sudo usermod -a -G mock myusername

La configuration de mock se trouve dans le dossier /etc/mock. En fait dedans il y a trois fichiers qui nous intéressent, à savoir :

• defaults.cfg : déclaration d’options de configuration et des repos à partir desquels mock ira chercher ses fichiers. La syntaxe pour les options de configuration est config_opts['option'] = 'value'. Quant à la syntaxe des repos c’est la même que celle que vous pourriez trouver dans /etc/yum.repos.d
• sites-defaults.cfg : déclaration d’options plus globales. defaults.cfg sert pour définir les options pour une distribution cible donnée, alors que site-defaults.cfg s’applique à tout le monde.
• logging.ini : les options du loggueur, classique quoi.

Par défaut il est déconseillé de modifier les fichiers à cet endroit car ils sont notamment utilisés pour faire des paquets directement pour RedHat. Pour faire des fichiers custom, faites le à un autre endroit différent.

Mock accepte un certain nombre de commandes.

Créer un srpm en utilisant 'rpmbuild -bs'. Ensuite, aller dans le répertoire où le srpm a été créé.

mock -r <configfile> --rebuild package-1.2-3.src.rpm

où <configfile> est le nom d'une configuration de /etc/mock/ (sans l'extension .cfg ). Il n'est pas nécessaire de passer -r si on a défini un fichier de configuration par défaut via un lien symbolique, comme indiqué ci-dessus. –rebuild est l'option par défaut. Donc, ce qui suit fonctionnerait aussi bien

mock package-1.2-3.src.rpm

L'option –verbose est utile pour afficher davantage de sorties à des fins de débogage.

Pour construire un paquet P qui dépend d'un autre paquet Q et que Q ne se trouve pas dans un référentiel, on poeut toujours utiliser mock. Voici une façon de le faire.

Tout d’abord, initialiser le référentiel factice:

mock -r MOCK_CONFIG --init

Un exemple de MOCK_CONFIG est “fedora-14-x86_64”; consulter le répertoire /etc/mock pour connaître les configurations fictives existantes.

Installer les packages nécessaires à la construction du programme (nommé dans BuildRequires) à partir des référentiels yum et/ou des RPM locaux. En pratique, cela peut nécessiter un certain nombre de paquest (pour les différentes dépendances); Pour lister plusieurs paquets sur la même ligne utiliser la commande :

mock -r MOCK_CONFIG --installe PACKAGE_NAME_OR_PATH_TO_RPM

Les versions actuelles de mock devraient permettre de compiler à partir du RPM source. L'option –no-clean est nécessaire car par défaut, le chroot est nettoyé avant la construction.

mock -r MOCK_CONFIG --no-clean /PATH/TO/SRPM

Copier le RPM source dans /tmp (pour contourner les contrôles qui détectent que les paquetages ne sont pas dans le référentiel):

mock -r MOCK_CONFIG --copyin /PATH/TO/SRPM /tmp

Se connecter dans le Shell de l'environnement fictif et effectuer la construction:

mock -r MOCK_CONFIG --shell
CD
rpmbuild --rebuild / tmp / SRPM_NAME

Dans /etc/mock/site-defaults.cfg appliquer les options d'optimation suivantes :

• Désactiver le plugin d'état du paquet: config_opts ['plugin_conf'] ['package_state_enable']=False
• Paralléliser les constructions: config_opts ['macros'] ['% _ smp_mflags'] = "-j17"
• Améliorer les occurrences de ccache entre les versions de paquet:
  config_opts['files']['etc/profile.d/zz-local.sh'] = """
unset CCACHE_HASHDIR
"""
• Compresser ccache: config_opts ['plugin_conf'] ['ccache_opts'] ['compress'] = True
• Utiliser la compression lzo pour le cache racine:
  config_opts ['plugin_conf'] ['root_cache_opts'] ['compress_program'] = "lzop"
config_opts ['plugin_conf'] ['root_cache_opts'] ['extension'] = ".lzo"

Dans les fichiers de configuration par repo

• Compresser (dé) compresser au sein de rpmbuild:

    config_opts ['chroot_setup_cmd'] = 'installer @ buildsys-build /usr/bin/pigz /usr/ bin/lbzip2'
    config_opts ['macros'] ['% __ gzip'] = '/usr/bin/pigz'
    config_opts ['macros'] ['% __ bzip2'] = '/usr/bin/lbzip2' 

Ajouter /usr/bin/scan-build à l'option chroot_setup_cmd des fichiers de configuration par chroot:

config_opts['chroot_setup_cmd'] = 'install @buildsys-build /usr/bin/scan-build'

Configurer un alias de shell pour l'utiliser à la place de plain mock (tout sur une seule ligne):

alias mock-scan-build="mock --define '__scan_build /usr/bin/scan-build' --define '_configure %__scan_build ./configure' --define '__cmake %__scan_build %{_bindir}/cmake' --define '__make %__scan_build %{_bindir}/make' --define '___build_template #!%{___build_shell}\\"$'\n'"alias make=\"%__make\" cmake=\"%__cmake\"\\"$'\n'"%{___build_pre}\\"$'\n'"%{nil}'"

Voir les rapports générés dans le /tmp du chroot

Mock 0.8.x introduit trois types de caches différents: 1) cache racine, 2) cache yum et 3) ccache. Ces caches accélèrent grandement la simulation.

À partir de mock 0.5, mock peut automatiquement mettre en cache la construction standard de chaque environnement dans un fichier tar local (/var/cache/mock/$ CONFIG/root_cache/*). Il décompresse ensuite ce fichier tar pour renseigner la buildroot, plutôt que de télécharger les RPM buildroot à chaque fois. Après avoir décompressé la buildroot à partir du cache racine, Mock effectue une yum update pour s’assurer que la buildroot est à jour avant l’installation supplémentaire de BuildRequires pour une construction de package.

Le cache racine est activé par défaut dans les versions 0.8.x et supérieures. Les caches racine sont automatiquement supprimés et recréés tous les 15 jours pour éviter qu'ils ne deviennent trop périmés.

Il est possible de désactiver le cache racine.

Par défaut, yum stocke les RPM téléchargés dans un répertoire sous /var/cache/yum. La fonctionnalité de cache yum monte le chroot /var/cache/yum dans un répertoire commun situé en dehors de l’environnement chroot (tel que /var/cache/mock/$CONFIG/yum_cache/) où il peut être enregistré et réutilisé par les générations suivantes. . Cela garantit que yum n'a pas besoin de télécharger chaque nouveau RPM sur le réseau pour chaque construction. Cette fonction est activée par défaut.

L'outil ccache est un utilitaire qui encapsule les appels à des compilateurs tels que “gcc” et met en cache la sortie. Lorsqu'il est appelé une seconde fois pour compiler le même programme (avec les mêmes arguments cmdline, gcc-version et fichiers d'en-tête), ccache récupère la version mise en cache plutôt que d'exécuter à nouveau le compilateur.

L'utilisation de SELinux avec des environnements chrootés tels que mock présente un certain nombre de problèmes, tels que la nécessité de répliquer tous les contextes de fichier par défaut avec le préfixe de répertoire chroot, qui est un cauchemar à administré. L'approche utilisée par mock est très simple, même si elle ne fonctionne qu'avec la stratégie targeted : précharger un factice libselinux qui fait que tous les processus enfants pensent que SELinux est désactivé. Comme mock s’exécute en tant que processus non confiné , cela fonctionne généralement bien.

Cependant, à partir de FC5, le domaine unconfined_t SELinux n'est plus totalement non confiné par SELinux; La protection de la mémoire est mise en œuvre pour protéger la plupart des processus utilisateur contre une variété d’exploits possibles. Cela pose au moins deux types de problèmes lorsqu’on utilise mock dans FC5:

• Lors de la création de packages pour des distributions héritées , le processus de construction peut impliquer le chargement d'anciennes bibliothèques partagées ne comportant pas de sections séparées pour, par exemple, le code exécutable et les données accessibles en écriture. Cela entraîne des refus execmod lorsqu'un processus exécuté dans le domaine unconfined_t tente de charger une telle bibliothèque, sauf si la bibliothèque est libellée textrel_shlib_t
• Lors de la création de packages utilisant mono (la même chose pourrait s'appliquer à Java ), le processus mono devrait normalement s'exécuter dans son propre domaine moins contraint (mono_t); lors de l'exécution sous mock, mono s'exécute dans le domaine unconfined_t , ce qui peut entraîner des execstack et execheap .

Bien qu'il soit possible de désactiver ces contrôles à l'aide de booléens SELinux, ce n'est pas souhaitable pour tous les processus. Une autre solution serait de s'assurer que tous les fichiers sont correctement étiquetés dans le chroot et que les transitions de domaine SELinux se produisent en cas de besoin. Cependant, cela n’est pas possible car le processus factice libselinux que SELinux est désactivé.

La solution suivante à ces problèmes crée une stratégie SELinux pour la simulation comportant deux aspects:

• Il s'exécute dans son propre domaine ( mockt ) aussi libre que tout processus devant s'exécuter, ce qui signifie jusqu'à présent qu'il autorise execheap et execmod , comme le domaine monot .
• Il étiquette tous les fichiers installés sous /var/lib/mock (où mock configure ses environnements chroot) avec le type de contexte spécial mockvarlibt , pour lequel execmod est autorisé pour les processus du domaine mockt .

Cette solution assouplit suffisamment la protection SELinux pour que la simulation puisse fonctionner, sans compromettre la protection offerte au domaine non restreint normal.

Pour installer le module de stratégie:

• Créer un répertoire pour stocker les fichiers de règles locaux, tels que /root/selinux.local
• Télécharger les fichiers: PackageMaintainers_MockTricks_mock.if, PackageMaintainers_MockTricks_mock.fc et PackageMaintainers_MockTricks_mock.te dans ce répertoire
• Générer et installer le module de stratégie comme suit

# make -f /usr/share/selinux/devel/Makefile
Compliling targeted mock module
/usr/bin/checkmodule:  loading policy configuration from tmp/mock.tmp
/usr/bin/checkmodule:  policy configuration loaded
/usr/bin/checkmodule:  writing binary representation (version 5) to tmp/mock.mod
Creating targeted mock.pp policy package
rm tmp/mock.mod.fc tmp/mock.mod

Les packages selinux-policy-devel et checkpolicy sont obligatoires.

Si le module de stratégie est chargé avant l'installation du package mockvarlibt , /var/lib/mock sera étiqueté comme mockvarlibt et /usr/bin/mock sera étiqueté comme mockexect lors de l'installation. Sinon, il est nécessaire d’utiliser restorecon pour corriger les contextes de fichiers:

# restorecon -R /var/lib/mock /usr/bin/mock

Mock peut être utilisé pour créer des chroots permettant de tester des objets, pas seulement de construire des packages. Voici un petit guide:

Créer un fichier de configuration qui pointe vers le ou les référents de votre choix, où se trouvent vos packages de test. 

mock -r <nom_configuration> --init
mock -r <nom_configuration> --install <vos paquets>
mock -r <nom_configuration> --shell

Utiliser mock pour “shell” permettra à mock de créer les points de montage dont on aura probablement besoin à l'intérieur du chroot.