Accueil > Domotique > Changement d’infrastructure serveur ???

Changement d’infrastructure serveur ???

lundi 27 octobre 2025, par johann

L’idée de derrière tout ceci :

Je suis les vidéos YouTube de Raynox, dont l’infrastructure domotique ressemble beaucoup à la mienne, tout comme la logique qui nous a amené à ce type d’architecture. L’une de ses vidéos a particulièrement retenu mon attention : il y expose des arguments pertinents, notamment celui du choix d’exécuter un conteneur Docker à l’intérieur d’une machine virtuelle QEMU/KVM ou d’un conteneur LXC, autrement dit, une virtualisation en deux niveaux.

Intuitivement, on sent bien que cette approche n’est pas optimale.

Dans un second temps, il présente une alternative que je ne connaissais pas : une distribution Fedora intégrant l’interface web Cockpit, qui permet de gérer aussi bien des conteneurs Podman (équivalents de Docker) que des machines virtuelles QEMU/KVM.

J’avais un mini-PC (Ryzen 5 3500U) qui prenait la poussière dans un coin ... et une carte Hailo 8L en PCIe fraîchement commandée. Alors, par curiosité et un peu pour le fun de la bidouille, je me suis dit :

“Allez, voyons ce que ça peut donner !”

1. Installation de Fedora Server

L’installation de Fedora Server ne présente pas de difficulté particulière, même si son installateur peut sembler un peu déroutant lorsqu’on vient plutôt de l’univers Debian ou Manjaro.

Le processus recommande de désactiver le compte root et de créer à la place un compte utilisateur disposant des privilèges sudo, qui servira à l’administration du système.

J’ai opté pour une installation minimaliste de Fedora Server, sans sélectionner d’autres paquets : tout le reste sera ajouté plus tard, selon les besoins.

Le serveur SSH est opérationnel et activé par défaut, tout comme Cockpit, la suite d’administration web intégrée à Fedora.

En fin d’installation, la machine est immédiatement accessible à distance, que ce soit en SSH pour la ligne de commande ou via Cockpit pour la gestion graphique.

Pour identifier l’adresse IP de votre serveur, deux options s’offrent à vous : soit consulter les informations de votre serveur DHCP (par exemple dans l’interface de votre routeur/box), soit vous connecter physiquement (clavier + écran) à la machine et exécuter la commande ip -a

Une fois votre serveur identifié sur le réseau, la première opération est de mettre à jour la machine, en ligne de commande avec sudo dnf upgrade --refresh -y ou à partir de l’interface cockpit.

Les outils logiciels pour la gestion des containers Podman et des machines virtuelles sont installables dans le menu « Outils » / « Applications » de l’interface de Cockpit.

Dans le menu réseau, il est également possible de définir une adresse ipv4 statique et de créer une interface bridge.

⚠️ Gestion d’espace disque sous Fedora (LVM)

Lors d’une installation par défaut de Fedora utilisant le gestionnaire de volumes logiques (LVM), tout l’espace disque disponible n’est pas immédiatement alloué au volume logique racine (/dev/mapper/fedora-root). Pour visualiser l’état en cours df -h

La commande sudo vgs permet pour voir les détails du groupe de volumes et l’espace libre non alloué (Colonne VFree).

Pour l’assigner,en totalité ou en partie à la partition racine, la commande sudo lvextend -r -L+XXX.XXg /dev/mapper/fedora-root est a exécuter, avec XXX.XXg la valeur en Gb, selon la quantité de disque disponible indiqué par la commande vgs

Enfin pour confirmer : df -h

2. Installation de Frigate dans un container Podman

L’un des avantages majeurs de Podman par rapport à Docker est sa capacité à exécuter des conteneurs en mode rootless, c’est-à-dire sans privilèges administrateur. Les conteneurs tournent alors avec les droits d’un simple utilisateur du système, ce qui renforce considérablement la sécurité.

Pour cela, il suffit de créer un utilisateur dédié, ici nommé « frigate », qui sera responsable de l’exécution du conteneur Podman Frigate. Cette création peut se faire aussi bien en ligne de commande qu’à partir de l’interface web Cockpit.

