FreeBSD : Bhyve

Bonjour à tous,

Aujourd'hui un nouveau billet qui porte sur Bhyve.

Pour faire court: Bhyve (BSD Hypervisor) est l'outil de virtualisation sous FreeBSD à l'instar de KVM pour Linux.
L'équipe de Bhyve a fait comme choix technique d'utiliser l'extension EPT au niveau CPU. Ce choix restreint donc les architectures possibles (surtout en lien avec l'âge du/des CPU).
Si l'extension EPT n'est pas présente, Bhyve se retrouve très fortement limité: il ne sera possible que de lancer des VM sous FreeBSD et avec uniquement 1 vCPU.

Attention! Dans mon cas j'utilisais un cpu de la génération Nehalem (Xeon L5520) qui a cette extension mais avec une fonctionnalité en moins qui n'arrive qu'à partir de la génération suivante: Westmere. Afin de pouvoir profiter pleinement de Bhyve j'ai dû les remplacer par des Xeon L5640.

Voici la différente, d'abord avec les L5520:

root@bhyve:~ # grep CPU: /var/run/dmesg.boot -A 7  
CPU: Intel(R) Xeon(R) CPU           L5520  @ 2.27GHz (1866.77-MHz K8-class CPU)  
  Origin="GenuineIntel"  Id=0x106a5  Family=0x6  Model=0x1a  Stepping=5
  Features=0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>
  Features2=0x9ce3bd<SSE3,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,DCA,SSE4.1,SSE4.2,POPCNT>
  AMD Features=0x28100800<SYSCALL,NX,RDTSCP,LM>
  AMD Features2=0x1<LAHF>
  VT-x: PAT,HLT,MTF,PAUSE,EPT,VPID
  TSC: P-state invariant, performance statistics

