Auteur/autrice : Victor

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.

Une histoire de gamma

Depuis un moment déjà, mes écrans avaient pris une teinte rouge très prononcée et les textes de couleurs sombres, en particulier de couleur bleu foncé, été devenu difficile à distinguer. En changeant de système d’exploitation, ou en branchant un autre ordinateur: pas de problème d’affichage de couleur. Ce n’était donc pas un début de vieillissement des écrans, comme j’avais pu le penser par instant. Seul Arch Linux était concerné.

Rien à signaler du côté de redshift, qui ne semblait pas responsable, bien qu’ajoutant un petit effet rouge supplémentaire. Après plusieurs tentatives infructueuses, j’avais fini par m’accommoder de cette balance de couleur plus que douteuse. Et ce n’est que très récemment que j’ai trouvé les éléments permettant de remonter à la source du problème.

Je suis donc allé explorer la configuration de mes écrans du côté de xrandr avec la commande suivante:

xrandr --verbose

Je parcours les lignes, ne voyant rien de particulier, quand tout à coup, je tombe sur la ligne:

Gamma:      1.6:2.5:4.0

Je cherche donc comment rétablir les gammas à des valeurs « neutres ». Toujours avec xrandr et en spécifiant la source concernée avec l’option output, on pourra utiliser l’option dédiée, à savoir: gamma. A noter que j’ai également constaté une remise à plat des gammas avec l’option brightness.

xrandr --output DVI-D-0 --gamma 1:1:1
xrandr --output DP-1 --brightness 1.0

Ce ne fut malheureusement pas suffisant. Au démarrage suivant, réapparition du problème. Après de nouvelles recherches, j’ai fini par trouver que le fichier de configuration pour ma disposition d’ écran par défaut dans autorandr contenait la ligne:

gamma 0.625:0.4:0.25

Après avoir modifié les trois valeurs à 1.0, j’ai donc retrouvé des couleurs correctes et un affichage satisfaisant. Bref, une bête erreur de configuration, qui devait remonter à l’installation et à la première configuration d’autorandr.

[macOS] Elasticsearch – Unrecognized VM option ‘UseConcMarkSweepGC’

Sur mon ordinateur de travail, après une mise à jour avec brew update suivi d’un brew upgrade, il m’était devenu impossible de démarrer elasticsearch. L’exécution se terminait systématiquement en erreur avec le message : Unrecognized VM option 'UseConcMarkSweepGC'. Après quelques recherches, voici la solution qui a permis le démarrage du programme sans erreur.

Éditer le fichier /usr/local/etc/elasticsearch/jvm.options et commenter les lignes suivantes :

-XX:+UseConcMarkSweepGC
-XX:CMSInitiatingOccupancyFraction=75
-XX:+UseCMSInitiatingOccupancyOnly

Pour remplacer ces trois lignes, ajouter les lignes suivantes :

8-13:-XX:+UseConcMarkSweepGC
8-13:-XX:CMSInitiatingOccupancyFraction=75
8-13:-XX:+UseCMSInitiatingOccupancyOnly

elasticsearch devrait désormais démarrer correctement.

Adieu Netgear… Ou pas.

Avant de commencer

Petite histoire de mise à jour Netgear imposant la création d’un compte utilisateur pour l’utilisation de certains des produits.

Ou comment éviter de dire n’importe quoi, en procédant à quelques vérifications.

Adieu Netgear

Pour la gestion de mon réseau, j’avais fait le choix de m’équiper avec de l’équipement de la marque Netgear, switchs et routeurs. Envisageant de faire l’acquisition d’une switch 24 ports une bonne fois pour toutes, j’envisageais d’en choisir un de la même marque que les autres, n’ayant pas eu de problème avec les précédents.

À compter d’aujourd’hui, il y a peu de chance que ce soit encore le cas à l’avenir. En effet, avec la version 1.0.5.4 de son firmware pour le modèle de switch GC108P / GC108PP, il est nécessaire de créer un compte Netgear Cloud pour avoir accès à toutes les fonctionnalités de l’appareil en termes de configuration. Netgear, dans un élan de bonté, permet néanmoins 3 connexions sans compte. Par contre, difficile de savoir si cette obligation s’étendra à terme à tous les appareils de la marque ou non, mais une l’ajout d’une telle obligation est un signal d’alerte à considérer.

Donc en résumer, pour configurer un produit pouvant fonctionner sur un réseau interne non connecté à internet, Netgear me force à m’inscrire et utiliser un compte utilisateur chez eux. Merci, mais non merci. J’ajoute donc Netgear à la liste des marques dont je n’achèterais pas de produits à l’avenir.

Je vais aller regarder ce que propose Mikrotik, dont j’ai entendu de bons retours. Pour la partie routeur, j’utilise du matériel Netgear, mais avec un firmware alternatif; je suis donc tranquille de ce côté-là pour l’instant (sinon, je m’orienterai vers Mikrotik ou un Turris Omnia).

Adieu Netgear !

La note de mise à jour Netgear incriminée.
La discussion liée sur HackerNews.

Ou pas

Après avoir écrit ces quelques lignes, et avant de publier, je me suis forcé à effectuer quelques recherches supplémentaires. Il semble donc que ces limitations de connexion soient propres à une gamme de switchs vendus spécifiquement avec du « Cloud Management » et souvent nommé « Smart Pro » dans la gamme de produits Netgear.

Une recherche google avec les bons filtres permet d’isoler la liste des produits concernés, liste qui reste limitée. Faut-il en déduire que le fabricant déploiera cette obligation sur l’ensemble de ses produits ? L’avenir nous le dira.

Il n’y a donc finalement pas d’obligation à éviter Netgear, mais seulement la nécessité de se renseigner correctement sur le produit dont on souhaite faire l’acquisition, afin de vérifier que celui-ci conviendra pour l’usage que nous souhaitons en faire.
Comme souvent.

Vérification des DNS

Récemment dans mon quotidien de développeur, je me suis retrouvé confronté à la question de la validité de la zone DNS, ou, pour le formuler plus simplement, à la question : comment vérifier le contenu d’une zone DNS ?

J’avais en effet transmis des informations à un tiers pour la configuration de la zone DNS d’un domaine, mais après vérification capture d’écran à l’appui : rien à faire. La validation du domaine restait en erreur du côté de Firebase. Et comme parfois avec Google, aucune information de débogage. Seul un laconique « Impossible de valider le domaine » est présent dans l’interface.

N’ayant pas accès aux interfaces de gestion du domaine, j’ai donc cherché à consulter le contenu de la zone DNS d’une autre manière et je me suis donc tourné vers nslookup. Avec en particulier les commandes telles que :

nslookup <domaine>
nslookup -type=txt <domaine>
nslookup -type=cname <domaine>

L’exécution de ces commandes, avec quelques variations pour vérifier différents sous-domaines, m’a permis de constater que les entrées configurées ne figurent pas dans la zone DNS, bien que présent dans l’interface. Je postule donc que la nouvelle zone DNS est sauvegardée, mais non publiée. Les vérifications sont en cours pour vérifier cette hypothèse. Si ce n’est pas le cas, la recherche continuera, et j’aurais au moins découvert un outil bien pratique, faute d’avoir trouvé l’élément bloquant.