Depuis quelques jours, mes interactions entre pushbullet et jeedom ne fonctionnent plus que dans un seul sens : Jeedom peut envoyer des notifs vers mon smartphone.
Mais plus l’inverse (alors que cela fonctionnait il y a encore peu de temps).
En regardant les logs de pushbullet dans Jeedom, je m’aperçois d’un problème avec le daemon :

Le plugin Pushbullet pour Jeedom n’est plus maintenue depuis plusieurs années mais un contributeur sur le GitHub pointe directement le doigt sur le problème : le problème est lié au certificat racine DST Root CA X3 qui a expiré fin septembre 2021.
Le contributeur donne la solution : il faut remplacer le certificat racine dans l’installation de pushbullet.
Let’s go !

On récupère le nouveau certificat racine :

Tout d’abord, je récupères le nouveau certificat racine qui va remplacer l’ancien, en allant sur https://curl.se/docs/caextract.html et en téléchargeant la dernière extraction en date :

Ensuite, je vais déposer ce fichier « cacert.pem » sur mon Jeedom (en fait dans la DB10 qui sert d’OS).
Pour cela, j’utilise WinSCP pour transférer en SSH.

Je dispose déjà d’un répertoire « /home/jeremy » pour mes scripts perso donc je déposes le fichier cacert.pem ici.

C’était une belle soirée de juillet 2021, je regardais un enregistrement sur le Freebox Player (Revolution) et tout d’un coup plus rien, écran noir, le player s’est éteint.
Je me dis « ok, un bug », je redémarre le player avec la télécommande : il redémarre, je relance mon enregistrement… puis 15 minutes plus tard, rebelotte.
Sur le coup, j’attribue cela à la MAJ du firmware qu’il y a eu quelques heures avant. Je le redémarre avec la télécommande et 10 min plus tard, il se re-éteint.
Ok, je vais pour lui faire un reboot électrique (on sait jamais) et je m’aperçois que le player est brulant. ah ?
Je le redémarre, vais dans les informations systèmes du player et constate une température de 99°C pour le CPU… et très vite, mon regard dérive sur la vitesse du ventilateur : 0 RPM, il ne tourne pas !

Ok, je le débranches électriquement, m’en vais à d’autres occupation puis 15 min plus tard, je le rebranches : surprise, le ventilateur que l’on entend habituellement au démarrage du player… ne fait aucun bruit aujourd’hui !
Petit tour dans les infos sys : toujours à 0 RPM.
Le problème est tout vu, le ventilateur est en souffrance, je démontes le boitier !

Ayant une vieille machine/serveur disposant de 5 ports réseaux gigabit, j’ai voulu la recycler en tant que routeur Mikrotik pour mon homelab.
Après différentes tentatives qui ont échoué (iso sur clé USB // netinstall avec SSD branché en esclave // netinstall en PXE), j’ai réussi à installer RouterOS (le système d’exploitation développé par Mikrotik) avec la méthode détaillée ci-dessous.

Tout d’abord, on récupère le package pour l’installation en x86 sur le site de Mikrotik : Il faut prendre « Extra Packages » dans « x86 ».

NB : Bien sûr, si vous pouvez faire l’installation en netinstall, il faudra choisir « Main Package ». Et si vous faites l’installation via une clé USB, il faut choisir « CD Image ». Perso, je n’ai pas réussi d’où ce tuto/mémo.

On dézippe le contenu du fichier téléchargé (dans mon cas « install-image-6.48.2.zip »).
Ensuite on branche le disque dur sur un PC Windows (dans mon cas, j’utilise un SSD de 60Go) et on installe le logiciel Win32DiskImager.
On lance Win32DiskImager et on sélectionne le fichier dézippé « install-image-6.48.2.img » et on sélectionne la lettre du lecteur où l’on veut installer RouterOS (« F: » dans mon cas) puis on clique sur « Write ».

Préambule : Retour d’expérience sur l’installation d’un ESXi 6.7 sur un shuttle XS35V4.
Lors de l’installation, un message d’erreur a nécessité un contournement.

Action !

Tout d’abord, je lance l’installation d’ESXi 6.7.0 (avec une version personnalisée pour d’autres matériels mais en fait il n’y en a pas besoin dans notre cas) :

L’installation se lance et semble bien se passer :

Mais avant d’arriver à la configuration de l’installateur, le message d’erreur suivant apparait sur le XS35V4 : « Relocating modules and starting up the kernel »

J’utilise depuis quelques années un PDU (Power Distribution Unit) pour pouvoir couper l’électricité sur un matériel électrique quand celui-ci est récalcitrant. Jusqu’à présent, il fallait que je me connecte à l’interface web du PDU et que je clique sur « on » ou « off » ou « reboot » de la prise que je voulais piloter à distance. Ce qui est un peu contraignant quand on n’a pas un PC à portée de main (sur smartphone, l’interface est horrible car pas adaptative). Et puis à l’occasion d’une coupure d’Internet (difficile de télétravailler) j’ai lu la doc du PDU… ce que je n’avais pas fait jusqu’à ce jour. Et BAM, je découvre qu’on peut piloter les prises à distance via des commandes telnet.
Ma box domotique étant parfaite pour passer les ordres (je peux la contacter par msg privée, SMS, ou autre appel spécifique), c’est elle qui enverra les commandes telnet au PDU.

Installer Expect sur l’hôte JEEDOM :

On se connecte en SSH à la distrib qui accueille Jeedom (testé dans Debian 9 et 10), on passe en root et on fait un « apt install expect » :

Création du fichier de script Expect :

On créé le fichier qui contiendra les commandes Expect et on lui attribue les droits habituels d’exécution :

On saisit les lignes de commandes dans le fichier nouvellement créé :

#!/usr/bin/expect
spawn telnet 192.168.xx.xx
expect "Login:" { send "teladmin\r" }
expect "Password:" { send "telpwd\r" }
sleep 1
send "sw o01 on imme\r"
sleep 1
send  "QUIT\r"