L’utilisateur frigate doit pouvoir accéder au GPU de la machine afin de bénéficier de l’accélération matérielle pour le décodage des flux vidéo.

Sous Linux, les périphériques graphiques /dev/dri/cardX et /dev/dri/renderD128 appartiennent respectivement aux groupes video et render. Il est donc nécessaire d’ajouter notre utilisateur frigate à ces deux groupes afin qu’il puisse y accéder avec les commandes sudo usermod -aG video frigate et sudo usermod -aG render frigate

Le système Fedora est maintenant opérationnel, avec deux comptes bien distincts :

un utilisateur administrateur, disposant des droits sudo pour gérer la machine,
et un utilisateur standard, dédié à l’exécution du conteneur Frigate avec des droits sur le GPU.

Cette distinction est importante, car certaines commandes devront être exécutées par l’un ou l’autre de ces comptes, selon qu’elles concernent la configuration du système hôte ou celle du conteneur.

Il s’agit à présent de mettre en place un conteneur Frigate basique, sans accélération matérielle pour la détection (c’est-à-dire sans module Hailo-8L).

Par défaut, Fedora Server est protégé par un pare-feu actif. Il faut donc autoriser l’accès aux ports utilisés par Frigate, avec le compte administrateur, soit directement depuis l’interface web Cockpit, soit en ligne de commande avec les instructions suivantes :

sudo firewall-cmd --add-port=5000/tcp --permanent
sudo firewall-cmd --add-port=8555/tcp --permanent
sudo firewall-cmd --add-port=8554/tcp --permanent
sudo firewall-cmd --add-port=8554/udp --permanent
sudo firewall-cmd --add-port=8555/udp --permanent

Le démarrage du conteneur Frigate, dans un terminal de l’utilisateur standard Frigate, s’effectue à l’aide de la commande suivante :

frigate@localhost:~$ podman run -d --name frigate --restart=unless-stopped --shm-size=256m --device /dev/dri:/dev/dri -v /etc/localtime:/etc/localtime:ro -v /home/frigate/config:/config:z -v /home/frigate/media:/media/frigate:z --tmpfs /tmp/cache:size=1000000000,mode=1777 -p 5000:5000 -p 1935:1935 -p 8554:8554 -p 8555:8555/tcp -p 8555:8555/udp -e FRIGATE_RTSP_PASSWORD='monMotdePasse' ghcr.io/blakeblackshear/frigate:stable
ff900b6866c639bd85ac0b183cb3789059c404c93deee2ae051966bfff9fd428
frigate@localhost:~$

Le conteneur démarre correctement, mais le fichier de configuration par défaut de Frigate provoque quelques problèmes dans mon cas.
J’ai donc dû l’adapter à ma configuration, puis effectuer un redémarrage forcé du conteneur depuis l’interface Cockpit pour que les modifications soient prises en compte.

Vitesse du détecteur de frigate avec 2 cameras h264 2k et une détection sur CPU uniquement

Les performances sont pour l’instant modestes, mais l’ajout de l’inférence matérielle pour la détection devrait normalement les améliorer de manière significative.

3. Détails de la commande « podman run »

Je détaille ci-dessous, pour mémoire, la commande de base présentée ci-dessus, accompagnée d’options et d’explications complémentaires, pas toujours évidentes à saisir au premier abord, notamment en ce qui concerne les implications en matière de sécurité.
L’objectif étant de mettre en place un conteneur rootless, il serait dommage de tout compromettre en négligeant ces aspects.

⚙️ Options générales Podman

podman run -d \
  --name frigate \
  --restart=unless-stopped \
  ....
  ghcr.io/blakeblackshear/frigate:stable

La commande podman run initialise un nouveau conteneur nommé « frigate », en utilisant l’image spécifiée à la fin de la commande. Le conteneur est lancé en mode détaché, c’est-à-dire qu’il s’exécute en arrière-plan comme un démon, et il est configuré pour redémarrer automatiquement, sauf lorsqu’il est arrêté manuellement.

💾 Mémoire et périphériques

L’option --shm-size=256m permet de définir la taille du segment mémoire partagé (/dev/shm), utile au buffering vidéo (FFmpeg et TensorFlow l’utilisent)