root@bhyve:~ # cpuflags  
/usr/local/bin/cpuflags: gcc: not found
[: -gt: unexpected operator
/usr/local/bin/cpuflags: gcc: not found
Unknown machine - please send cpuflags details to abs@absd.org  
OS    : 'FreeBSD'  
hw.model  : 'Intel Xeon CPU           L5520  @ 2.27GHz'  
hw.machine  : 'amd64'  
hw.machine_arch : 'amd64'  
cpu details :  
CPU: Intel(R) Xeon(R) CPU           L5520  @ 2.27GHz (1866.77-MHz K8-class CPU)  
  Origin="GenuineIntel"  Id=0x106a5  Family=0x6  Model=0x1a  Stepping=5
  Features=0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>
  Features2=0x9ce3bd<SSE3,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,DCA,SSE4.1,SSE4.2,POPCNT>
  AMD Features=0x28100800<SYSCALL,NX,RDTSCP,LM>
  AMD Features2=0x1<LAHF>
  VT-x: PAT,HLT,MTF,PAUSE,EPT,VPID
  TSC: P-state invariant, performance statistics

Cette génération de CPU possède bien l'extension EPT mais n'est pas compatible avec Bhyve.

Maintenant avec les L5640:

root@bhyve:~ # grep CPU: /var/run/dmesg.boot -A 7  
CPU: Intel(R) Xeon(R) CPU           L5640  @ 2.27GHz (2266.79-MHz K8-class CPU)  
  Origin="GenuineIntel"  Id=0x206c2  Family=0x6  Model=0x2c  Stepping=2
  Features=0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>
  Features2=0x9ee3fd<SSE3,DTES64,MON,DS_CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,POPCNT>
  AMD Features=0x2c100800<SYSCALL,NX,Page1GB,RDTSCP,LM>
  AMD Features2=0x1<LAHF>
  VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID
  TSC: P-state invariant, performance statistics

root@bhyve:~ # cpuflags  
/usr/local/bin/cpuflags: gcc: not found
[: -gt: unexpected operator
/usr/local/bin/cpuflags: gcc: not found
Unknown machine - please send cpuflags details to abs@absd.org  
OS    : 'FreeBSD'  
hw.model  : 'Intel Xeon CPU           L5640  @ 2.27GHz'  
hw.machine  : 'amd64'  
hw.machine_arch : 'amd64'  
cpu details :  
CPU: Intel(R) Xeon(R) CPU           L5640  @ 2.27GHz (2266.79-MHz K8-class CPU)  
  Origin="GenuineIntel"  Id=0x206c2  Family=0x6  Model=0x2c  Stepping=2
  Features=0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>
  Features2=0x9ee3fd<SSE3,DTES64,MON,DS_CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,POPCNT>
  AMD Features=0x2c100800<SYSCALL,NX,Page1GB,RDTSCP,LM>
  AMD Features2=0x1<LAHF>
  VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID
  TSC: P-state invariant, performance statistics

La différence est subtile: le L5520 a bien l'extension EPT tout comme le L5640 cependant, ce dernier a en plus le flag UG (Unrestricted Guest) pour le VT-x qui fait toute la différence.

La plateforme utilisée:

  • 2*L5640
  • Supermicro X8DAL-I
  • 3*16Go DDR3 ECC REG
  • Raid 0 de 4*146Go sas 10K

Commencons maintenant par l'ajout des modules nécessaires à Bhyve:

root@bhyve:~ # nano /boot/loader.conf  
if_bridge_load="YES"  
if_tap_load="YES"  
vmm_load="YES"  
nmdm_load="YES"  
  • if_bridge_load : Charge le driver pour avoir un montage automatique des interfaces Bridge
  • if_tap_load : Charge le driver pour avoir un montage automatique des interfaces tap des VM
  • vmm_load : Module nécessaire à la gestion de machines virtuelles
  • nmdm_load : Charge le driver pour avoir accès à une console série

Pour effectuer leur chargement sans devoir redémarrer:

root@bhyve:~ # kldload if_bridge  
root@bhyve:~ # kldload if_tap  
root@bhyve:~ # kldload vmm  
root@bhyve:~ # kldload nmdm  

Afin de se faciliter les opérations, il existe un outil qui s'appelle vm-bhyve qui permet de manipuler Bhyve plus facilement:

root@bhyve:~ # pkg install vm-bhyve grub2-bhyve

La préparation du dataset qui servira à accueillir les VM (si vous utilisez ZFS ce qui est mon cas):

root@bhyve:~ # zfs create tank/vms  
root@bhyve:~ # zfs set mountpoint=/vms tank/vms  

Il faut maitenant rajouter les informations concernant vm-bhyve dans le rc.conf afin qu'il soit lancé automatiquement au boot:

root@bhyve:~ # nano /etc/rc.conf  
# Bhyve
vm_enable="YES"  
vm_dir="zfs:tank/vms"  
vm_list=""  
vm_delay="5"  
  • vm_enable : permet d'activer ou désactiver vm-bhyve
  • vm_dir : spécifie le dossier ou le dataset où seront stockées les VM
  • vm_list : liste des VM avec un démarrage auto (l'ordre dans la liste régie l'ordre de lancement des VM)
  • vm_delay : délais entre le démarrage de chaque VM

On initialise l'installation:

root@bhyve:~ # vm init  

Cette commande crée les répertoires cachés nécessaire au bon fonctionnement de vm-bhyve.

Afin d'automatiser une partie de l'installation (dans le cas de Windows) ainsi que de fournir des paramètres génériques lors de la création des VM, il existe des fichiers de templates:

cp /usr/local/share/examples/vm-bhyve/* /vms/.templates/  

Pour utiliser pleinement ZFS, il faut modifier les fichiers de templates. Vous devez rajouter la ligne suivante au niveau de la partie de gestion des disques pour chaque template que vous allez utiliser :

disk0_dev="sparse-zvol"  

Et modifier les lignes:

disk0_name="disk0.img"  
disk0_type="ahci-hd"  

En:

disk0_name="disk0"  
disk0_type="virtio-blk"  

Ces modifications permettront de créer le disque dur de la vm au sein de ZFS par le biais d'un volume ZFS (zvol) et non d'un fichier .img.

Pour que nos VM puissent avoir accès à des ressources réseaux (internet ou un LAN quelconque), il est nécessaire de créer un virtual switch (vswtich):

root@bhyve:~ # vm switch create public  
root@bhyve:~ # vm switch list  
NAME            TYPE       IDENT       VLAN      NAT          PORTS  
public          auto       bridge0     -         -            -  

Le vswitch étant créé, il faut maintenant lui attacher une interface physique pour pouvoir avoir accès à internet/LAN (étape qu'il est possible de sauter si vous souhaitez uniquement créer un vswitch):

root@bhyve:~ # vm switch add public em1  
root@bhyve:~ # vm switch list  
NAME            TYPE       IDENT       VLAN      NAT          PORTS  
public          auto       bridge0     -         -            em1  

Attention! L'interface que l'on ajoute au virtualswitch doit avoir une adresse IP sinon le traffic ne sort pas.

Nous pouvons maintenant créer la VM et lancer son installation:

root@bhyve:~ # vm create -t freebsd-zvol -s 16G testvm  
root@bhyve:~ # vm install testvm FreeBSD-11-boot-only.iso  

Attention! Au boot de l'installeur de FreeBSD, il vous sera demandé le type de console, il faut bien choisir VT100 (normalement le choix par défaut).

Une fois l'installation terminée, il faut choisir l'option pour avoir accès à un shell et faire poweroff afin de pouvoir récupérer la main sur votre terminal de départ.
Vous pouvez maintenant démarrer la VM et y accéder via SSH.

Une petite liste des commandes de base:

  • Lister toutes les VM, qu'elles soient démarrées ou non:
root@bhyve:~ # vm list  
  • Démarrer une VM:
root@bhyve:~ # vm start testvm  
  • Arrêter une VM (via ACPI):
root@bhyve:~ # vm stop testvm  
  • Stopper une VM en restant appuyer sur le bouton power:
root@bhyve:~ # vm poweroff testvm  
  • Appuyer sur le bouton reset de la VM:
root@bhyve:~ # vm reset testvm  
  • Se connecter à la console de la VM (pour sortir de la console il faut utiliser: ~.):
root@bhyve:~ # vm console testvm  
  • Supprimer une VM (doit être arrêtée):
root@bhyve:~ # vm destroy testvm  
  • Permet de changer ou rajouter des options à la VM (lance vi en éditeur):
root@bhyve:~ # vm configure testvm  
  • Pour augmenter la taille du disque de la VM:
root@bhyve:~ # zfs set volsize=32G zroot/vms/testvm/disk0  

Vous avez maintenant une installation de Bhyve fonctionnelle!

Have a nice day.

FreeBSD: passage de 10.3 à 11.0

Bonjour à tous,

Aujourd'hui un petit billet portant sur le changement de version de FreeBSD.

Les versions 10.x de FreeBSD étant dépréciées chacune leur tour, j'ai donc migré toutes mes VM vers la version 11.0.
La procédure en elle-même est plutôt simple si elle est bien respectée.

Tout d'abord: FAITES DES BACKUPS/SNAPSHOT!
Cela permet d'éviter des soucis.

Une chose importante à savoir: il n'est clairement pas conseillé de sauter une version. Si votre VM est en 10.2, il faut faire 2 migrations: 10.2 -> 10.3 puis 10.3 -> 11.0.
J'ai expérimenté le passage de 10.2 à 11.0 directement et il s'en est résulté des comportements étranges et une instabilité de la VM.

Pour commencer, il faut mettre à jour la version actuelle, pour ça rien de plus simple:

freebsd-update fetch  
freebsd-update install  

Il est maintenant possible de récupérer les fichiers nécessaires au changement de version:

freebsd-update upgrade -r 11.0-RELEASE  

Cette étape peut être assez longue (de 15 à 30 mins) suivant la VM sur laquelle cela s'exécute.

Il reste à appliquer cette nouvelle version:

freebsd-update install  

Une fois cette opération terminée, il faut redémarrer:

shutdown -r now  

Après ce reboot, il faut à nouveau appliquer le changement de version:

freebsd-update install  

Pour pouvoir continuer à utiliser la VM dans de bonnes conditions, il faut mettre à jour les logiciels présents sur la VM. Cependant, pkg n'étant plus dans la bonne version pour la FreeBSD 11, il faut utiliser pkg-static:

pkg-static update -f  
pkg-static install -f pkg  

Cela permet de forcer l'installation de pkg dans la bonne version pour FreeBSD 11.

Il ne reste plus qu'à mettre à jour tous vos logiciels:

pkg upgrade  

Une dernière application de la nouvelle version est nécessaire ainsi qu'un dernier reboot:

freebsd-update install  
shutdown -r now  

Le reboot terminé, il est possible de vérifier la version en place:

freebsd-version -k  

Vous devriez avoir un retour comme cela:

root@hark:~ # freebsd-version -k  
11.0-RELEASE-p2  

Have a nice day!

FreeBSD: Opensmtpd en relay localhost

Bonjour à tous,

Aujourd'hui un petit billet rapide sur la mise en place d'Opensmtpd servant de relay pour l'envoi de mail vers root et configuré uniquement pour accepter les connexions depuis le localhost.

En premier lieu, il faut procéder à son installation:

pkg install opensmtpd

Il faut ensuite modifier le fichier /etc/rc.conf afin de désactiver Sendmail (qui sert par défaut à l'envoi des mails interne) puis d'activer opensmtpd:

# Disable Sendmail MTA
sendmail_enable="NO"
sendmail_submit_enable="NO"
sendmail_outbound_enable="NO"
sendmail_msp_queue_enable="NO"

smtpd_enable="YES"

Nous pouvons maintenant passer à sa configuration qui, dans notre cas va être très simple. Le fichier de configuration se trouve ic /usr/local/etc/mail/smtpd.conf.

# This is the smtpd server system-wide configuration file.
# See smtpd.conf(5) for more information.

# To accept external mail, replace with: listen on all
listen on 127.0.0.1
listen on ::1

# If you edit the file, you have to run "smtpctl update table aliases"
table aliases db:/usr/local/etc/mail/aliases.db
table secrets db:/usr/local/etc/mail/secrets.db

accept from local for domain votredomain.fr relay via tls+auth://label@votreserveur.votredomain.fr auth 

il est nécessaire de spécifier le compte depuis lequel le mail sera envoyé et depuis lequel l'authentification au niveau du serveur de mail sera effectuée. Pour cela il faut créer le fichier /usr/local/etc/mail/secrets:

label email@votredomain.fr:password

Il est possible d'utiliser le fichier d'aliases se trouvant dans /etc/aliases mais j'ai préféré ne pas y toucher et en faire une copie à coté du fichier de configuration d'opensmtpd:

cp /etc/aliases /usr/local/etc/aliases

Il reste à l'éditer afin de changer l'adresse mail associé à root.
Une fois ces modifications faites, il faut générer/regénérer les fichiers db, pour cela rien de plus simple:

/usr/local/libexec/opensmtpd/makemap secrets
/usr/local/libexec/opensmtpd/makemap aliases

Le service doit être maintenant démarré afin d'être opérationnel:

service smtpd start

Le relay de vos mails locaux est désormais opérationnel!

Si vous souhaitez voir la file d'attente du relay:

smtpctl show queue

Si vous souhaitez supprimer un message rien de plus simple. En premier lieu, il faut afficher la queue (comme vu précédemment) puis utiliser la commande suivante:

smtpctl remove idmessage

Il suffit de remplacer idmessage par l'identifiant du mail à supprimer.

Have a nice day.

FreeBSD: routage avec des vtnet

Bonjour à tous,

Un petit billet portant sur la mise en place d'une machine virtuelle sous FreeBSD avec des cartes en VIRTIO (sous proxmox 4) qui servira de routeur (et de firewall).
Au départ j'utilisais des cartes en e1000 mais le type VIRTIO est censé être plus performant.

Un souci simple mais très handicapant s'est présenté: les paquets arrivent bien sûr les interfaces mais n'en repartent jamais.
Cependant, un tcpdump voyait bien les paquets arriver, montrait bien leur départ mais la commande (un ping par exemple) tombait en timeout.

Le fautif: le checksum offload hardware. Ce mécanisme sert à décharge le checksum des entêtes au niveau de la carte réseau (si elle possède cette capacité).

Pour le désactiver rien de plus simple:

ifconfig vtnet0 -rxcsum -txcsum

Le voici désactivé pour l'IPv4.
Si vous faites de l'IPv6, la commande n'est pas plus compliquée:

ifconfig vtnet0 -rxcsum6 -txcsum6

Et le ping est fonctionnel.
Ce souci était présent sur tout ce qui passait par ce routeur, que ce soit du simple icmp ou de l'http/https.

Cependant attention! au prochain reboot, la modification n'est plus effective. Pour que cela soit persistent, il faut rajouter ce qui suit dans votre /etc/rc.conf :

ifconfig_vtnet0="inet bla netmask bla -rxcsum -txcsum"
ifconfig_vtnet0_ipv6="inet6 bla prefixlen 64 -rxcsum6 -txcsum6"

La modification sera valable tout le temps maintenant.

Have a nice day.

Boris

FreeBSD: poudriere ou comment gérer ses paquets

Edit 23/03/16: maj de l'article pour le vhost et la déclaration du nouveau répo.
Edit 24/01/17: maj de l'article pour ajout désactivation repo FreeBSD

Bonjour à vous,

Aujourd'hui, un long billet qui va porter sur un logiciel FreeBSD: Poudriere.

Pour débuter, une petite explication : Poudriere est un logiciel permettant d'automatiser et de maintenir un serveur de packages privé. Il permet de compiler automatiquement une série de packages avec des options de compilation ainsi qu'un environnement prédéfini.
Privé au sens qu'il n'est pas dans la liste des dépôts publics de FreeBSD, mais si vous suivez ce billet, il le sera de tous ceux qui connaissent l'URL.

Par exemple, si vous avez besoin d'une version de php/perl fixe pour un environnement donné, il vous suffit de le fixer dans les fichiers de configuration dédié à cet arbre de ports. Ce qui permettra de ne pas changer d'environnement lors des prochains updates.

Prérequis

Afin de pouvoir utiliser Poudriere dans les meilleures conditions, ZFS est nécessaire.

Pour activer ZFS, il suffit de faire:

echo 'zfs_enable="YES"' >> /etc/rc.conf

Son utilisation permet d’accélérer la création de jails et le traitement des fichiers des différents ports.

Installation

L'installation de Poudriere est tout ce qu'il y a de plus classique :

pkg update
pkg install poudriere

Maintenant, il faut créer le dossier qui sera le point de montage du zpool ZFS:

mkdir /Poudriere
zpool create -m /poudriere poudriere /dev/vtbd1

Vous pouvez changer le dossier sans soucis. Cependant, il faudra adapter le reste du billet à ce changement.

Nous allons maintenant passer à la configuration de base de Poudriere.
Cela se passe dans le fichier /usr/local/etc/poudriere.conf :

ZPOOL=poudriere
ZROOTFS=/poudriere
FREEBSD_HOST=ftp://ftp.freebsd.org
RESOLV_CONF=/etc/resolv.conf
BASEFS=/usr/local/poudriere
USE_TMPFS=yes
ALLOW_MAKE_JOBS=yes

Petite explication des options ci-dessus:

  • ZPOOL : le nom de votre pool ZFS
  • ZROOTFS : la racine de votre pool (ou le point de montage)
  • FREEBSD_HOST : l’hôte à partir duquel télécharger les ports et la distribution. A adapter suivant votre pays afin d'avoir de meilleures performances.
  • RESOLV_CONF : le fichier de configuration du client DNS utilisé par poudrière.
  • BASEFS : le répertoire où poudrière va mettre ses jails et ports
  • USE_TMPFS : demander à Poudriere d’utiliser un TMPFS pour la compilation, il est possible de le désactiver en commentant la ligne si vous êtes limité en ram.
  • ALLOW_MAKE_JOBS=yes : permet de compiler un port avec plusieurs cpu/coeurs.

Ports et jail

Nous allons maintenant créer un arbre de ports par défault:

poudriere ports -c -p default

Options:

  • -c : indique la création de l'arbre de ports
  • -p : définie le nom de l'arbre de ports créé

Le nom peut être changé (ici default) au moment de la création.
/!\ Attention! Une fois créé il n'est plus possible de le changer.

Nous passons maintenant à la création de notre première jail:

poudriere jail -c -j "F102" -v "10.2-RELEASE" -a amd64

Options:

  • -c : indique la création de la jail
  • -j : définie le nom de la jail
  • -v : définie la version de FreeBSD voulue
  • -a : définie l'architecture voulue

Dans ce cas précis, je crée une jail pour la version 10.2 de FreeBSD avec comme architecture AMD64.

Fichiers make

Les fichiers de configuration pour la compilation (make.conf) sont stockés dans un dossier en particulier.
Il faut vérifier si ce dossier est bien présent, sinon il faut le créer:

mkdir /usr/local/etc/poudriere.d

Il est ensuite possible de passer des paramètres (ou knobs) à toutes les jails de Poudriere par le biais du fichier make.conf:

echo "WITH_PKGNG=yes" > /usr/local/etc/poudriere.d/make.conf
echo "WITHOUT_X11=yes" >> /usr/local/etc/poudriere.d/make.conf

Avec ces paramètres dans ce fichier en particulier, TOUTES les compilations seront faites avec le support de PKG pour l'installation des packets et sans le support X11.

Il est possible d'ajouter ces options uniquement pour une jail en particulier, il faudra pour cela ajouter ces options dans le fichier dédié à la jail. Par exemple dans le fichier F102-make.conf au lieu de make.conf.

Afin de gérer les logiciels à compiler, on peut soit préciser les logiciels à la main lors du lancement de la compilation ou les mettres dans un fichier. J'ai choisis la deuxième méthode, voici par exemple le contenu du fichier /usr/local/etc/Poudriere.d/F102-ports :

editors/nano
www/nginx

Une fois ce fichier renseigné, il faut choisir les options de compilation. La commande suivante est l'équivalent d'un make config-recursive:

poudriere options -f /usr/local/etc/poudriere.d/F102-ports -j F102 -p default

Compilation

Il ne reste plus qu'à lancer la compilation des logiciels que nous avons choisis:

poudriere bulk -f /usr/local/etc/poudriere.d/F102-ports -j F102 -p default

Options

  • -f : spécifie un fichier avec une liste de paquets à compiler
  • -p : spécifie le nom de l'arbre de ports à utiliser

Une fois la compilation terminée, il est possible de vérifier le contenu de l'arbre de ports:

ls -al /usr/local/poudriere/data/packages/F102-default

Le dossier peut être différence suivant le paramètre que vous avez fixé dans le fichier de configuration.

Update

Une fois ces premières étapes réalisées, la maintenance et l'update de notre arbre de ports, de notre jail et donc par association de la compilation qui va avec ce fait de la manière suivante.

En premier lieu, il faut mettre à jour notre arbre de ports:

poudriere ports -u -p default

Options:

  • -u : indique que nous voulons mettre à jour notre ports.
  • -p : spécifie le nom de l'arbre de ports à mettre à jour.
poudriere bulk -f /usr/local/etc/poudriere.d/F102-ports -j F102 -p default

Une fois la compilation terminée, vous aurez un rapport sur les paquets compilés. Deux formes de rapport: dans le shell directement avec le nombre de packages compilés, les échecs et les warning. Il y a également une page HTML regroupant ces informations.

Mise à disposition des paquets

Une fois les paquets compilés, il faut les mettre à disposition par le biais d'un serveur HTTP afin qu'ils soient accessibles par les serveurs.

Pour cela deux solutions:

  • Soit vous exposez directement le dossier /use/local/poudriere/data/packages/F102-default (chemin qui peut changer en fonction de ce que vous avez renseigné dans le fichier de configuration de Poudriere).
  • Soit vous faites une synchronisation de ce dossier sur un autre serveur qui lui mettre à disposition par HTTP les paquets.

De mon côté j'ai choisis la deuxième solution avec comme serveur HTTP Nginx.

Il faut mettre en place une réplication des packages entre l'arborescence de Poudriere et le serveur HTTP. Pour cela, rien de plus simple: rsync.

rsync -az /use/local/poudriere/data/packages/ serveur_ip_ou_nom:/chemin/vers/cible

Options:

  • -az : a pour le mode archivage qui permet de conserver les droits/permissions et de copier de façon récursive. z pour compresser les données avant l'envoie.

Cette commande utilise automatiquement SSH, il n'est plus nécessaire de le préciser.

Il est possible de rajouter un v (donc -avz) pour avoir un mode verbose, utile pour la première synchro.

Reste maintenant à configurer la partie HTTP. Pour cela, je créé un fichier de vhost dédié:

server {
    listen       80;
    listen       [::]:80;
    server_name  repo.securmail.fr;

    access_log  /var/log/repo/access.log;
    error_log   /var/log/repo/error.log;

    location / {
        root   /var/www/repo/;
        index  index.html index.htm;
        autoindex on;
    }
}

Attention! C'est du HTTP uniquement car je n'ai pas réussi à faire fonctionner pkg avec un repo en HTTPS et certificat autosigné.

Plusieurs choses sont importantes:

  • les logs: il faut faire attention que le dossier existe bien, sinon vous pouvez le changer sans soucis.
  • root: il s'agit du dossier où vont se trouver les packages, à adapter en fonction de la où vous les avez synchronisés.
  • autoindex: il est obligatoire d'avoir cet option d'activé, cela permet de lister automatiquement le contenu du dossier.

Il vous suffit d'effectuer un reload de Nginx et normalement votre repository privé sera opérationnel!

Afin de maintenir cette infrastructure en bon état de marche, il est possible de réaliser un script qui effectue les étapes d'update, de compilation et de synchronisation appelé depuis une tâche cron. Cela permettra d'avoir une arborescence toujours à jour.

Ce script sera aussi accessible pour un lancement à la main si vous souhaitez rajouter un logiciel qui n'est pas présent au sein du repository et que vous souhaitez l'ajouter sans délais.

Ajouter son repository

Maintenant que notre repository est accessible, il faut l'ajouter sur nos différents serveurs FreeBSD. Pour cela il faut créer le fichier suivant /usr/local/etc/pkg/repos/local.conf.
Il faut vérifier si le dossier /usr/local/etc/pkg/repos/ existe sinon, il faut le créer:

mkdir -p /usr/local/etc/pkg/repos/

Nous allons maintenant remplir le fichier local.conf

nano /usr/local/etc/pkg/repos/local.conf

Avec comme contenu:

myrepo: {
    url: "pkg+http://repo.yourdomain.fr/F102-default",
    mirror_type: "srv",
    signature_type: "none",
    fingerprints: "/usr/share/keys/pkg",
    enabled: yes
}

Suivant comment vous avez nommé votre repository, il faudra changer F102-default par ce que vous avez choisis.
Il est possible de changer le nom de notre repository en changeant myrepo par ce que vous souhaitez.

Une fois ce fichier complété, il suffit de faire:

pkg update
Updating FreeBSD repository catalogue...
FreeBSD repository is up-to-date.
Updating myrepo repository catalogue...
Fetching meta.txz: 100%    264 B   0.3kB/s    00:01    
Fetching packagesite.txz: 100%    3 KiB   3.1kB/s    00:01    
Processing entries: 100%
myrepo repository update completed. 8 packages processed.
pkg upgrade
Updating FreeBSD repository catalogue...
FreeBSD repository is up-to-date.
Updating myrepo repository catalogue...
myrepo repository is up-to-date.
All repositories are up-to-date.
Updating database digests format: 100%
New version of pkg detected; it needs to be installed first.
The following 1 package(s) will be affected (of 0 checked):

Installed packages to be UPGRADED:
    pkg: 1.6.3 -> 1.6.4 [myrepo]

Comme vous le constatez, notre repository est bien accessible et prit en compte.

A partir de ce point, il ne vous reste plus qu'à ajouter les logiciels dont vous avez besoin à votre repository.

Si vous souhaitez désactiver le repository FreeBSD de base il suffit de créer le fichier /usr/local/etc/pkg/repos/FreeBSD.conf et d'y inscrire le contenu suivant:

FreeBSD: { enabled: no }

Have a nice day.

PS: un grand merci à Solène Rapenne pour son aide et ses conseils :)