Illustration abstraite représentant une série de cercles bleus concentriques centrés vers le bas, d'où partent des lignes jaunes et orange qui rayonnent en éventail à partir du centre. Le fond est blanc et épuré, évoquant une impression d'organisation précise qui rappelle la « mise en place » par son agencement délibéré.

Cloudflare Tunnel : pourquoi l’utiliser, comment il fonctionne et le mettre en place

par · Lecture: 22 minutes

Cloudflare Tunnel permet de publier un site, une API ou une application interne sans ouvrir de port entrant sur le serveur. Le connecteur cloudflared établit lui-même une liaison sortante vers Cloudflare, qui devient le point d’entrée public et sécurisé du service.

Qu’est-ce qu’un Cloudflare Tunnel ?

Un Cloudflare Tunnel crée une liaison sécurisée entre un serveur privé et le réseau mondial de Cloudflare.

Traditionnellement, publier une application impose plusieurs opérations :

  • disposer d’une adresse IP publique ;
  • ouvrir les ports 80 ou 443 ;
  • configurer une redirection NAT ;
  • exposer un reverse proxy ;
  • gérer les certificats TLS ;
  • protéger directement l’adresse IP du serveur.

Cloudflare Tunnel inverse cette logique.

Le serveur exécute un petit programme nommé cloudflared. Celui-ci ouvre des connexions sortantes vers Cloudflare. Le pare-feu n’accepte donc aucune connexion entrante destinée au tunnel.

Lorsqu’un visiteur ouvre l’application, Cloudflare reçoit la requête. Son réseau la transmet ensuite à cloudflared, qui la relaie vers le service local concerné.

Cloudflare Tunnel peut publier des serveurs HTTP, des applications HTTPS, des services SSH, des bureaux RDP, des sockets Unix et différents services TCP. Aucun routage IP public n’est nécessaire sur le serveur d’origine.

Lire Cloudflare Tunnel : pourquoi l’utiliser, comment il fonctionne et le mettre en place

Linux : résoudre l'erreur "failed to execute /lib/udev/socket:@/org/freedesktop/hal/udev_event" photo

Linux : corriger l’erreur « cannot open pixbuf loader module file »

par · Lecture: 7 minutes

Lors d’une mise à jour Linux, du lancement d’une application GTK, ou de l’ouverture d’une image, vous pouvez tomber sur cette erreur :

(gtk-update-icon-cache-3.0:12015): GdkPixbuf-WARNING **:
Cannot open pixbuf loader module file
'/usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders.cache':
No such file or directory

This likely means that your installation is broken.
Try running the command
  gdk-pixbuf-query-loaders > /usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders.cache
to make things work again for the time being.Langage du code : JavaScript (javascript)

Le message peut apparaître dans le terminal pendant un apt upgrade, lors du lancement d’un logiciel graphique, ou quand une application ne parvient plus à ouvrir certains formats d’images.

Dans la plupart des cas, le problème vient du cache des loaders GdkPixbuf. Ce cache indique à GTK quelles bibliothèques utiliser pour charger les formats d’images : PNG, JPEG, WebP, SVG, TIFF, AVIF selon les paquets installés, etc.

La bonne nouvelle : ce cache se régénère. Et, dans beaucoup de cas, une seule commande suffit.

À quoi sert GdkPixbuf ?

GdkPixbuf est une bibliothèque utilisée par les applications GTK pour charger et manipuler des images. Elle ne contient pas forcément tous les chargeurs d’images en dur : elle s’appuie sur des modules, appelés loaders, pour gérer différents formats.

La commande gdk-pixbuf-query-loaders collecte les informations sur ces modules et écrit le résultat dans le fichier de cache par défaut, ou sur la sortie standard selon son mode d’appel. La page de manuel Debian décrit précisément ce rôle : collecter les informations sur les modules chargeables de GdkPixbuf et les écrire dans l’emplacement de cache prévu. :contentReference[oaicite:0]{index=0}

Si ce fichier loaders.cache manque, est vide, pointe vers de mauvais chemins, ou correspond à une autre architecture, les applications GTK peuvent ne plus savoir charger certains formats d’images.

Lire Linux : corriger l’erreur « cannot open pixbuf loader module file »

Encoder une vidéo H.264 : utiliser qt-faststart pour la lecture progressive photo

FFmpeg : optimiser une vidéo MP4 pour la lecture progressive

par · Lecture: 9 minutes

Lorsque l’on intègre une vidéo MP4 dans une page web, on s’attend à ce qu’elle démarre rapidement. Pourtant, il arrive qu’un lecteur HTML5 attende le téléchargement complet du fichier avant de lancer la lecture.

Le problème ne vient pas forcément du navigateur, ni du lecteur, ni même du serveur. Très souvent, il vient de la structure interne du fichier MP4.

Pour qu’une vidéo MP4 puisse être lue progressivement, les métadonnées nécessaires à la lecture doivent se trouver au début du fichier. Dans un MP4, ces métadonnées sont stockées dans ce que l’on appelle le moov atom. Si ce bloc se trouve à la fin du fichier, le navigateur doit parfois attendre d’avoir téléchargé toute la vidéo avant de commencer la lecture.

La solution moderne consiste à optimiser le fichier MP4 avec FFmpeg et l’option -movflags +faststart.

Pourquoi une vidéo MP4 ne démarre pas immédiatement ?

Un fichier MP4 contient plusieurs blocs internes, appelés atoms ou boxes. Parmi eux, le bloc moov contient les métadonnées nécessaires au lecteur : pistes audio et vidéo, durées, index, informations de synchronisation, etc.

Si le bloc moov est placé à la fin du fichier, le navigateur ou le lecteur doit atteindre cette partie avant de savoir comment lire correctement la vidéo. Sur un fichier local, ce n’est pas très grave. Sur le web, cela peut provoquer une attente frustrante.

Pour une vidéo web classique, on veut donc placer le moov atom au début du fichier. Ainsi, le navigateur peut lire les métadonnées immédiatement, puis commencer la lecture pendant que le reste de la vidéo continue de se télécharger.

C’est ce que l’on appelle souvent la lecture progressive. Ce n’est pas du streaming adaptatif comme HLS ou DASH, mais c’est largement suffisant pour beaucoup de vidéos MP4 intégrées dans une page web.

Lire FFmpeg : optimiser une vidéo MP4 pour la lecture progressive

Articles suivants →