Ingénieur en informatique de formation et de métier, j’administre ce serveur et son domaine et privilégie l'utilisation de logiciels libres au quotidien. Je construis progressivement mon "cloud" personnel service après service pour conserver un certain contrôle sur mes données numériques.
Il y a 5 ans jour pour jour, je publiais le premier article d’Unicoda.
Quelques années ont passées depuis. 193 articles. 26 commentaires. Notre petit bout d’Internet vit sa vie. Nous publions à notre rythme, avec parfois alternance de période plus calme en termes d’écriture.
En 5 ans, l’infrastructure a bien changé, hébergement simple pour commencer, serveur mutualisé et enfin serveur dédié. Chaque étape amenant ses propres défis et son lot de connaissances à acquérir.
Unicoda est une aventure.
Une aventure qui n’en ait qu’à ces balbutiements.
Où nous mènera-t-elle, nul ne le sait.
Mais je délire, je m’égare.
Ami lecteur, visiteur d’un soir, merci pour ce passage dont seuls subsisteront quelques octets, au fin fond d’un fichier de log.
Il se fait tard.
Bonne nuit.
Bon vent.
Et à bientôt je l’espère.
Dans un article précédent, j’évoquais rapidement le problème des requêtes vers des sites externes pour charger des contenus tels que polices d’écriture, scripts JS, et autres. Je faisais donc remarquer que l’intégration d’une vidéo Youtube dans un article rentrait dans ce cas, et qu’il ne semblait pas y avoir beaucoup de solutions.
Après y avoir réfléchi plusieurs fois depuis, j’ai trouvé une solution qui me convient. Plutôt que d’intégrer toute la vidéo via le mécanisme automatique de WordPress et ainsi obliger les visiteurs à récupérer du script JavaScript sur les serveurs Youtube, j’ai décidé de remplacer le lecteur intégré par une simple image comportant un lien vers la vidéo que je souhaite partager. Ainsi, plus de requête vers les serveurs Youtube de Google, je récupère l’image de la vidéo et la stocke directement sur mon serveur. Ajoutons à cela que si le visiteur souhaite visionner la vidéo, celui-ci sera donc rediriger vers Youtube, mais si celui-ci a bloqué la transmission de l’information referer (le site d’origine sur lequel vous avez cliqué sur le lien), Youtube ne sera pas en mesure de faire le lien entre votre lecture de l’article intégrant la vidéo et le visionnage de celle-ci.
Passons à la pratique. Si je désire intégrer à cet article le clip pour Towers de Bon Iver, découvert par hasard l’an dernier et dont l’url est :
https://www.youtube.com/watch?v=t60roHM1t7o
À l’aide de la console Firefox, j’ai déterminé l’url à appeler pour récupérer l’image de présentation d’une vidéo Youtube, à savoir :
Où <id-vidéo> correspond à l’identifiant Youtube de la vidéo présent dans le paramètre v de l’url de la vidéo, à savoir ici t60roHM1t7o, ce qui nous donne donc :
Si ce lien ne permet pas de récupérer la miniature de la vidéo, on peut se tourner vers :
https://i.ytimg.com/vi/<id-vidéo>/hqdefault.jpg
Illustration avec la miniature du court métrage Sintel de la Blender Foundation :
https://i.ytimg.com/vi/eRsGyueVLvQ/hqdefault.jpg
Je récupère donc l’image, l’ajoute à la bibliothèque de médias WordPress et l’insère dans l’article. Après avoir trouvé une taille d’affichage correcte, j’édite les paramètres WordPress de l’image dans l’article et en particulier le champ « Légende » qui contiendra « Lien vers la vidéo « Bon Iver – Towers » ». Je modifie également le champ « Lier à », sélectionne « Lien personnalisé » et ajoute dans le champ qui apparaît le lien vers la vidéo. Enfin, je coche « Ouvrir le lien dans un nouvel onglet ». Et voici le résultat :
Lien vers la vidéo « Bon Iver – Towers »
De cette façon, j’évite qu’un visiteur affichant la page soit forcé de charger des scripts en provenance des serveurs Youtube de Google. Seul les lecteurs souhaitant découvrir le contenu de la vidéo pourront alors cliquer sur le lien via l’image. Je laisse maintenant ceux qui le souhaitent faire l’essai du système; bonne découverte musicale !
J’utilise PCManFM comme explorateur de fichiers visuel. La semaine dernière, je me suis intéressé à l’affichage des miniatures dans l’explorateur, élément cosmétique manquant jusqu’à présent. Pour les images, c’est très simple, il suffit d’installer tumbler.
pacman -S tumbler
Du coup, j’en ai profiter pour ajouter la même chose pour les vidéos avec ffmpegthumbnailer.
pacman -S ffmpegthumbnailer
Ce n’est pas grand chose, mais ça apporte un peu de diversité dans l’affichage des dossiers d’images et de vidéos.
Dernièrement, j’ai rencontré un problème à la mise à jour d’un ordinateur sous Arch. L’erreur indiquait: « la préparation de la transaction a échoué (paquet invalide ou corrompu) ».
$ sudo pacman -Syu
:: Synchronisation des bases de données de paquets...
core est à jour
extra est à jour
community est à jour
:: Début de la mise à jour complète du système...
erreur : l’ouverture du fichier /var/lib/pacman/local/blender-17:2.78-1/desc a échoué : Aucun fichier ou dossier de ce type
résolution des dépendances...
recherche des conflits entre paquets...
avertissement : les métadonnées pour le paquet blender-17:2.78-1 n’ont pas pu être totalement chargées.
erreur : la préparation de la transaction a échoué (paquet invalide ou corrompu)
La première étape pour que Pacman accepte d’effectuer la mise à jour du système consiste à retirer le paquet posant problème, ici blender.
sudo pacman -R blender
Une fois le paquet retiré, on peut procéder à la mise à jour.
sudo pacman -Syu
Ou pas, puisque j’obtiens cette fois des erreurs de conflits de fichiers :
erreur : la validation de la transaction a échoué (conflit de fichiers)
ttf-dejavu : /etc/fonts/conf.d/20-unhint-small-dejavu-sans-mono.conf est déjà présent dans le système de fichiers
ttf-dejavu : /etc/fonts/conf.d/20-unhint-small-dejavu-sans.conf est déjà présent dans le système de fichiers
ttf-dejavu : /etc/fonts/conf.d/20-unhint-small-dejavu-serif.conf est déjà présent dans le système de fichiers
ttf-dejavu : /etc/fonts/conf.d/57-dejavu-sans-mono.conf est déjà présent dans le système de fichiers
ttf-dejavu : /etc/fonts/conf.d/57-dejavu-sans.conf est déjà présent dans le système de fichiers
ttf-dejavu : /etc/fonts/conf.d/57-dejavu-serif.conf est déjà présent dans le système de fichiers
Des erreurs se sont produites, aucun paquet n’a été mis à jour.
Dans ce cas précis, la procédure à suivre consiste à vérifier pour chaque fichier, si celui-ci est utilisé par l’un des paquets du système.
Une fois assuré que le fichier est inutilisé, on le renomme pour en conserver un exemplaire, au cas où. D’après la documentation, celui-ci sera nettoyer lors de la mise à jour.
Une fois ces opérations effectuées pour chacun des fichiers posant problème, on peux relancer à nouveau le processus de mise à jour.
sudo pacman -Syu
Cette fois, les paquets sont mis à jour correctement, tant mieux! En me basant sur ce que j’ai lu, il semble que l’erreur « paquet invalide ou corrompu » apparaisse dans différents cas de figure. Si l’erreur devait réapparaître, il n’est donc pas exclu de devoir trouver une autre solution pour la résoudre.
Pour bien commencer l’année 2017, j’ai décidé de remettre le nez dans la configuration Apache du site. Lorsque j’avais installé WordPress pour créer Unicoda en 2012, j’avais renseigné les deux paramètres « Adresse web de WordPress (URL) » et « Adresse web du site (URL) » dans les réglages généraux avec « http://www.unicoda.com ». Du côté de la conf Apache, j’avais indiqué que le serveur répondrai avec le contenu du WordPress pour unicoda.com et www.unicoda.com bien entendu.
Un beau jour, j’ai fini par remarquer qu’en tentant d’accéder au site via unicoda.com, j’étais redirigé vers www.unicoda.com. Cette redirection étant effectuée par WordPress lorsque celui-ci constate que l’url ne correspond pas à l’adresse configurée. Autant vous dire que celle-ci n’était pas des plus rapides. J’ai donc décidé en ce début d’année d’améliorer le processus de redirection en l’effectuant directement au niveau d’Apache.
En modifiant mes fichiers de configuration, j’ai donc ajouté une redirection de unicoda.com vers www.unicoda.com sur les deux protocoles http et https. Désormais, j’ai donc un virtualhost spécifique pour unicoda.com, en lieu et place d’une déclaration comme « ServerAlias » de www.unicoda.com dans un seul fichier de configuration. Le résultat est sans appel puisque la redirection prend désormais 100 ms environ alors qu’elle était de l’ordre de la seconde avant. Si je me base sur un test effectué via gtmetrix, on passe de 2,57 s à 325 ms, presque un facteur 8 (7,9) ! Le gain en rapidité n’est donc pas négligeable.
Pour ce qui est de la redirection http, la configuration est relativement simple :
Et enfin, cerise sur le gâteau, l’opération s’est déroulé sans accro après rechargement de la nouvelle configuration par le processus Apache. En somme, c’est donc une année 2017 qui commence plutôt bien.