L’option --device /dev/dri:/dev/dri permet au conteneur Podman d’accéder directement à la carte graphique de l’hôte, activant ainsi l’accélération matérielle (hardware) pour le traitement vidéo.
Pour que cela fonctionne correctement, l’utilisateur exécutant le conteneur (dans mon cas frigate) doit appartenir aux groupes video et render, afin d’avoir les permissions nécessaires sur les périphériques GPU.

frigate@localhost:~$ ls -al /dev/dri
total 0
drwxr-xr-x.  3 root root        100 23 oct.  17:41 .
drwxr-xr-x. 20 root root       4040 23 oct.  17:41 ..
drwxr-xr-x.  2 root root         80 23 oct.  17:41 by-path
crw-rw----.  1 root video  226,   1 23 oct.  17:41 card1
crw-rw-rw-.  1 root render 226, 128 23 oct.  17:41 renderD128

frigate@localhost:~$ sudo usermod -aG render frigate
frigate@localhost:~$ sudo usermod -aG video frigate

🔒 Sécurité et permissions

  --group-add keep-groups \
  --security-opt label=disable \
  --cap-add CAP_PERFMON \
  --cap-add SYS_ADMIN \

L’option --group-add keep-groups autorise le conteneur à hériter des groupes secondaires de l’utilisateur hôte.
Cependant, ici, elle est superflue : les périphériques GPU sont explicitement montés via --device /dev/dri:/dev/dri, et l’utilisateur qui lance le conteneur rootless est déjà membre des groupes nécessaires (video et render).
Cette ligne est conservée uniquement à titre informatif.

Sur une distribution Fedora Server, la configuration par défaut de SELinux empêche un conteneur rootless d’accéder aux statistiques du GPU, ce qui génère l’erreur :
Unable to poll intel GPU stats: Failed to initialize PMU! (Operation not permitted).
Les options permettent simplement de contourner cette restriction et d’obtenir l’accès aux statistiques GPU, au prix d’un compromis sur la sécurité.

--security-opt label=disable : Désactive l’isolation SELinux.
--cap-add CAP_PERFMON : Autorise la lecture des compteurs de performance matériels (GPU/CPU). Requis pour la télémétrie GPU (intel_gpu_top, Frigate GPU stats).
--cap-add SYS_ADMIN : Donne un large accès système (quasi root).

Pour mémoire également, l’option --privileged confère au conteneur des privilèges quasi équivalents à ceux du root de l’hôte. Cela permet l’accès direct à tous les périphériques (/dev/dri/*, /dev/video*, etc.), rendant superflue la configuration des groupes pour l’accès GPU.

En environnement de production, l’accès aux statistiques du GPU n’étant pas vital, il est conseillé de retirer ces options afin de réduire les risques et renforcer la sécurité.

📂 Volumes et répertoires montés

-v /etc/localtime:/etc/localtime:ro	.
-v /home/frigate/config:/config:z
-v /home/frigate/media:/media/frigate:z

Ces options sont classiques sous Docker ou Podman et permettent de partager certains fichiers ou volumes entre l’hôte et le conteneur.
Il faut toutefois prêter une attention particulière au montage des volumes : l’ajout de l’option :z est nécessaire sous SELinux afin d’ajuster automatiquement le contexte de sécurité et permettre l’accès aux données par le conteneur.

--tmpfs /tmp/cache:size=1000000000,mode=1777
Cette option créee un Ramdisk temporaire en mémoire vive (≈ 1 Go) pour le cache vidéo (plus rapide que le disque), accessible à tous (mode=1777)

🌐 Réseau et ports exposés

  -p 5000:5000 \
  -p 1935:1935 \
  -p 8554:8554 \
  -p 8555:8555/tcp \
  -p 8555:8555/udp \

Ces options sont également classiques sous Docker ou Podman et permettent d’exposer les ports de l’interface web de frigate (5000), des flux RTMP(1935) , des flux RTSP restreamés (8554) et des flux WebRTC faible latence (8555 / UDP & TCP)

🌿 Variables d’environnement

-e FRIGATE_RTSP_PASSWORD=''monMotdePasse''

Frigate intègre un serveur RTSP interne qui permet de restreamer les flux vidéo des caméras (par exemple pour les visualiser dans Home Assistant, VLC ou d’autres clients RTSP). La variable d’environnement FRIGATE_RTSP_PASSWORD sert à définir le mot de passe RTSP utilisé pour accéder à ces flux restreamés sur rtsp ://ip_du_serveur:8554/nom_de_camera ?user=frigate&password=’monMotdePasse’

4. Hailo 8L / Compilation

Le système logiciel Hailo est une pile d’éléments qui interagissent ensemble.

1️⃣ Pilote PCIe (Kernel Driver) : C’est le module bas niveau qui permet au système d’exploitation (Fedora Server) de voir le périphérique et de communiquer avec lui (lecture/écriture sur le bus PCIe).

2️⃣ Firmware (hailo8_fw.bin) : C’est le microcode qui est chargé sur le Hailo-8L lui-même par le pilote au démarrage. Il gère le fonctionnement interne de la puce.

3️⃣ Runtime HailoRT : C’est la bibliothèque que vos applications utilisent pour envoyer des modèles et des données au périphérique.

Le pilote PCIe (driver), le runtime HailoRT (bibliothèque logicielle) et le firmware du Hailo-8L doivent idéalement être de la même version, cela évite d’avoir à ce poser des questions lorsque cela ne fonctionne pas.

⚙️ Vérification de la détection physique (PCIe)
La commande lspci permet de vérifier la présence de la carte Hailo sur le bus PCI Express :

johann@localhost:~$ lspci -nnk | grep -i hailo
04:00.0 Co-processor [0b40]: Hailo Technologies Ltd. Hailo-8 AI Processor [1e60:2864] (rev 01)
        Subsystem: Hailo Technologies Ltd. Hailo-8 AI Processor [1e60:2864]
        Kernel driver in use: hailo
        Kernel modules: hailo_pci

Si la carte est détectée, une ligne mentionnant l’appareil devrait apparaitre. Les ligne « Kernel driver in use » et « Kernel driver » devraient être vide à ce stade, mais vous voyez un retour car, au moment où j’écris ceci, mon système est opérationnel et le pilote est déjà chargé."

Si rien n’apparaît : La carte n’est pas détectée. Le problème est matériel (mauvaise installation, slot PCIe désactivé/défectueux, ou alimentation, ...).

🔍 Identification de la version du Runtime HailoRT
Comme indiqué précédemment, les trois composants de la pile logicielle Hailo doivent idéalement être de versions compatibles. Le driver s’exécute sur le système hôte, tandis que le runtime et les bibliothèques logicielles fonctionnent à l’intérieur du conteneur Frigate. Une fois le conteneur opérationnel, la commande podman ci-dessus permet de vérifier la version du runtime utilisée par l’image Frigate.

frigate@localhost:~$ podman exec frigate hailortcli --version
HailoRT-CLI version 4.21.0

⚙️ Compilation du pilote PCIe (Kernel Driver)

La documentation et les fichiers nécessaires pour la carte Hailo-8L requièrent la création d’un compte développeur sur le site Hailo.ai. Bien qu’un paquet .deb prêt à l’emploi soit fourni pour Ubuntu, aucune solution n’est proposée pour Fedora.
Pour contourner ce problème, je me suis appuyé sur la documentation de Frigate, qui fournit un script (à adapter), permettant de télécharger directement les fichiers depuis le GitHub librement accessible, et les étapes de compilation.

Avec le compte utilisateur administrateur, voici l’ensemble des commandes que j’ai rentré :

sudo dnf install -y gcc make cmake kernel-devel kernel-headers dkms git

hailo_version='4.21.0'

git clone --depth 1 --branch v${hailo_version} https://github.com/hailo-ai/hailort-drivers.git

cd hailort-drivers/linux/pcie

sudo make all
sudo make install

cd ../../
./download_firmware.sh
sudo mkdir /lib/firmware/hailo
sudo cp hailo8_fw.4.21.0.bin /lib/firmware/hailo
sudo ln -s /lib/firmware/hailo/hailo8_fw.4.21.0.bin /lib/firmware/hailo/hailo8_fw.bin

sudo cp ./linux/pcie/51-hailo-udev.rules /etc/udev/rules.d/
sudo udevadm control --reload-rules && sudo udevadm trigger

La règle udev fixe les permissions sur /dev/hailo0 à 0666

cat ./linux/pcie/51-hailo-udev.rules
#Change mode rules for Hailo's PCIe driver
SUBSYSTEM=='hailo_chardev', MODE='0666'

Et enfin un sudo modprobe hailo_pci, si tout c’est correctement déroulé, entraine avec sudo dmesg le chargement du driver :

[161447.538082] hailo: Init module. driver version 4.21.0
[161447.538197] hailo 0000:04:00.0: Probing on: 1e60:2864...
[161447.538205] hailo 0000:04:00.0: Probing: Allocate memory for device extension, 13192
[161447.549591] hailo 0000:04:00.0: Probing: Device enabled
[161447.549626] hailo 0000:04:00.0: Probing: mapped bar 0 - 000000007146fbe2 16384
[161447.549639] hailo 0000:04:00.0: Probing: mapped bar 2 - 000000002a9ea0a1 4096
[161447.549650] hailo 0000:04:00.0: Probing: mapped bar 4 - 0000000064a2fabf 16384
[161447.549657] hailo 0000:04:00.0: Probing: Setting max_desc_page_size to 4096, (page_size=4096)
[161447.549749] hailo 0000:04:00.0: Probing: Enabled 64 bit dma
[161447.549755] hailo 0000:04:00.0: Probing: Using userspace allocated vdma buffers
[161447.549761] hailo 0000:04:00.0: Disabling ASPM L0s 
[161447.549767] hailo 0000:04:00.0: Successfully disabled ASPM L0s 
[161447.552467] hailo 0000:04:00.0: soft reset finished
[161447.552471] hailo 0000:04:00.0: Soft reset done
[161447.552475] hailo 0000:04:00.0: Writing file hailo/hailo8_fw.bin
[161447.599845] hailo 0000:04:00.0: File hailo/hailo8_fw.bin written successfully
[161447.599849] hailo 0000:04:00.0: Writing file hailo/hailo8_board_cfg.bin
[161447.599929] hailo 0000:04:00.0: File hailo/hailo8_board_cfg.bin written successfully
[161447.599931] hailo 0000:04:00.0: Writing file hailo/hailo8_fw_cfg.bin
[161447.599985] hailo 0000:04:00.0: File hailo/hailo8_fw_cfg.bin written successfully
[161447.689228] hailo 0000:04:00.0: NNC Firmware loaded successfully
[161447.689238] hailo 0000:04:00.0: FW loaded, took 138 ms
[161447.700933] hailo 0000:04:00.0: Probing: Added board 1e60-2864, /dev/hailo0

Il faut maintenant adapter la commande de lancement du conteneur Frigate pour qu’elle prenne en compte le nouveau périphérique /dev/hailo0, fraîchement reconnu par le système.

podman run --replace -d --name frigate --restart=unless-stopped --shm-size=256m --device /dev/hailo0:/dev/hailo0 --device /dev/dri:/dev/dri -v /etc/localtime:/etc/localtime:ro -v /home/frigate/config:/config:z -v /home/frigate/media:/media/frigate:z --tmpfs /tmp/cache:size=1000000000,mode=1777 -p 5000:5000 -p 1935:1935 -p 8554:8554 -p 8555:8555/tcp -p 8555:8555/udp -e FRIGATE_RTSP_PASSWORD='monMotdePasse' ghcr.io/blakeblackshear/frigate:stable

La commande hailortcli fw-control identify lancée à l’intérieur du conteneur Frigate retourne l’erreur 13 (Permission denied), indiquant un défaut de permission d’accès au Hailo.

frigate@localhost:~$ podman exec frigate hailortcli fw-control identify
[HailoRT] [error] CHECK failed - Failed to open device file /dev/hailo0 with error 13
[HailoRT] [error] CHECK_SUCCESS failed with status=HAILO_DRIVER_OPERATION_FAILED(36)
[HailoRT] [error] CHECK_SUCCESS failed with status=HAILO_DRIVER_OPERATION_FAILED(36)
[HailoRT] [error] CHECK_SUCCESS failed with status=HAILO_DRIVER_OPERATION_FAILED(36)
[HailoRT CLI] [error] CHECK_SUCCESS failed with status=HAILO_DRIVER_OPERATION_FAILED(36)

N’ayant pas installé le runtime HailoRT sur l’hôte, il n’est pas possible de tester la commande directement depuis celui-ci.
Cependant, les droits d’accès sur /dev/hailo0 étant corrects et le driver PCIe correctement chargé, SELinux apparaît comme le principal suspect de ce problème.

Dans le terminal utilisateur administrateur :

johann@localhost:~$ sudo ausearch -m AVC -ts recent
----
time->Mon Oct 27 09:46:00 2025
type=AVC msg=audit(1761554760.453:1201): avc:  denied  { read write } for  pid=75883 comm=&quot;hailortcli&quot; name=&quot;hailo0&quot; dev=&quot;devtmpfs&quot; ino=812 scontext=system_u:system_r:container_t:s0:c132,c197 tcontext=system_u:object_r:device_t:s0 tclass=chr_file permissive=0

Les logs SELinux indique bien un soucis. Je désactive temporairement SELinux :

johann@localhost:~$ getenforce
Enforcing
johann@localhost:~$ sudo setenforce 0
johann@localhost:~$ getenforce
Permissive

Et dans le terminal utilisateur frigate, on relance la commande :

frigate@localhost:~$ podman exec frigate hailortcli fw-control identify
Executing on device: 0000:04:00.0
Identifying board
Control Protocol Version: 2
Firmware Version: 4.21.0 (release,app,extended context switch buffer)
Logger Version: 0
Board Name: Hailo-8
Device Architecture: HAILO8L
Serial Number: HLDDxxxxxxxxxxxx
Part Number: HMxxxxxxxxxx
Product Name: HAILO-8L AI ACC M.2 B+M KEY MODULE EXT TMP

Bingo !!! mais ne pas oublier de rétablir le mode « Enforcing » de SELinux avec sudo setenforce 1

Je ne suis clairement pas un expert de SELinux, loin de là. Heureusement, ChatGPT m’a traduit tout ça dans un langage enfin compréhensible par des êtres humains. 😅

johann@localhost:~$ ls -Z /dev/hailo0
system_u:object_r:device_t:s0 /dev/hailo0

Tout comme Gemini :
Gemini : Ce message de refus (AVC denied) de SELinux est très précis et indique clairement que le contexte de sécurité de votre conteneur (container_t) n’a pas la permission d’accéder en lecture et en écriture (read write) au périphérique Hailo (hailo0), qui a le contexte de périphérique générique (device_t).

5. Hailo 8L / SELinux

Après plusieurs échanges avec les IA et quelques tests, deux solutions se dégagent. Pour ma part, j’ai mis en œuvre avec succès la seconde, basée sur la création d’une politique SELinux spécifique car c’est la solution préconisée par Cockpit dans le menu SELinux de l’interface.

1️⃣ Solution semanage / restorecon

– sudo semanage fcontext -a -t container_file_t ’/dev/hailo0’

Ceci établit une règle persistante (une "policy file context") dans la base de données de SELinux.
La règle dit : "Chaque fois que le système rencontre le chemin /dev/hailo0, il doit lui attribuer le type container_file_t."

– sudo restorecon -v /dev/hailo0 :

Ceci est la commande d’exécution. Elle applique immédiatement la règle définie par semanage fcontext.
Elle change le contexte de sécurité actuel du fichier /dev/hailo0 en container_file_t.

La problématique de cette approche est qu’elle autorise tous les conteneurs à faire toutes les opérations (lecture/écriture, etc.) sur /dev/hailo0.

Pour atténuer cette problématique, on peut s’assurer que le périphérique /dev/hailo0 appartient à un groupe spécifique (par exemple, le groupe hailo). L’utilisateur exécutant le conteneur Frigate (en mode rootless) doit ensuite être ajouté à ce même groupe pour hériter des droits d’accès."

Le fichier « /etc/udev/rules.d/51-hailo-udev.rules » serait modifier pour contenir SUBSYSTEM=='hailo_chardev', GROUP='hailo', MODE='0660'

2️⃣ Solution audit2allow

Installation des Outils Nécessaires
sudo dnf install policycoreutils-devel -y
Identification des refus dans les logs
sudo ausearch -m avc | grep hailo
Toutes les tentatives infructueuses devraient s’afficher
Génération d’une règle de politique SELinux
sudo ausearch -m avc -c hailortcli | audit2allow -M hailo
👉 Cela crée deux fichiers dans ton répertoire courant :
- hailo.te → le texte de la règle SELinux
- hailo.pp → le module compilé prêt à être chargé

module hailo 1.0;

require {
        type container_t;
        type device_t;
        class chr_file { ioctl open read write };
}

#============= container_t ==============

#!!!! This avc can be allowed using the boolean 'container_use_devices'
allow container_t device_t:chr_file { ioctl read write };

#!!!! This avc is allowed in the current policy
allow container_t device_t:chr_file open;

Chargement du module de politique hailo
sudo semodule -i hailo.pp
Cette règle devient persistante entre les redémarrages.
Vérification Finale
sudo semodule -l | grep hailo
Lancez à nouveau dans le terminal utilisateur standard,la commande qui échouait :
podman exec -it frigate hailortcli fw-control identify

Si la politique a été correctement appliquée, la commande devrait maintenant réussir à s’exécuter, et vous verrez les détails de votre carte Hailo-8L. Votre système reste en mode enforcing, garantissant la sécurité pour toutes les autres opérations non liées à votre carte.

5. Podman Frigate / Systemd

Deux approches sont possibles :

Utiliser Quadlet, la méthode recommandée et native pour l’intégration de Podman avec systemd,
ou Employer la méthode dite « classique », désormais considérée comme obsolète mais toujours parfaitement fonctionnelle, via la commande suivante :
podman generate systemd --name frigate --files --new

J’ai mis en oeuvre pour ma part la deuxième solution, voici mon mode opératoire
Dans un terminal de l’utilisateur standard Frigate :

– Lancer le container frigate avec ces options définitives :

podman run --replace -d --name frigate --restart=unless-stopped --shm-size=256m --device /dev/hailo0:/dev/hailo0 --device /dev/dri:/dev/dri -v /etc/localtime:/etc/localtime:ro -v /home/frigate/config:/config:z -v /home/frigate/media:/media/frigate:z --tmpfs /tmp/cache:size=1000000000,mode=1777 -p 5000:5000 -p 1935:1935 -p 8554:8554 -p 8555:8555/tcp -p 8555:8555/udp -e FRIGATE_RTSP_PASSWORD='motDePasse' ghcr.io/blakeblackshear/frigate:stable

– S’assurer du bon fonctionnement de frigate, avec une attention particulière pour l’accélération GPU et NPU Hailo. Les « journaux système » et les « Incateurs systèmes » du menu permettent d’établir rapidement un diagnostique.

– Générer le fichier container-frigate.service avec la commande
podman generate systemd --name frigate --files --new

– Valider le contenu du container-frigate.service : cat container-frigate.service et modifier au besoin

– Créer le répertoire /home/frigate/.config/systemd/user et copier/déplacer le fichier container-frigate.service dans ce répertoire

mkdir -p ~/.config/systemd/user
cp ./container-frigate.service ~/.config/systemd/user

– Informer systemd d’une modification des fichiers de configuration : systemctl --user daemon-reload

– Activer le service container frigate :
systemctl --user enable --now container-frigate.service

Dans un terminal de l’utilisateur administrateur :
sudo loginctl enable-linger frigate

Bien que n’ayant pas mis en oeuvre la première solution (Quadlet), le site linuxtricks propose un éclairage très pertinent sur la méthode.

6. Conclusion

Je ne prétends pas maîtriser tous les aspects de Podman et systemd, et il est possible que certaines étapes puissent être améliorées.
Quoi qu’il en soit, mon installation Frigate est opérationnelle, et si ce guide peut aider ne serait-ce qu’un peu, l’objectif est atteint.

Après, on ve na pas se mentir, cela est bien plus complexe que la solution actuelle Proxmox + LXC + Docker.