Derniers articles - La taverne de John-John : Logiciel & scripts

Comment ne pas déverrouiller les HDD HGST (Cross-flash vendor-locked)

Sat, 14 Feb 2026 17:28:00 +0100

L'année dernière je suis tombé dans le rabbit hole des disques durs SAS bloqués logiciellement. Cette page résume mes aventures à tenter techniquement de les déverrouiller mais sans succès à ce jour. Tout part de l'achat de quelques disques durs 2,5 pouces SAS-2 et SAS-3 pas chers sur eBay qui sont issus d'appliances de marque NetApp, EMC ou Cisco décommissionnées.

Et s'ils ne sont pas chers c'est qu'il y a une raison. 😁

J'en ai malencontreusement pris quatre sur eBay sans savoir, sans trop me méfier, qui sont étiquetés NetApp. N'ayant jamais eu de tel matos OVER 9000 propriétaire à la maison ou au travail, comme par exemple des baies de disques EMC ou NetApp, je n'avais absolument pas connaissance de tout ce qui m'attendait. Voici les deux modèles de disques avec lesquels je suis concerné :

2x HGST HUC109090CSS600 (famille Cobra-E), dont un est décédé suite à mes essais
2x HGST HUC101890CS4204 (famille Cobra-F)

Tout va bien avec les Cobra-E mais ce n'est pas le cas avec les Cobra-F. Le disque ne fonctionne pas totalement de manière générique et correctement partout sur d'autres contrôleurs SAS d'autres marques (LSI, ServeRAID, PERC, ...). Il y donc une distinction à faire entre les firmware "custom" et les firmwares constructeur OEM, appelé "génériques" ou civils. civilian revenant souvent sur les forums spécialisés. On trouve de ces histoires à la pelle sur le net. Le sujet ne concerne pas un fabricant spécialement. La plupart ont pu faire fonctionner ces disques en l'état, tels quels, simplement en les reformatant avec une taille de secteur standard, en les passant de 520 à 512 octets, pour une utilisation en RAID logiciel du genre unRAID/TrueNAS sur une carte en mode HBA/IT.

Mais dans certains cas changer la taille de secteur à 512 octets en reformatant ne suffit pas à les rendre absolument compatible partout. Car dans mon cas souvient un autre problème de cold boot. Le blocage du disque se fait, selon moi, sur une séquence de démarrage après mise sous tension qui doit être absolument respectée (timing). Sinon à l'allumage les disques "buguent" et ne sont pas détectés correctement. Sur mon Dell PowerEdge T440, que la PERC soit en mode RAID ou HBA, c'est la même chose, la machine est bloquée au boot sur l'écran bleu, la seule solution étant de retirer les disques de la cage et de les remettre. Après cette manipulation ils fonctionnent correctement. Ce qui réclame d'être devant le serveur lors du boot : pas terrible. C'est comme si les disques attendaient une courte période de temps que le contrôleur (ou l'expander de la backplane) leur envoie quelque chose, juste après la mise en tension, sinon c'est trop tard, faut ré-appliquer une déconnexion électrique. Seulement comme la carte contrôleur et/ou la backplane elle aussi doit prendre le temps de démarrer, elle ne répond pas assez vite, ce temps est dépassé, les disques ne sont pas détectés. C'est assimilable à une race condition. C'est mon hypothèse. Même situation que cette personne : https://forums.servethehome.com/index.php?threads/hgst-netapp-sas-drives-most-of-the-time-dont-show-up-on-dell-r730xd-backplane.43001/.

Pour ceux qui auraient fait le rapprochement avec le problème de la broche 3.3V : que les disques reçoivent ce 3.3V ou pas c'est la même chose. Même avec des adaptateurs qui n'apportent pas cette 3ème tension c'est pareil. Le fil n'est pas présent, il n'y a que le 12V et 5V d'appliqués, donc ce n'est pas cela le problème.

Donc pour moi cela provient d'une modification du logiciel interne qui a été personnalisé pour un démarrage "spécifique". La solution est simple à première vue : remettre le firmware constructeur à la place, ce qui rendrait le disque conforme à son comportement d'origine. C'est là que les choses se gâtent. Si on essaye, et bien cela ne fonctionne pas. Même mettre le firmware originel du fabricant échoue. On pourrait penser que c'est quelque chose de légitime. Et bien non. C'est de la sécurité. C'est le début des investigations durant des nuits blanches de recherche et de casse tête cet été pour moi.

Les firmware d'origine

On peut les trouver sur le net, notamment sur l'espace de téléchargement du site hddguru.

La mauvaise idée : jouer avec la puce Flash

Ouais c'est facile, yaka (faukon) dessouder la SPI Winbond/Macronix du PCB, la mettre dans un programmateur et hop.

Hélas c'est une autre époque ou pour des techniques de récupération de données très spéciales. Sur les HDD modernes une partie du firmware est en effet dans la puce Flash mais une autre partie est située sur les plateaux du disque. Cette zone est appelée la SA (System Area). Elle est située dans de la zone LBA négative (LBA < 0) et pas obligatoirement de manière contiguë.

Pour garder un ensemble cohérent de firmware et éviter de bricker son HDD, il est donc bon de laisser au firmware installé le soin d'écrire les bonnes sections lui-même du nouveau firmware à la fois dans la flash et sur les plateaux si besoin. Des bouts du firmware global étant répartis de part et d'autre. Donc cette méthode barbare, on oublie.

La protection / Comprendre la logique

Il y en a comme moi qui ont essayés, ils ont eu des problèmes. 😂
Nous avons tenté des commandes à base de sg_write_buffer mais toutes échouent avec des Illegal Request comme réponse.

Déjà pourquoi ça ne fonctionne pas ? C'est simple : le firmware du HDD embarque un mécanisme interne de vérification du nouveau firmware à prendre en compte (lors d'une commande sg_write_buffer). C'est le disque dur (ou SSD) LUI-MÊME qui accepte ou refuse le fichier firmware .lod, .sed ou .bin proposé à l'implantation. Le nouveau firmware est accepté uniquement si sa signature condensée SHA256 correspond à une clé publique RSA-2048 déjà inscrite dans le firmware du HDD en place. Il faut donc être familier des principes de chiffrement asymétrique (clé publique / clé privée) et de condensât (checksums / digest).

Un disque qui embarque un firmware NetApp ne pourra être flashé qu'avec un autre firmware signé par NetApp.
Un disque qui embarque un firmware Dell ne pourra être flashé qu'avec un autre firmware signé par Dell.
Etc...

D'où le terme de "Vendor-locked" : les disques sont verrouillés et interdisent le cross-flashing, c'est à dire mettre le firmware d'un autre "vendor" (revendeur) à la place. D'où le fait aussi que les revendeurs (NetApp, Dell, EMC, Cisco,...) doivent repackager/recustomiser le firmware du fabricant (WD, HGST, Seagate...) à leurs clients lorsque le fabricant en sort un nouveau : exemple.

C'est une fonctionnalité proposée par les fabricants (WD, HGST, Seagate...) directement en usine, le firmware est personnalisé pour le client (Nom du fabricant, numéro de modèle, code PIN, clé publique RSA-2048...). Sur un HGST Ultrastar 10K900, il est facile reconnaître la provenance en lisant le numéro MLC. Il démarre toujours par CE pour Cobra-E (famille 10K900) suivi d'un 0 et enfin de 4 caractères alphanumériques (version du firmware).

Un disque NetApp aura donc un firmware noté CE0NAxx, CE0NA00, CE0NA01, CE0NA02, etc... Et cette information est apposée sur l'étiquette constructeur (valeur MLC en rouge), on peut donc en déduire que ces disques sont déjà personnalisés en sortie d'usine.

Un spécimen "civil", destiné à la revente au détail, aura un firmware générique, son MLC équivaut à CE0A5B0 sur l'étiquette de ce spécimen neuf illustré ci-dessous :

Remarque 1 : cette protection N'A RIEN A VOIR avec le chiffrage du disque en lui-même (SED) ou quelconque protection par mot de passe ATA.

Remarque 2 : Ne pas oublier que firmware contenu dans le binaire .lod n'est pas réellement 100% complet, des données variables sont propres au disque dans la Service Area et doivent le rester (calibration des têtes, listing des secteurs défectueux, numéro de série, etc... Ces données ne sont pas et ne doivent pas être mises à jour lors d'un upgrade firmware. Glossaire : https://blog.acelab.eu.com/glossary.

Comment déverrouiller un disque ? RTFM frère

Il faut passer par la case retro-ingénierie et accessoirement se palucher une tonne de documentation. Va falloir fouiner ! Certaines commandes de la norme SCSI sont publiques (T10). D'autres sont cachées (non documentées, documentation non accessible au public) que l'on appelle des VSC (Vendor Specific Commands) ou encore des VUC (Vendor Unique Commands). Elles sont ainsi spécifiques à chaque marque de disque dur, et les constructeurs peuvent faire ce qu'ils veulent avec. J'ai passé des heures à jouer avec les commandes sg_utils que ce soit coté Windows ou Linux avec mon petit PC Lenovo de test :

C'est en envoyant des commandes bien ciblées au disque qu'on arrive à le placer dans un certain état (spacial mode) qui désactivera la vérification de la signature du firmware. Une fois cette fonction désactivée, le HDD pourra ingurgiter n'importe quel firmware: OEM, HP, Dell, EMC, NetApp, etc... Et le cross-flash est donc possible. Hélas seuls des outils professionnels hors de prix peuvent faire ce cross-flash. Du genre le ACELab PC3000 ou chez MRT Lab.

The "Russian dude"

Il est surnommé tel quel par ce site (lug.mtu.edu). Son auteur est je pense assez blasé. J'en comprends la frustration.

E123 est une personne sur des forums qui propose un service de déverrouillage de ces disques à distance (via le bureau à distance de Windows). Un service monnayé contre quelques euros par disque. Ce E123 est très compétent, aucun doute là dessus. Il a dû y passer du temps, et le temps c'est de l'argent. Il ne souhaite pas partager ses secrets. Knowledge is money !

La vidéo ci-dessus est une démonstration de son service. En résumé : le disque connecté se présente comme un DKR5D, il lance un script .bat DOS "CMD" classique, qui démarre un deuxième Niagara en mode CLI (une deuxième instance de Niagara, pas celle que l'on voit à l'écran en graphique). Le script utilise Niagara pour envoyer des commandes au disque afin de le déverrouiller. C'est ici toute la magie, qui est monnayée, cachée dans ce script temporaire. Une fois ce script déroulé, dans un deuxième temps on peut injecter un autre firmware, ce qu'il va faire avec le Niagara déjà ouvert en GUI. Ce logiciel exploite derrière la commande sg_write_buffer. L'injection du nouveau firmware fonctionne. Il montre dans un troisième temps que le disque fraîchement mis à jour fonctionne bien sous le logiciel Victoria avec le nouveau firmware générique implanté. Le disque n'est plus un DKR5D mais un HITACHI générique tout en conservant le même numéro de série. Remarque : il existe une version Linux de Niagara.

Pourquoi partir dans cette direction ?

E123 a laissé quelques indices dans ce post sur le forum hddguru.

E123 :

To reflash HGST disks from one vendor to another, it is necessary to deactivate checks inside the hard drive itself, as provided by the manufacturer. Dig the code, look for keys, look for vendor commands. No free utility, let alone OEM flasher, will help in this case.

Grosso modo il faut analyser le code du firmware ARM (en dumpant les modules de la SA du disque) à la recherche de la routine qui désactivera cette vérification : ce qui signifie trouver les "clés" et des VSC à jouer. Des investigations à faire en solo quoi (hard way), comme lui a dû les faire de son coté. Mais ce n'est pas à la portée de tout le monde de bien savoir lire et décortiquer du code ARM décompilé. Je n'ai pas de licence pour le logiciel IDA. Peut-être demander à une IA ?

Le matériel nécessaire

Comme déjà dit, il faudra envoyer des commandes "sur mesure" au disque dur. Pour cela il est conseillé d'utiliser une carte HBA en mode IT (Initiator-Target). Certaines cartes comme la PERC H730P de mon Dell T440 peuvent basculer dans ce mode en jouant dans les paramètres. Sinon vous pouvez prendre une carte contrôleur SAS type LSI2008 déjà pré-flashée sur AliExpress pour quelques dizaines d'euros. Ce sont des cartes Dell, IBM/Lenovo ou HP recyclées dont le firmware d'origine a été re-flashé pour l'utiliser dans ce mode.

En gros, elle fonctionne comme un passe-plat. Les commandes SCSI transitent telles quelles de l'Initiator (hôte Linux/Windows/BSD) à la Target (disque dur) sans restriction/translation sur le chemin. Par opposition au mode RAID, qui comme son nom l'indique, embarque toute la couche de logique de gestion RAID (communications internes indépendantes entre la carte et ses disques, sans intervention de l'hôte/OS) et peut maquiller la communication. Vidéos de the-art-of-server sur Youtube :

Les logiciels nécessaires

Pour envoyer des commandes custom SCSI au disque SAS il faut passer par les outils sg_utils (paquet sg3_utils sur Linux). Pour les Windowsiens, il existe des versions exécutables pré-compilées qui font le travail même sous Windows 7.

Pour investiguer sur le plan logiciel

J'ai eu un temps utilisé un Dell Optiplex 380 mais après j'ai pris un Lenovo Edge 72. Un truc assez vieux qui accepte Windows 7 out of the box.

Dual boot Fedora 42 / Windows 7 (menu grub2 / os-prober), utilisation à distance (RDP/SSH)
Un petit script pour dumper la ROM du disque en modules (petit script de fzabkar)
Un éditeur hexadécimal
Les commandes linux de fouinage : binwalk, strings, file & vbindiff
Ghidra (explorer/désassembler/décompiler le code ARM 32bits LE du firmware et les dumps de ROM)

En aparté, pour gruger la timebomb du logiciel Niagara sous Linux. Avec Ghidra je suis parti à la recherche de la fonction qui affiche le message dans libtcluil.so. Petite trouvaille, on remarque que le logiciel essaye de détecter si on est sur le réseau d'HGST ou pas (usage en interne à l'entreprise) "onHGSTNetwork".

Pour gruger, il suffit de supprimer le test de retour de la fonction niagaraExpired. Ainsi la fonction niagaraExpired est toujours exécutée mais son résultat n'est plus pris en compte (return non exploité). Le logiciel démarre intégralement sans jamais expirer. Il me semble que j'avais tenter de gruger l'heure du PC sans succès. Avant :

Après :

Un Niagara débloqué sous Linux. Plus besoin de Windows 7.

Des documentations téléchargées du web...

Les premières tentatives, comment déverrouiller un disque ?

Au départ benoîtement, j'ai cru qu'il suffisait de lire la documentation constructeur. HGST implémente le protocole de sécurité "TCG Entreprise SCC". Ces fonctionnalités ne servent qu'aux disques dits "SED", chiffrés en interne. HGST propose deux modèles de disques, l'un chiffré (CSS601) et un autre non-chiffré (CSS600). Mes disques sont non-chiffrés. Mais en fait derrière le soft entre les deux modèles est peut-être identique ? Que ce soit un CSS600 ou 601 ce sont juste des paramètres qui changent dans le firmware. Pourquoi parler de ça ? Ce système de TCG embarque toute la logique de sécurisation globale du disque dur jusqu'au chiffrement des données sur les plateaux par zones (appelées bandes). Les données sur les plateaux sont découpées par bandes/zones et chaque zone à sa clé de chiffrement. C'est indiqué dans la documentation. HGST se sert du mécanisme TCG pour gérer l'aspect sécuritaire de deux autres fonctionnalités dont celle qui nous intéresse. Comme expliqué dans la documentation. Il est possible de désactiver cette vérification de signature de firmware. Ce qui ouvrirait la porte à notre "cross-flashing". Comme indiqué, ces fonctionnalités sont "un plus" qui sortent du cadre de la norme TCG.

En gros, il faut utiliser certaines fonctionnalités fournies par ce module TCG et aller modifier la table "Admin SP". SP pour Security Provider afin de désactiver la fameuse vérification de signature de firmware qui nous embête.

Les commandes TCG sont encapsulées via les commandes SCSI suivantes :
- SECURITY PROTOCOL IN (A2h) = IF-RECV
- SECURITY PROTOCOL OUT (B5h) = IF-SEND

Les fonctions liées à TCG sont lourdes à mettre en œuvre, il y a toute une négociation (aller-retour) à base de jeton (comID) à faire avec le disque dur avec une authentification et ça réclame un vrai programme dédié.

Il faudrait :

commencer par faire un "Level 0 discovery"
débuter une session et obtenir un comID
s'authentifier avec le MSID ou un code pin de 32 caractères
pour enfin envoyer la commande pour changer la valeur qui nous intéresse : passer Firmware_Dload_Port.PortLocked à False
à ce stade, le HDD est déverrouillé et ainsi prêt à accueillir n'importe quel firmware (civil ou non).

J'ai pu trouver sur GitHub un utilitaire génial fait en Go qui fait 95% du travail : https://github.com/open-source-firmware/go-tcg-storage/tree/main

Reste un peu à l'adapter... mais il y a un problème, il faut s'identifier auprès du disque avec le MSID ou un code PIN que l'on ne connaît pas. J'ai ressorti Ghibra à la recherche du mot de passe. Le code PIN TCG réclame que le longueur du mot de passe soit exactement de 32 caractères. Ni plus, ni moins. La longueur n'est pas variable. Sachant que le MSID par défaut est le numéro de série du disque établi sur 8 caractères répété 4 fois, donc 32 caractères. J'ai quand même trouvé du "Hello World!" dans le firmware. Hélas je n'ai pas les symboles pour tout comprendre.

Mais rien n'empêche le vendor d'avoir mis autre chose comme mot de passe. Mais hélas cette piste s'arrête là car les commandes TCG avec cet utilitaire en Go n'ont pas d'effets. La partie TCG semble complètement désactivée. Idem dans Niagara. Donc je pense que ce sont d'obscures commandes non-documentées qui gèrent cet aspect... et alors là pour les trouver... 😤🤯

La capitulation

Courant août j'ai abandonné. Trop complexe pour moi tout seul de rendre mes HGST OEM, c'est figé en l'état sur mon NAS.

J'en ai même perdu un sur les quatre durant mes essais, comme d'autres sur les forums, en bricolant partiellement les différents modules qui composent la Service Area avec sq_raw / sg_write_buffer. En octobre dernier, mr44er sur hddoracle poste de nouvelles informations issues d'une IA façon GPT, une lueur d'espoir. J'ai essayé certaines commandes qu'il a posté mais elles sont à moitié fausses. Le "special mode" je l'avais déjà tenté bien avant.

Nous sommes en février 2026 et donc je confirme que j'ai lâché l'affaire, trop de temps perdu même si j'ai appris pas mal. Comme d'autres avant moi, j'ai contacté ce fameux russe par courriel avec une petite vidéo faite en privée en anglais pour lui expliquer tout cela. Il est resté sur l'affaire des 520->512 octets et qu'après cela il n'y a pas de restrictions, que les disques fonctionnent bien en restant en firmware NetApp. Donc l'opération ne servirait à rien. Oui ça fonctionne, mais rien à propos de mon affaire de cold boot. Après une seconde demande quelques semaines plus tard, j'ai eu une réponse négative, grosso-modo ce n'est pas intéressant pour lui car je n'ai que trois disques à flasher, il en faudrait une dizaine pour que l'on parle sérieusement. Je pense qu'il traite plus en business/B2B qu'avec des simples particuliers ponctuels comme moi ça lui prendrait trop de temps. Finalement je sors la carte bleue et je me prends des SSD d'occasion Dell reconditionnés comme ça plus de problème.

Un jour peut-être on aura une solution gratuite mise en ligne publiquement. 😒
En attendant, beaucoup de ces disques iront finir leur vie en mode anticipé dans les DEEE. Merci la "sécurité".

Démon apcupsd sur onduleur vintage en SNMP

Sun, 27 Jun 2021 17:43:00 +0200

Depuis mon emménagement je n'ai pas pris le temps de bien raccorder mon onduleur informatiquement parlant sur mon "serveur" NAS 24/7. La flemme.

Cet onduleur APC Smart-UPS 1000 je l'aime bien car il a sa carte Web/SNMP qui permet de lui donner des fonctions intéressantes, autant les exploiter.

Cet UPS embarque aussi un connecteur RS-232C (attention brochage non standard) mais la carte mère Asrock H87M n'a plus ce type de port en accès direct soudé sans devoir ouvrir le PC et installer une équerre DE9. Il existe toujours un pin header sur la carte mère pour le port série.

Comme expliqué récemment, mon PC-NAS cerise est en Wi-Fi, par conséquent le port réseau (réparé à l'époque) est libre. Donc j'ai utilisé un RJ-45 direct entre l'onduleur et cerise. Il faut donc bien définir les métriques pour les interfaces réseau. Le WiFi doit être privilégié pour sortir et atteindre Internet.

Code BASH :

root@cerise:~# cat /etc/network/interfaces
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).
# The loopback network interface
auto lo
iface lo inet loopback
# The primary network interface
auto enp4s0
iface enp4s0 inet static
address 192.168.1.1
netmask 255.255.255.0
metric 2
#Wifi
auto wlxd0374511a96f
iface wlxd0374511a96f inet dhcp
        wpa-ssid X
        wpa-psk X
        #wireless-power off
        post-up iwconfig wlxd0374511a96f power off
metric 1
#Wifi
auto wlp5s0
iface wlp5s0 inet dhcp
        wpa-ssid X
        wpa-psk X
        #wireless-power off
        post-up iwconfig wlp5s0 power off
metric 0

Code BASH :

root@cerise:~# ip r
default via 192.168.0.254 dev wlp5s0
192.168.0.0/24 dev wlp5s0 proto kernel scope link src 192.168.0.12
192.168.1.0/24 dev enp4s0 proto kernel scope link src 192.168.1.1 metric 2
192.168.123.0/24 dev virbr0 proto kernel scope link src 192.168.123.1

192.168.0.0/24 pour le WiFi et internet 0.0.0.0.
192.168.1.0/24 pour l'onduleur APC (192.168.1.2).
192.168.123.0/24 pour les machines virtuelles.
Le mieux étant de passer par un navigateur internet, bon l'interface est old school hein.

Sinon en telnet :

Code BASH :

root@cerise:/var/log# telnet 192.168.1.2
Trying 192.168.1.2...
Connected to 192.168.1.2.
Escape character is '^]'.
User Name : apc
Password  : ***
American Power Conversion               Web/SNMP Management Card AOS   v3.2.6.b
(c) Copyright 2000 All Rights Reserved  Smart-UPS & Matrix-UPS APP     v3.2.6.a
-------------------------------------------------------------------------------
Name      : DUPRE Jonathan              Date    : 06/27/2021
Contact   : DUPRE Jonathan              Time    : 16:14:02
Location  : FRANCE                      Up Time : 0 Days 1 Hour 4 Minutes
Status    : P+ N+ A+                    User    : Administrator
Smart-UPS 1000 named ATELIER  : On
------- Control Console -------------------------------------------------------
     1- Device Manager
     2- Network
     3- System
     4- Logout
     <ESC>- Main Menu, <ENTER>- Refresh, <CTRL-L>- Event Log
> 1
------- Device Manager --------------------------------------------------------
     1- Smart-UPS 1000
     <ESC>- Back, <ENTER>- Refresh, <CTRL-L>- Event Log
> 1
------- Smart-UPS 1000 --------------------------------------------------------
        Status of UPS : On
        Last Transfer : Due to software command or UPSs test control.
        -----------------------------------------------------------------------
        Input Voltage    : 231.4 VAC         Operating Frequency : 50.00 Hz
        Output Voltage   : 231.4 VAC         Internal Temperature: 038.7 C
        Load Power       : 004.6 % Watts     Battery Voltage     : 27.60 VDC
        Max Line Voltage : 235.3 VAC         Battery Capacity    : 100.0 %
        Min Line Voltage : 230.1 VAC         Runtime Remaining   : 0073 min
        -----------------------------------------------------------------------
        Self-Test Result : Passed            Calibration Result  : Passed
        Self-Test Date   : 06/23/2021        Calibration Date    : 04/18/2018
     1- Control
     2- Configuration
     3- Detailed Status
     4- About UPS
     <ESC>- Back, <ENTER>- Refresh, <CTRL-L>- Event Log
> 4
------- About Smart-UPS 1000 named ATELIER  -----------------------------------
        Serial Number     : GS9920005848     Firmware Revision : 60.11.I
        Manufacture Date  : 05/12/99
        Press <ENTER> to continue...
------- Smart-UPS 1000 --------------------------------------------------------
        Status of UPS : On
        Last Transfer : Due to software command or UPSs test control.
        -----------------------------------------------------------------------
        Input Voltage    : 232.7 VAC         Operating Frequency : 50.00 Hz
        Output Voltage   : 232.7 VAC         Internal Temperature: 038.7 C
        Load Power       : 004.6 % Watts     Battery Voltage     : 27.60 VDC
        Max Line Voltage : 235.3 VAC         Battery Capacity    : 100.0 %
        Min Line Voltage : 230.1 VAC         Runtime Remaining   : 0073 min
        -----------------------------------------------------------------------
        Self-Test Result : Passed            Calibration Result  : Passed
        Self-Test Date   : 06/23/2021        Calibration Date    : 04/18/2018
     1- Control
     2- Configuration
     3- Detailed Status
     4- About UPS
     <ESC>- Back, <ENTER>- Refresh, <CTRL-L>- Event Log
> Connection closed by foreign host.

Sinon installer un petit reverse proxy, le but étant de taper un port particulier pour atteindre directement l'onduleur en web :

Code BASH :

root@cerise:/etc/apache2/sites-available# cat 007-apcups.conf
Listen 8082
<VirtualHost *:8082>
    ProxyPreserveHost On
    ProxyPass / http://192.168.1.2:80/
    ProxyPassReverse / http://192.168.1.2:80/
VirtualHost>

Reste à installer le paquet apcupsd intégré à Debian/Ubuntu.

Code BASH :

apt install apcpusd

Il faut ensuite modifier le fichier apcupsd.conf. Par défaut il est configuré pour de l'USB et le démon passe en zombie.
Pour ma part j'ai choisi le mode SNMP, il faut donc mettre les bonnes valeurs et relancer.

Code TEXT :

UPSCABLE ether
UPSTYPE snmp
DEVICE 192.168.1.2:161:APC:public

J'ai activé le log de l'état de l'onduleur toutes les 5 minutes dans le fichier STATFILE /var/log/apcupsd.status.

Code TEXT :

STATTIME 300

Voila maintenant mon PC-NAS sera stoppé correctement à la prochaine coupure de courant. Les seuils sont paramétrables.

Code BASH :

root@cerise:~# apcaccess
APC      : 001,046,1040
DATE     : 2021-06-27 16:27:41 +0200
HOSTNAME : cerise
VERSION  : 3.14.14 (31 May 2016) debian
UPSNAME  : ATELIER
CABLE    : Ethernet Link
DRIVER   : SNMP UPS Driver
UPSMODE  : Stand Alone
STARTTIME: 2021-06-27 15:47:30 +0200
MODEL    : SMART-UPS 1000
STATUS   : ONLINE
LINEV    : 234.0 Volts
LOADPCT  : 4.0 Percent
BCHARGE  : 100.0 Percent
TIMELEFT : 73.0 Minutes
MBATTCHG : 5 Percent
MINTIMEL : 3 Minutes
MAXTIME  : 0 Seconds
MAXLINEV : 236.0 Volts
MINLINEV : 230.0 Volts
OUTPUTV  : 234.0 Volts
SENSE    : Medium
DWAKE    : 0 Seconds
DSHUTD   : 20 Seconds
DLOWBATT : 5 Minutes
LOTRANS  : 204.0 Volts
HITRANS  : 253.0 Volts
RETPCT   : 15.0 Percent
ITEMP    : 38.0 C
ALARMDEL : 5 Seconds
LINEFREQ : 50.0 Hz
LASTXFER : No transfers since turnon
NUMXFERS : 0
TONBATT  : 0 Seconds
CUMONBATT: 0 Seconds
XOFFBATT : N/A
SELFTEST : OK
STESTI   : 168
STATFLAG : 0x05000008
MANDATE  : 05/12/99
SERIALNO : GS9920005848
BATTDATE : 10/22/13
NOMOUTV  : 230 Volts
EXTBATTS : 0
BADBATTS : 0
FIRMWARE : 60.11.I
END APC  : 2021-06-27 16:28:21 +0200

Explications des valeurs : https://linux.die.net/man/8/apcaccess

Code BASH :

root@cerise:~# systemctl status apcupsd
● apcupsd.service - UPS power management daemon
     Loaded: loaded (/lib/systemd/system/apcupsd.service; enabled; vendor preset: enabled)
     Active: active (running) since Sun 2021-06-27 15:47:30 CEST; 43min ago
       Docs: man:apcupsd(8)
    Process: 5613 ExecStartPre=/lib/apcupsd/prestart (code=exited, status=0/SUCCESS)
    Process: 5631 ExecStart=/sbin/apcupsd (code=exited, status=0/SUCCESS)
   Main PID: 5632 (apcupsd)
      Tasks: 3 (limit: 9332)
     Memory: 1.0M
     CGroup: /system.slice/apcupsd.service
             └─5632 /sbin/apcupsd
juin 27 15:47:30 cerise systemd[1]: Starting UPS power management daemon...
juin 27 15:47:30 cerise systemd[1]: apcupsd.service: Cant open PID file /run/apcupsd.pid (yet?) after start: Operation not permitted
juin 27 15:47:30 cerise apcupsd[5632]: apcupsd 3.14.14 (31 May 2016) debian startup succeeded
juin 27 15:47:30 cerise apcupsd[5632]: NIS server startup succeeded
juin 27 15:47:30 cerise systemd[1]: Started UPS power management daemon.
root@cerise:~# netstat -a | grep 3551
tcp        0      0 cerise:3551             0.0.0.0:*               LISTEN
tcp        0      0 cerise:52018            cerise:3551             TIME_WAIT
root@cerise:~#

Peertube - Journal de bord maintenance

Sat, 15 Feb 2020 12:56:00 +0100

Horodatage	Résumé	Versions/Détails
09/04/2026 22h45	MAJ Debian	Debian 13.4 partout
09/04/2026 22h30	MAJ Peertube	Peertube 8.1.5
03/04/2026 17h30	MAJ Peertube	Peertube 8.1.4
13/03/2026 17h15	MAJ Peertube	Peertube 8.1.2
12/03/2026 22h20	MAJ Peertube	Peertube 8.1.1
27/01/2026 17h55	MAJ Peertube	Peertube 8.0.2
16/12/2025 23h45	MAJ Peertube	Peertube 8.0.1
12/12/2025 00h00	MAJ Peertube	Peertube 8.0.0
04/10/2025 14h00-15h10	MAJ Debian	Debian 12.12 -> 13.1 pour frontend (VPS OVH) & backend (Dell Optiplex 3050)
01/10/2025 22h50	MAJ Peertube + Debian + Node.js	Peertube 7.3.0 + Debian 12.12 + Node 22.20.0
22/08/2025 19h40	MAJ Node.js	22.18.0
02/08/2025 00h00	MAJ Peertube + Debian + Node.js	Peertube 7.2.3 + Debian 12.11
16/06/2025 19h20	MAJ Peertube	Peertube 7.2.1
07/06/2025 23h30	MAJ Peertube	Peertube 7.2.0
08/04/2025 19h30	MAJ Peertube	Peertube 7.1.1
05/04/2025 00h30	MAJ Debian	Debian 12.10
14/03/2025 21h25	MAJ NodeJS & kernel	20.18.3 -> 20.19.0, 6.1.124 -> 6.1.128
04/03/2025 17h30	MAJ NodeJS	18.20.6 ->20.18.3
11/01/2025 16h50	MAJ Debian	Debian 12.9
09/01/2025 19h15	MAJ Peertube	Peertube 7.0.1
18/12/2024 00h45	MAJ Peertube	Peertube 7.0.0
09/10/2024 18h15	MAJ Peertube	Peertube 6.3.2
29/09/2024 17h20	MAJ Peertube	Peertube 6.3.1
21/09/2024 21h30	MAJ Peertube	Peertube 6.3.0
02/08/2024 00h00	MAJ Peertube	Peertube 6.2.1
27/07/2024 10h50	MAJ Peertube	Peertube 6.2.0
30/04/2024 15h20	MAJ Peertube	Peertube 6.1.0
04/04/2024 19h00	MAJ Peertube sécurité	Peertube 6.0.4
23/03/2024	Migration	Passage du serveur dédié SoYouStart (2018) -> Serveur Dell auto-hébergé
31/01/2024 23h00	Génération des storyboards	Génération de tous les storyboards (pour toutes les vidéos existantes) --> https://docs.joinpeertube.org/maintain/tools#generate-storyboard Code BASH : USER@peertube:/var/www/peertube/peertube-latest$ sudo -u peertube NODE_CONFIG_DIR=/var/www/peertube/config NODE_ENV=production npm run create-generate-storyboard-job -- --all-videos > peertube@6.0.3 create-generate-storyboard-job > node ./dist/scripts/create-generate-storyboard-job.js --all-videos Created generate-storyboard job for Compaq Prolinea 4/100 - Réparation kinder surprise. Created generate-storyboard job for Nettoyer les têtes de son magnétoscope VHS. Created generate-storyboard job for Réparation micro-chaîne Grundig MF 2050. ...
24/01/2024 18h00	MAJ Peertube	Peertube 6.0.3
07/01/2024 00h45	MAJ Debian	Debian 12.4 (Kernel 6.1.69) Node 18.19
13/12/2023 22h10	MAJ Peertube	Peertube 6.0.2
03/12/2023 de 16h15 à 16h45	MAJ Debian & Peertube	Toutes les vidéos sont en HLS exclusivement. Debian 12.2 Peertube 6.0.1 ffmpeg 5.1.4
16/11/2023 17h30	MAJ PostgreSQL	Postgres 15.4 -> 15.5 (CVE-2023-5869)
12/09/2023 de 20h00 à 22h00	MAJ Debian	Debian 11.7 -> 12.1 noyau 6.1.52 ffmpeg 5.1.3 nginx 1.22.1 redis 7.0.11 Node 16 -> 18.17.1 LTS Postgres 15.3 -> 15.4
09/09/2023	MAJ Peertube	Peertube 5.2.1
08/07/2023	MAJ Debian	Debian 10 -> 11.7
25/06/2023	MAJ Peertube	Peertube 5.2.0
19/06/2023	MAJ Postgres	Postgres 11.20 -> 15.3
10/06/2022 19h55	MAJ Peertube	Peertube 4.2.0
31/05/2022 (nuit)	MAJ Debian	Node.js 16.15 Debian 10.12 + Noyau 4.19.235-1 Postgres 11.16 Reboot serveur
08/03/2022 11h25	MAJ Peertube	Peertube 4.1.1
23/02/2022 10h25	MAJ Globale	Peertube 4.1.0 Node.js 16.14 Postgres 11.15 Noyau 4.19.208-1 Reboot serveur
15/12/2021 10h40	MAJ Globale	Peertube 4.0.0 Node.js 16.13.1 Postgres 11.14 Debian 10.11 Reboot serveur ]
13/12/2021 19h50	MAJ ffpmeg	ffmpeg 4.2 --> 4.4.1 (compilation manuelle avec options --enable-gpl --enable-libaom --enable-libass --enable-libfdk-aac --enable-libfreetype --enable-libmp3lame --enable-libopus --enable-libvorbis --enable-libvpx --enable-libx264 --enable-libx265 --enable-nonfree)
16/10/2021 21h28	MAJ Peertube	Peertube 3.4.1
27/09/2021 22h19	MAJ Node	Node.js 12.22.6
15/09/2021 9h55	MAJ Peertube	Peertube 3.4.0
19/08/2021 12h45	MAJ Peertube	Peertube 3.3.0
19/08/2021 12h24	MAJ Debian	Node.js 12.22.5 Postgres 11.13 Debian 10.10 (Kernel 4.19.194-3) Reboot serveur
11/06/2021 23h30	MAJ Peertube	Peertube 3.2.1
03/04/2021 18h05	MAJ Peertube	Peertube 3.1.0
02/04/2021 22h30	MAJ Debian	Node.js 12.22.0 Postgres 11.11 Debian 10.9 Reboot serveur
07/02/2021 19h30	MAJ Peertube	Peertube 3.0.1
22/01/2021 00h30	MAJ Debian	Node.js 12.20.1 Postgres 11.10 Debian 10.7 Reboot serveur
13/09/2020 22h48	MAJ Debian	Node.js 10.22.0 Peertube 2.4.0 Postgres 11.9 Debian 10.5 Reboot serveur
23/06/2020 17h00	Modification config	ésactivation de la redondance (remote_redundancy > videos > accept_from : 'nobody'). Serveurs tiers non fiables, mauvaise expérience utilisateur. Relance furtive + retrait de toutes les redondances de vidéos.
13/09/2020 22h48	MAJ Globale	Node.js 10.21.0 Peertube 2.2.0 Postgres 11.8
27/02/2020	MAJ Peertube	Peertube 2.1.0 en 2.1.1 - Relance furtive
26/02/2020	MAJ Globale + HLS	Peertube 2.0.0 -> 2.1.0 Postgres 11.6 -> 11.7 Activation du mode HLS. Script de migration peertube-2.1.js ne parcourt aucune vidéo. Requête SQL ne renvoie aucune ligne. Certainement car le mode HLS n'était pas activé avant. Essai manuel OK avec le script create-transcoding-job -- --generate-hls sur vidéo Panasonic SA-PMX70.

15/02/2020 - Passage de Postgres 9.6 en 11.6

La chose ne s'est pas faite sans mal. Pour ma part j'avais deux instances Postgres, une en 9.6 (en production) et l'autre en 11.6 (en attente) créée lors du passage de Debian 9 vers 10. Le but étant de migrer les données de l'une à l'autre. Comme on saute 2 versions majeures on ne peut pas juste copier les fichiers plats (ou sinon avec pg_upgrade). Une autre méthode simple pour réaliser cela est donc de faire un export et puis un import avec les utilitaires pg_dump et pg_restore. La base étant petite cela prend peu de temps. La base cible et les rôles ont été créés de prime-abord.

Code BASH :

pg_dump --host "localhost" --port "5432" --username "postgres" --dbname "peertube_prod" -c -Fc -f "/tmp/sauvegarde_migration.backup"
pg_restore --clean --host "localhost" --port "5433" --username "peertube" --role "postgres" --dbname "peertube_prod" --verbose "/tmp/sauvegarde_migration.backup"

Bref la procédure n'a rien de sorcier mais j'ai eu une erreur lors de l'importation.

Code TEXT :

pg_restore: création de INDEX « public.tag_name »
pg_restore: [programme d'archivage (db)] Erreur à partir de l'entrée TOC 2527 ; 1259 16649 INDEX tag_name peertube
pg_restore: [programme d'archivage (db)] could not execute query: ERREUR:  n'a pas pu créer l'index unique « tag_name »
DÉTAIL : La clé (name)=(santanavevo) est dupliquée.
    La commande était : CREATE UNIQUE INDEX tag_name ON public.tag USING btree (name);

Bizarre que des valeurs soient dupliquées pour un index unique. Je ne m'explique pas comment, mais bon.
Peertube détectant l'index manquant il re-tente de le créer au lancement de l'instance et tombe sur la même erreur. Oh étonnant !

Code TEXT :

févr. 15 01:18:59 peertube systemd[1]: Started PeerTube daemon.
févr. 15 01:18:59 peertube peertube[15777]: > peertube@2.0.0 start /var/www/peertube/versions/peertube-v2.0.0
févr. 15 01:18:59 peertube peertube[15777]: > node dist/server
févr. 15 01:19:01 peertube systemd[1]: Stopping PeerTube daemon...
févr. 15 01:19:01 peertube systemd[1]: peertube.service: Main process exited, code=killed, status=15/TERM
févr. 15 01:19:01 peertube systemd[1]: peertube.service: Succeeded.
févr. 15 01:19:01 peertube systemd[1]: Stopped PeerTube daemon.
févr. 15 01:20:45 peertube systemd[1]: Started PeerTube daemon.
févr. 15 01:20:46 peertube peertube[16021]: > peertube@2.0.0 start /var/www/peertube/versions/peertube-v2.0.0
févr. 15 01:20:46 peertube peertube[16021]: > node dist/server
févr. 15 01:20:48 peertube peertube[16021]: [video.latavernedejohnjohn.fr:443] 2020-02-15 01:20:48.289 info: Database peertube_prod is ready.
févr. 15 01:20:48 peertube peertube[16021]: [video.latavernedejohnjohn.fr:443] 2020-02-15 01:20:48.370 error: Cannot install application. {
févr. 15 01:20:48 peertube peertube[16021]:   "err": {
févr. 15 01:20:48 peertube peertube[16021]:     "stack": "SequelizeUniqueConstraintError: n'a pas pu créer l'index unique « tag_name »\n    at Query.formatError (/var/www/peertube/versions/peertube-v
févr. 15 01:20:48 peertube peertube[16021]:     "message": "n'a pas pu créer l'index unique « tag_name »",
févr. 15 01:20:48 peertube peertube[16021]:     "name": "SequelizeUniqueConstraintError",
févr. 15 01:20:48 peertube peertube[16021]:     "errors": {},
févr. 15 01:20:48 peertube peertube[16021]:     "parent": {
févr. 15 01:20:48 peertube peertube[16021]:       "stack": "error: n'a pas pu créer l'index unique « tag_name »\n    at Connection.parseE (/var/www/peertube/versions/peertube-v2.0.0/node_modules/pg/l
févr. 15 01:20:48 peertube peertube[16021]:       "message": "n'a pas pu créer l'index unique « tag_name »",
févr. 15 01:20:48 peertube peertube[16021]:       "name": "error",
févr. 15 01:20:48 peertube peertube[16021]:       "length": 188,
févr. 15 01:20:48 peertube peertube[16021]:       "severity": "ERREUR",
févr. 15 01:20:48 peertube peertube[16021]:       "code": "23505",
févr. 15 01:20:48 peertube peertube[16021]:       "detail": "La clé (name)=(santanavevo) est dupliquée.",
févr. 15 01:20:48 peertube peertube[16021]:       "schema": "public",
févr. 15 01:20:48 peertube peertube[16021]:       "table": "tag",
févr. 15 01:20:48 peertube peertube[16021]:       "constraint": "tag_name",
févr. 15 01:20:48 peertube peertube[16021]:       "file": "tuplesort.c",
févr. 15 01:20:48 peertube peertube[16021]:       "line": "4056",
févr. 15 01:20:48 peertube peertube[16021]:       "routine": "comparetup_index_btree",
févr. 15 01:20:48 peertube peertube[16021]:       "sql": "CREATE UNIQUE INDEX \"tag_name\" ON \"tag\" (\"name\")"
févr. 15 01:20:48 peertube peertube[16021]:     },
févr. 15 01:20:48 peertube peertube[16021]:     "sql": "CREATE UNIQUE INDEX \"tag_name\" ON \"tag\" (\"name\")"
févr. 15 01:20:48 peertube peertube[16021]:   }
févr. 15 01:20:48 peertube peertube[16021]: }
févr. 15 01:20:48 peertube peertube[16021]: npm ERR! code ELIFECYCLE
févr. 15 01:20:48 peertube peertube[16021]: npm ERR! errno 255
févr. 15 01:20:48 peertube peertube[16021]: npm ERR! peertube@2.0.0 start: `node dist/server`
févr. 15 01:20:48 peertube peertube[16021]: npm ERR! Exit status 255
févr. 15 01:20:48 peertube peertube[16021]: npm ERR!
févr. 15 01:20:48 peertube peertube[16021]: npm ERR! Failed at the peertube@2.0.0 start script.
févr. 15 01:20:48 peertube peertube[16021]: npm ERR! This is probably not a problem with npm. There is likely additional logging output above.
févr. 15 01:20:48 peertube peertube[16021]: npm ERR! A complete log of this run can be found in:
févr. 15 01:20:48 peertube peertube[16021]: npm ERR!     /var/www/peertube/.npm/_logs/2020-02-15T00_20_48_386Z-debug.log

Allez il faut faire un tour en base, et pourtant rien de bizarre de prime abord :

Code TEXT :

psql (11.6 (Debian 11.6-1.pgdg100+1), serveur 9.6.16)
Connexion SSL (protocole : TLSv1.3, chiffrement : TLS_AES_256_GCM_SHA384, bits : 256, compression : désactivé)
Saisissez « help » pour l'aide.
peertube_prod=> \x
Affichage étendu activé.
peertube_prod=> select * from tag where name='santanavevo';
-[ RECORD 1 ]-----
id   | 10311
name | santanavevo

Et pourtant il y a bien anguille sous roche quand on essaye avec like :

Code TEXT :

peertube_prod=> select * from tag where name like '%santanavevo%';
-[ RECORD 1 ]-----
id   | 2092
name | santanavevo
-[ RECORD 2 ]-----
id   | 10311
name | santanavevo
peertube_prod=> select id,name::bytea from tag where name like '%santanavevo%';
-[ RECORD 1 ]------------------
id   | 2092
name | \x73616e74616e617665766f
-[ RECORD 2 ]------------------
id   | 10311
name | \x73616e74616e617665766f

Deux tuples ressortent cette fois. Caractère parasite ? Reste à déterminer lequel est réellement utilisé :

Code TEXT :

peertube_prod=> select * from video where video.id in (select "videoId" from "videoTag" where "tagId"=2092);
(0 ligne)
peertube_prod=> select * from video where video.id in (select "videoId" from "videoTag" where "tagId"=10311);
-[ RECORD 1 ]---------+-------------------------------------------------------------------------------
id                    | 12916
uuid                  | 6c28dd73-2570-417f-8a8a-03c46dd07ef5
name                  | Santana - Corazon Espinado ft. Mana (Official Video)
category              | 1
licence               | 1
language              | es
privacy               | 1
nsfw                  | f
description           | Source : https://www.youtube.com/watch?v=t6omUxqhG78\r                        +
                      | \r                                                                            +
                      | Check out Santana's official music video for 'Corazon Espinado' ft. Mana.\r   +
                      | \r                                                                            +
                      | Click to listen to Santana on Spotify: http://smarturl.it/SanSpot?IQid=SanCE\r+
                      | \r                                                                            +
                      | As featured on Ultimate Santana. C...
support               |
duration              | 275
views                 | 1
likes                 | 0
dislikes              | 0
remote                | t
url                   | https://video.ploud.fr/videos/watch/6c28dd73-2570-417f-8a8a-03c46dd07ef5
commentsEnabled       | t
waitTranscoding       | t
state                 | 1
publishedAt           | 2019-08-02 02:16:11.913+02
channelId             | 343
createdAt             | 2019-08-02 02:16:11.913+02
updatedAt             | 2020-02-15 01:40:17.043+01
downloadEnabled       | t
originallyPublishedAt | 2013-10-02 00:00:00+02

Cette vidéo n'utilise pas le tag 2092, donc on peut le supprimer sans crainte.

Code TEXT :

peertube_prod=> select * from "videoTag" where "videoId"=12916;
-[ RECORD 1 ]-------------------------
videoId   | 12916
tagId     | 2094
createdAt | 2020-01-28 03:41:28.985+01
updatedAt | 2020-01-28 03:41:28.985+01
-[ RECORD 2 ]-------------------------
videoId   | 12916
tagId     | 10312
createdAt | 2020-01-28 03:41:28.985+01
updatedAt | 2020-01-28 03:41:28.985+01
-[ RECORD 3 ]-------------------------
videoId   | 12916
tagId     | 10311
createdAt | 2020-01-28 03:41:28.985+01
updatedAt | 2020-01-28 03:41:28.985+01
-[ RECORD 4 ]-------------------------
videoId   | 12916
tagId     | 2091
createdAt | 2020-01-28 03:41:28.985+01
updatedAt | 2020-01-28 03:41:28.985+01
-[ RECORD 5 ]-------------------------
videoId   | 12916
tagId     | 2090
createdAt | 2020-01-28 03:41:28.985+01
updatedAt | 2020-01-28 03:41:28.985+01
peertube_prod=> delete from tag where id=2092;
DELETE 1

Je croyais qu'il n'y en avait qu'un seul. Donc au bout d'un moment, on compte les doublons, 27 au total.

Code XML :

peertube_prod=> SELECT name, COUNT(*) occurrences FROM tag GROUP BY name HAVING COUNT(*) > 1;
      name      | occurrences
----------------+-------------
 Keep           |           2
 open source    |           2
 Musique        |           2
 #Musique       |           2
 open-source    |           2
 thinkerview    |           2
 петр великий   |           2
 ke$ha vevo     |           2
 cotton eye joe |           2
 cottoneyejoe   |           2
 hip hop        |           2
 hip-hop        |           2
 Don't          |           2
 #FreeCAD       |           2
 острова        |           2
 паломничество  |           2
 FreeCAD        |           2
 Dont           |           2
 lofi           |           2
 neg'marron     |           2
 music          |           2
 #music         |           2
 let's play     |           2
 thinker view   |           2
 anime          |           2
 hiphop         |           2
 negmarron      |           2
(27 lignes)

On commence par supprimer tous les tags qui ne sont utilisés par aucune vidéo. Ce qui en élimine 1444.

Code TEXT :

peertube_prod=> begin;
BEGIN
peertube_prod=> delete from tag where id IN (select id from tag where id not in (select distinct "tagId" from "videoTag"));
DELETE 1444
peertube_prod=> commit;
COMMIT

Ce qui fait redescendre le nombre de doublons à 7.

Code TEXT :

peertube_prod=> SELECT name, COUNT(*) occurrences FROM tag GROUP BY id, name HAVING COUNT(*) > 1;
     name      | occurrences
---------------+-------------
 thinkerview   |           2
 hip-hop       |           2
 паломничество |           2
 FreeCAD       |           2
 music         |           2
 anime         |           2
 hiphop        |           2
(7 lignes)

Après quelques updates manuels pour résorber ces 7 derniers doublons, l'import se fait sans souci.

Reste à passer à la version 2.1.0 de Peertube la semaine prochaine.

Peertube - Uploader de très gros fichiers

Thu, 15 Aug 2019 20:03:00 +0200

OBSOLÈTE !!! OBSOLÈTE !!! OBSOLÈTE !!!

Procédure d'upload de gros fichiers sur Peertube supérieurs à 8Go - 'The hard way'.

OBSOLÈTE !!! OBSOLÈTE !!! OBSOLÈTE !!!
Perso même après avoir bidouillé nginx dans tous les sens je n'arrive à rien. Une fois bien configuré (client_max_body_size, client_body_temp_path, augmentation des timeout), nginx récupère bien et stocke le fichier envoyé dans son espace d'upload en intégralité. Ayant la fibre j'ai pu tester des fichiers jusqu'à 32Go et cela ne pose pas de problème. nginx n'a rien à voir dans l'histoire pour moi.

Code TEXT :

client_max_body_size 32G;
proxy_connect_timeout       2400;
proxy_send_timeout          2400;
proxy_read_timeout          2400;
send_timeout                2400;
client_body_temp_path /peerstor/uploads/;

Il y a de la place !

Code BASH :

df -h /peerstor/uploads/
Sys. de fichiers Taille Utilisé Dispo Uti% Monté sur
/dev/md8           1,8T     74G  1,8T   5% /peerstor

Le problème c'est quand Peertube arrive derrière pour le copier dans son répertoire temporaire et y faire ses affaires, la copie ne se fait pas entièrement et bloque à un stade de manière aléatoire au bout de quelques Go de copie (souvent 2Go pile). J'ai l'impression que la copie est faite en dure par Peertube lui-même plutôt que faite par le système (simple copie système, du genre avec mv). Il s'en suit une erreur 503 ou 502 "backend" sur l'IHM d'upload sur Firefox ou Chrome. Le formulaire d'upload est remis à zéro. J'ai lâché l'affaire.

Plus d'infos : http://burogu.makotoworkshop.org/index.php?post/2018/12/08/bigfilepeertube

Cette procédure de contournement est un filoutage qui nécessite un accès SSH/admin sur l'instance. C'est lourdingue mais bon, on fait comme on peut hein. Heureusement que Chocobozz a prévu quelques petits scripts bien utiles, dont un qui justement permet de contourner le système d'upload HTTP et à prendre un fichier directement déjà présent sur le serveur.

Importer un fichier vidéo bidon (1080p) de quelques secondes à peine via l'interface navigateur. Penser à mettre la vidéo en privée. Laissez le transcodage se faire normalement (720p et 480p dans mon cas).
Récupérer l'ID généré de la vidéo uploadée (dans les URL). Par exemple : e9a72892-f5f1-46af-a126-70e0c9fefb90
Supprimer (avec pgAdmin3/psql) dans la table "videoFile" les n enregistrements liés aux résolutions inférieures à la vidéo source (clé étrangère videoId). Une ligne par résolution.
Supprimer (rm) aussi les fichiers vidéos associés à ces résolutions inférieures (e9a72892-f5f1-46af-a126-70e0c9fefb90-720.mp4 et e9a72892-f5f1-46af-a126-70e0c9fefb90-480.mp4).
Uploader le gros fichier vidéo sur le serveur par un autre moyen que HTTP/HTTPS, par exemple via SSH.

Remplacer la vidéo existante :

Lancer le script d'import (create-import-video-file-job.js) :

Code BASH :

cd /var/www/peertube/peertube-latest
sudo -u peertube NODE_CONFIG_DIR=/var/www/peertube/config NODE_ENV=production npm run create-import-video-file-job -- -v e9a72892-f5f1-46af-a126-70e0c9fefb90 -i /peerstor/videos/maVraieVideoQuiRemplaceLaVideoBidon.mp4

Aller dans les jobs en se connectant root sur l'IHM Peertube (Administration > Système > Travaux)
Attendre que son état devienne "completed". Cela peut être long (copie + calcul du infoHash).
Le fichier e9a72892-f5f1-46af-a126-70e0c9fefb90-1080.mp4 sera remplacé par une copie de maVraieVideoQuiRemplaceLaVideoBidon.mp4 (ils auront la même taille, on peut éventuellement vérifier par md5sum/sha512sum).

Supprimer le fichier vidéo source devenu inutile /peerstor/videos/maVraieVideoQuiRemplaceLaVideoBidon.mp4 (rm).

A ce stade seul le fichier 1080p a été substitué, il faut ensuite explicitement demander à re-encoder tout et générer les résolutions inférieures :

Lancer le script de transcodage (create-transcoding-job.js) pour :

Code BASH :

cd /var/www/peertube/peertube-latest
sudo -u peertube NODE_CONFIG_DIR=/var/www/peertube/config NODE_ENV=production npm run create-transcoding-job -- -v e9a72892-f5f1-46af-a126-70e0c9fefb90

Aller dans les jobs en se connectant root sur l'IHM Peertube (Administration > Système > Travaux)
Attendre que son état devienne "completed".

Si la durée de la vidéo n'est plus la même : modifier manuellement avec pgAdmin/psql la durée de la vidéo (car elle n'est pas mise à jour par les scripts), il s'agit de la colonne "duration" de la table "video". La valeur est un integer qui représente des secondes. Commande pour avoir la valeur à mettre :
Code BASH :
```
expr `mediainfo --Inform="General;%Duration%" e9a72892-f5f1-46af-a126-70e0c9fefb90-1080.mp4` / 1000
```
Tester la vidéo, vérifier que tout est OK dans toutes les résolutions.
Passer la vidéo en statut public.

That's it !

Toutes ces manipulations sont scriptables si on y met un peu de volonté. Perso cela ne concerne qu'a peine quelques vidéos très longues chez moi, donc je le fais manuellement, ça ne vaut pas le coup. Un pgAdmin lancé en SSH avec affichage à distance c'est hyper pratique pour faire des petites modifications rapidement à la souris sans avoir à taper du SQL.

Installation d'une instance Peertube (sur Debian Stretch 9.6)

Tue, 27 Nov 2018 03:42:00 +0100

Exemple d'installation d'une instance Peertube en mode production, publique pour le web (extranet).
Il existe une version YunoHost ainsi qu'en conteneur Docker

1 - Le choix du serveur (attention au transcodage)

Concernant le processeur, attention à ne pas prendre de CPU trop faible comme par exemple un Intel Atom, car Peertube transcode chaque vidéo uploadée sur le serveur lui-même via ffmpeg. Et plus le CPU est petit plus cela va mettre du temps. Pour exemple sur un serveur Kimsufi KS-3 CPU Intel Atom N2800 - 2 threads réservés pour une vidéo de 6 minutes uploadée (1080p 6Mbps). Rappel : le fichier original en 1080p (ou plus) est lui-aussi transcodé.

Résolution	Total	Ratio
1080	60 minutes	x10
480	15 minutes	x2.5
360	11 minutes	x1.83
720	29 minutes	x4.83
240	6 minutes	x1

Total = 60 + 15 + 11 + 29 + 6 = 121 minutes = 2 heures de conversion pour 6 minutes de vidéos

La même chose sur un Xeon E3-1225 V2 dans les mêmes conditions :

Résolution	Total	Ratio
1080	7 minutes	x1
480	2 minutes	x0.3
360	2 minutes	x0.3
720	3 minutes	x0.5
240	2 minutes	x0.3

Total = 7 + 2 + 2 + 3 + 2 = 16 minutes de conversion pour 6 minutes de vidéos

Chaque résolution transcodée engendre la création de fichiers vidéos supplémentaires (un fichier suffixé pour chaque définition inférieure). Ces fichiers réclament évidemment de l'espace. Si la vidéo originale en 1080p occupe 110Mo à elle seule, avec les définitions inférieures on arrive presque au double (total = 205Mo).
On pourrait donc être tenté de désactiver le transcodage dans les paramètres de Peertube, seulement :

le fichier téléversé sur le serveur peut ne pas être compatible avec tous les navigateurs clients.
certains clients n'ont pas le débit ADSL pour regarder la vidéo native en 1080, il faut donc proposer le 720p voire même en dessous pour économiser la bande passante pour les mobiles.
il n'existe pour le moment aucun moyen facile de transcoder sur son PC toutes les résolutions et de téléverser les fichiers directement. Ce qui aurait été pratique pour ceux qui ont la fibre. Si vous tentez un max de bricolage en base de données vous attend et il vaut mieux éviter.

Pour la mémoire évidemment tout dépend de la charge et du nombre de vidéos et d'utilisateurs à desservir, 2-4Go de RAM sont largement suffisants. Si plus, ce sera utilisé en tant que cache de vidéos et autres fichiers statiques par l'OS, cela n'est pas perdu.

Let's GO !

Vous vous apercevrez que la procédure "hardcore" est longue mais pas infaisable pour autant. Bon courage.

2 - Première connexion au serveur livré & préparation/personnalisation du système

Après livraison d'un serveur chez Kimsufi/SoYouStart/PeuImporte, se connecter en root avec le couple login/mot de passe fourni par courriel. Rappel : les courriels sont aussi visibles depuis l'interface client (Mon Compte > Mes emails > "Installation de votre serveur terminée").

Mise à jour du serveur (pas toujours nécessaire)

Code BASH :

root@peertube:~#apt-get update
root@peertube:~#apt-get upgrade
root@peertube:~#cat /etc/debian_version
9.6

Remettre le serveur dans le bon fuseau horaire (Europe/Paris)

Code BASH :

root@peertube:~#dpkg-reconfigure tzdata

Création d'un utilisateur lambda* + génération d'une paire de clés

Code BASH :

root@peertube:~#useradd lambda -d /home/lambda -m -s /bin/bash
root@peertube:~#su - lambda
lambda@peertube:~$ssh-keygen
lambda@peertube:~$exit

* = Le nom lambda est ici volontairement générique car donner le d'utilisateur réel que j'utilise serait une aide pour d'éventuels tipiakeurs. Donc à vous de le remplacer par ce que vous voulez, soyez inventif.

Activer le mécanisme de sudoers + rajouter lambda aux sudoers

Code BASH :

root@peertube:~#apt install sudo
root@peertube:~#usermod -aG sudo lambda

Positionner un mot de passe à l'utilisateur lambda

Code BASH :

root@peertube:~#passwd lambda

Contrôle

A ce stade vérifier que lambda peut se connecter en SSH au serveur avec son mot de passe (avec une nouvelle session à part). Une fois connecté vérifier que lambda peut passer root via sudo :

Code BASH :

lambda@peertube:~$sudo su -
root@peertube:~#

Sécurisations SSH (Facultatif mais très conseillé)

Copier votre clé publique dans le fichier authorized_keys de lambda (dans mon cas depuis Mobaxterm). Suivre ce tutoriel pour plus d'informations. La même chose peut se faire avec PuTTY, et c'est bien évidemment encore plus facile depuis Linux.

Code BASH :

ssh-copy-id lambda@IP_SERVEUR

Reconfigurer le démon SSHD :

Code BASH :

root@peertube:~#vi /etc/ssh/sshd_config

Port XXXX (changer le port par défaut, mettre autre que 22)
LoginGraceTime (descendre)
MaxAuthTries (descendre)
PermitRootLogin no (ne pas autoriser la connexion au compte root depuis SSH)
PubkeyAuthentication yes (activer l'authentification par clé publique)
X11Forwarding yes (activer la redirection X11, vous en aurez besoin, activé par défaut)
PasswordAuthentication no (désactiver l'authentification par mot de passe)

Relancer le démon SSHD pour prendre en compte les changements :

Code BASH :

root@peertube:~#systemctl restart sshd

Dorénavant seul l'utilisateur lambda peut se connecter au serveur sur le nouveau port SSH indiqué et uniquement avec la clé publique du client (Mobaxterm/PuTTY).

Installation de divers paquets intéressants

Code BASH :

root@peertube:~#apt-get install htop iperf iperf3 speedtest-cli ufw curl file fail2ban

Tester la bande passante du serveur :

Code BASH :

root@peertube:~# speedtest-cli
Retrieving speedtest.net configuration...
Testing from OVH SAS (188.165.236.17)...
Retrieving speedtest.net server list...
Selecting best server based on ping...
Hosted by Naitways (Paris) [1.88 km]: 5.041 ms
Testing download speed................................................................................
Download: 818.86 Mbit/s
Testing upload speed....................................................................................................
Upload: 251.53 Mbit/s

Code BASH :

root@peertube:~# iperf -c ping.online.net
------------------------------------------------------------
Client connecting to ping.online.net, TCP port 5001
TCP window size: 85.0 KByte (default)
------------------------------------------------------------
[  3] local 188.165.236.17 port 39566 connected with 62.210.18.40 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec   301 MBytes   252 Mbits/sec

Configuration et activation du pare-feu (facultatif mais très conseillé)

Code BASH :

root@peertube:~#ufw logging off #(désactiver journalisation)
root@peertube:~#ufw allow 80/tcp #(Peertube NGINX HTTP)
root@peertube:~#ufw allow 443/tcp #(Peertube NGINX HTTPS)
root@peertube:~#ufw allow 9000/tcp #(Peertube Node.js websockets)

Concernant l'accès via SSH :
Option 1 - Soit SSH accessible uniquement depuis la maison, s'assurer d'avoir une IP fixe ! (Plus sécurisé)

Code BASH :

root@peertube:~#ufw allow proto tcp from $IP_MAISON to any port $PORT_SSH

Option 2 - Soit SSH accessible depuis partout (Moins sécurisé, trouvable par nmap)

Code BASH :

root@peertube:~#ufw allow $PORT_SSH/tcp

Facultatif - Ajout supervision par SNMP (par exemple avec Centreon) accessible uniquement depuis la maison, s'assurer d'avoir une IP fixe :

Code BASH :

root@peertube:~#ufw allow proto udp from $IP_MAISON to any port 161

Activer le pare-feu et activer son lancement au démarrage :

Code BASH :

root@peertube:~#ufw enable
root@peertube:~#systemctl enable ufw

Faire un reboot et confirmer que le serveur est toujours accessible.

3 - Pré-installation de Peertube

La documentation officielle est accessible ici : https://docs.joinpeertube.org/#/install-any-os?id=installation
Il est très conseillé de la suivre. Ce qui est marqué ici date de 2018. Il peut y avoir des différences depuis.

Installer les pré-requis (dépendances) - Partie 1

Code BASH :

apt-get install unzip nginx ffmpeg pgadmin3 pgtop pg-activity postgresql postgresql-contrib openssl g++ make redis-tools redis-server git certbot python-certbot-nginx xauth mediainfo

Installer les pré-requis (dépendances) - Partie 2 (Node.js - Version 10 au moment de la création de cette page)

Rappel : N'utilisez pas les versions majeures impaires de Node.js.

Code BASH :

root@peertube:~#curl -sL https://deb.nodesource.com/setup_10.x | bash -
root@peertube:~#apt-get install -y nodejs

Installer les pré-requis (dépendances) - Partie 3 (Yarn)

Code BASH :

root@peertube:~#curl -sS https://dl.yarnpkg.com/debian/pubkey.gpg | sudo apt-key add -
root@peertube:~#echo "deb https://dl.yarnpkg.com/debian/ stable main" | sudo tee /etc/apt/sources.list.d/yarn.list
root@peertube:~#apt-get update && apt-get install yarn
root@peertube:~# yarn --version
1.12.3

MAJ décembre 2021 : Comme indiqué dans les changelogs de Peertube : Attention à votre version d'ffmpeg ! Il se peut que la version de votre distribution soit trop ancienne (< 4.1). La version 4.4.0 n'est pas compatible avec Peertube. J'ai recompilé manuellement en 4.2 il fût un temps puis en version 4.4.1 récemment pour ne pas avoir de problème. Si vous compilez, pensez à rajouter la bibliothèque libfdk-aac car Peertube s'en sert.

Créer l'utilisateur système peertube et renseigner son mot de passe

Code BASH :

root@peertube:~#useradd -m -d /var/www/peertube -s /bin/bash -p peertube peertube
root@peertube:~#passwd peertube
Entrez le nouveau mot de passe UNIX :
Retapez le nouveau mot de passe UNIX :
passwd: password updated successfully

Créer le rôle peertube + la base de données PostgreSQL nommée peertube_prod

Code BASH :

root@peertube:~#su - postgres
postgres@peertube:~$createuser -P peertube
[CHOISIR UN MOT DE PASSE ET LE RETENIR !!!]
postgres@peertube:~$createdb -O peertube -E UTF8 -T template0 peertube_prod
postgres@peertube:~$psql -c "CREATE EXTENSION pg_trgm;" peertube_prod
postgres@peertube:~$psql -c "CREATE EXTENSION unaccent;" peertube_prod

4 - Récupération & installation de Peertube

Créer les dossiers d'installation :

Code BASH :

root@peertube:~#su - peertube
peertube@peertube:~$cd /var/www/peertube && sudo -u peertube mkdir config storage versions && cd versions

Récupérer le nom de la dernière version disponible :

Code BASH :

peertube@peertube:~$export VERSION=$(curl -s https://api.github.com/repos/chocobozzz/2018/217/releases/latest | grep tag_name | cut -d '"' -f 4) && echo "Latest Peertube version is $VERSION"

Récupération du .zip de la dernière version :

Code BASH :

peertube@peertube:~$cd /var/www/2018/217/versions
peertube@peertube:~/versions$wget -q "https://github.com/Chocobozzz/2018/217/releases/download/${VERSION}/peertube-${VERSION}.zip"

Dézip et création d'un lien symbolique :

Code BASH :

peertube@peertube:~/versions$unzip peertube-${VERSION}.zip && rm peertube-${VERSION}.zip
peertube@peertube:~/versions$cd ../ && ln -s versions/peertube-${VERSION} ./peertube-latest

Installation :

Code BASH :

peertube@peertube:~$cd ./peertube-latest && yarn install --production --pure-lockfile
yarn install v1.12.3
[1/5] Validating package.json...
...
...
...
...
Done in 20.68s.
Done in 60.29s.

5 - Configurer Peertube + divers

Copier le modèle de fichier de configuration fourni :

Code BASH :

root@peertube:~#cd /var/www/peertube && sudo -u peertube cp peertube-latest/config/production.yaml.example config/production.yaml

Editez le fichier de configuration :

Code BASH :

root@peertube:~#vi /var/www/2018/217/config/production.yaml

Le remplacement des deux premières valeurs du tableau est indispensable ! Le reste peut être fait plus tard via l'interface d'administration web.

Nom valeur	Par défaut	Description	Exemple
webserver-hostname	example.com	FQDN instance	video.jonathandupre.fr
database-password	peertube	Mot de passe du rôle peertube (postgresql)
log-level	info	Verbosité du log	warning
admin-email	admin@example.com	Adresse courriel compte admin
transcoding-threads	1	Nombre de threads occupés pour l'encodage	Selon le nombre de cœurs de votre serveur (2 pour un quad core)

Configurer NGINX

Copier le fichier de configuration fourni :

Code BASH :

root@peertube:~#cp /var/www/2018/217/peertube-latest/support/nginx/peertube /etc/nginx/sites-available/peertube

Remplacez le domaine peertube.example.com par le vrai nom de domaine de votre instance :

Code BASH :

root@peertube:~#sed -i 's/peertube.example.com/video.monsite.fr/g' /etc/nginx/sites-available/peertube

Activer ce fichier de configuration dans nginx :

Code BASH :

root@peertube:~#ln -s /etc/nginx/sites-available/peertube /etc/nginx/sites-enabled/peertube

6 - Procédure de génération du certificat Let's Encrypt

Maintenant assurez-vous que le nom de domaine pointe bien sur votre serveur dans la zone DNS (video.monsite.fr --> IP_SERVEUR). Cela est nécessaire pour Let's Encrypt.

Arrêter Nginx :

Code BASH :

root@peertube:~#systemctl stop nginx

Commenter les directives ssl_certificate and ssl_certificate_key (lignes 22 et 23) :

Code BASH :

root@peertube:~# vim /etc/nginx/sites-available/peertube

Lancer certbot et répondre aux questions de l'assistant :

Code BASH :

root@peertube:~#certbot --authenticator standalone --installer nginx --post-hook "systemctl start nginx"

Décommenter les directives ssl_certificate and ssl_certificate_key (lignes 22 et 23) :

Code BASH :

root@peertube:~#vim /etc/nginx/sites-available/peertube

Nginx est déja relancé par l'option post-hook de certbot, envoyer un signal pour qu'il recharge sa configuration :

Code BASH :

root@peertube:~#systemctl reload nginx

TCP/IP Tuning

Code BASH :

root@peertube:~#cp /var/www/2018/217/peertube-latest/support/sysctl.d/30-peertube-tcp.conf /etc/sysctl.d/
root@peertube:~#sysctl -p /etc/sysctl.d/30-peertube-tcp.conf
net.core.default_qdisc = fq_codel
net.ipv4.tcp_congestion_control = bbr

systemd

Copier l'unité fournie, l'ajouter au système et activer le lancement automatique de peertube au boot :

Code BASH :

root@peertube:~#cp /var/www/2018/217/peertube-latest/support/systemd/peertube.service /etc/systemd/system/
root@peertube:~#systemctl daemon-reload
root@peertube:~#systemctl enable peertube

7 - Démarrer Peertube

A ce stade, il est acquis que Nginx, Postgres et Redis soient déjà lancés avant de démarrer Peertube.

Code BASH :

root@peertube:~#ps -ef | grep redis
redis    24322     1  0 01:02 ?        00:00:01 /usr/bin/redis-server 127.0.0.1:6379

Code BASH :

root@peertube:~#ps -ef | grep nginx
root     27491     1  0 01:50 ?        00:00:00 nginx: master process /usr/sbin/nginx -g daemon on; master_process on;
www-data 27492 27491  0 01:50 ?        00:00:00 nginx: worker process
www-data 27493 27491  0 01:50 ?        00:00:00 nginx: worker process
www-data 27494 27491  0 01:50 ?        00:00:00 nginx: worker process
www-data 27495 27491  0 01:50 ?        00:00:00 nginx: worker process

Code BASH :

root@peertube:~#ps -ef | grep postgres
postgres 23454     1  0 00:49 ?        00:00:00 /usr/lib/postgresql/9.6/bin/postgres -D /db/postgresql/9.6/main -c config_file=/etc/postgresql/9.6/main/postgresql.conf
postgres 23456 23454  0 00:49 ?        00:00:00 postgres: 9.6/main: checkpointer process
postgres 23457 23454  0 00:49 ?        00:00:00 postgres: 9.6/main: writer process
postgres 23458 23454  0 00:49 ?        00:00:00 postgres: 9.6/main: wal writer process
postgres 23459 23454  0 00:49 ?        00:00:00 postgres: 9.6/main: autovacuum launcher process
postgres 23460 23454  0 00:49 ?        00:00:00 postgres: 9.6/main: stats collector process

Ces 3 services sont UP, n'oubliez pas également la messagerie pour l'envoi des courriels si vous utilisez cette fonction. On peut lancer :

Code BASH :

root@peertube:~#systemctl start peertube

Le lancement se fait en background (démon), utiliser cette commande suivante pour voir si tout va bien (suivi du log) :

Code BASH :

root@peertube:~#journalctl -feu peertube

En cas d'erreur en boucle, faire un stop pour analyser le problème (stacktrace), au besoin le log par défaut sort dans /var/log/syslog. Si vous avez tout bien fait, vous pouvez vous connecter à votre instance en https :

8 - Se connecter à Peertube

L'utilisateur par défaut est "root" sur l'interface web, il est créé d'office dans la base PostgreSQL peertube_prod. Mais son mot de passe est dans les logs. Changeons-le dès maintenant en utilisant le script fourni :

Code BASH :

root@peertube:/var/log# su - peertube 
peertube@peertube:~$ cd /var/www/2018/217/peertube-latest && NODE_CONFIG_DIR=/var/www/2018/217/config NODE_ENV=production npm run reset-password -- -u root 
 
> peertube@1.0.1 reset-password /var/www/2018/217/versions/peertube-v1.0.1 
> node ./dist/scripts/reset-password.js "-u" "root" 
 
New password? 
User password updated. 
peertube@peertube:~/peertube-latest$

Il ne vous reste plus qu'à l'utiliser sur l'interface pour rentrer :

Maintenant vous avez accès à tout pour créer les autres utilisateurs, configurer et uploader :

Rappel : n'utilisez pas l'utilisateur root pour publier des vidéos. root est un utilisateur technique qui sert uniquement pour administrer l'instance ponctuellement. Créez des comptes utilisateurs normaux et publiez vos vidéos avec ces autres comptes.

Proof Of Concept - Manipulation du jukebox Pioneer via le web

Wed, 10 Oct 2018 00:00:00 +0200

Problématique : comment piloter à distance le changeur Pioneer ? Tout est histoire de protocole… le problème étant que si on décide de concevoir une application web dynamique pour manipuler le jukebox, seuls des appels via AJAX ou WebSockets sont possibles. Ce qui implique une solution de "passerelle" entre le port Série du Jukebox et le monde réseau Ethernet et même web (HTTP) :

CAC-V3000 <---> ???? <---> Navigateur web

Matériellement parlant

3 solutions sont possibles :

Il existe des boîtiers spéciaux, appelés des « serial servers » ou « serial over IP » mais ils sont hors de prix et propriétaires.
Avec un Arduino : il existe des shields "Ethernet". Ce dernier pouvant faire donc office de serveur HTTP, très bon tutoriel pour manipuler les librairies Serial et Ethernet sur OC : Ce serait la solution la plus efficiente. Malheureusement son prix est élevé :
◦ [url=https://boutique.semageek.com/fr/513-arduino-ethernet-shield-2-8058333490328.html]https://boutique.semageek.com/fr/513-arduino-ethernet-shield-2-8058333490328.html
◦ https://www.sparkfun.com/products/11166
Avec un Raspberry Pi :
◦ Installer une Raspbian
◦ Utiliser le GPIO ou un adaptateur USB-Série de type FTDI/PL-2303 pour y connecter le Pioneer.
◦ Avantage : utilitaires minicom & picocom à disposition pour debug.

Solution matérielle retenue : Raspberry Pi 1 B+ (en stock).

Logiciellement (avec le Raspberry Pi)

Plusieurs solutions sont possibles :

ser2net

http://techtinkering.com/2013/04/02/connecting-to-a-remote-serial-port-over-tcpip/

C'est un démon qui sous Linux permet de « rerouter » un port série /dev/ttyUSB0 vers un socket TCP. Testé avec succès, mais hélas ne convient par pour des appels HTTP, ser2net travaille de façon brute. C’est parfait pour du Telnet (Putty / MobaXterm) mais ça ne fait pas serveur web.

Script "pivot" en PHP

Méthode sale du pauvre qui fonctionne, mais pas top. Installation d'une Rasbian, de apache2 et de PHP7.0. Essai avec un script PHP maison (ici scmd.php – SingleCoMmanD) se charge de prendre une commande (par exemple 1PS?A) en paramètre d’URL (méthode GET) et de l’écrire sur le port série. Ensuite on lit le port série, récupère la ligne de réponse 1PSXXXXXXXX et renvoie le résultat. Avantage : hyper facile à mettre en œuvre. Inconvénient : Très lent. Les tests montrent un temps de réponse de 300 à 420ms de latence pour traiter une commande.

La réponse met plus de 400ms à arriver ce qui est trop long même en ayant optimisé le code au maximum. Ce qui posera souci pour l’affichage du temps (écoulé, restant). Il est à signaler que localement via les outils picocom ou minicom ce temps n’est pas observé, la réponse est instantanée même à 9600 bauds par seconde.

Le problème provient à la fois de Apache (qui lance un processus PHP à chaque fois pour chaque appel de page) mais aussi de PHP lui-même : on ne peut pas conserver en mémoire des objets persistants, notamment la connexion au port série. De ce fait à chaque appel de scmd.php on doit rouvrir le port série et le refermer, ce qui explique ce délai. PHP est donc à oublier. Il faut trouver un logiciel de type serveur web qui accepte d’avoir une connexion persistante vers le port série.

Script "pivot" en nodeJS

Installation de Node.JS et des modules ws et serialport. :

Tant qu'on y est autant passer pas les websocket plutôt que de renvoyer une "pseudo-page" de réponse texte. Les essais semblent nettement plus concluants, on tombe à moins de 55ms. Cette voie est donc à suivre sans hésiter.

Il n'y a plus qu'à blinder le code (try/catch), ajouter quelques contrôles, ajouter un timeout pour l'attente du port série, tout angliciser et JSONifier le tout. To be continued...

Mise à jour le 18/10/2018

J'ai essayé de comprendre pourquoi PHP pouvait être aussi lent. Pour cela j'ai comparé avec un vrai PC (plutôt que le RPi). Ce sont les mêmes scripts installés sur les deux machines. Dans les captures d'écran suivantes, l'IP 192.168.0.6 correspond au Rasbperry Pi. L'IP 192.168.0.4 correspond au Thinkcentre M91p sous un Debian 9.5 que j'ai utilisé pour mes essais. Pour commencer j'ai activé opCache sur le Raspi, mais hélas cela ne fait pas mieux :

On voit le nombre de cache hits grossir mais hélas toujours 320ms. Idem avec PHP-FPM (FastCGI). Au final j'ai trouvé, je me suis fait trollé par le Prolific PL-2303. Car avec le Thinkcentre je retrouve exactement cette même latence en PHP quand le Pioneer est relié via cet adaptateur USB Prolific (/dev/ttyUSB0). J'ai donc essayé avec le port série du PC legacy de la carte mère (/dev/ttyS0), et bizarrement les temps sont nettement plus courts (81ms VS 380ms) :

Cette latence "d'ouverture du port" doit certainement provenir du pilote pl2303 lui-même. Au final cela n'a d'importance que pour une version PHP du service offert, cela ne change en rien pour nodeJS puisque le port reste ouvert pour chaque requête. La version nodeJS étant plus puissante et simple à implémenter c'est celle qui sera conservée pour développer l'application.

Reste à tester :

Si cette latence est présente aussi sur d'autres adaptateurs avec des puces FTDI.
Dans le cas d'un Raspi : savoir si le port UART interne via le GPIO fait la même chose, mais il faut un module MAX232 pour convertir de TTL vers RS232 (+-12V) et inverseur pour tester.

Dans tous les cas cela posera problème pour le Raspberry Pi si je dois héberger la base de données Postgres plus l'application web dessus, et pas sûr que les 512Mo tiennent. Même avec un overclock à 900Mhz le script nodeJS met plus de 12 secondes à s'initialiser et à être prêt. Alors que c'est instantané sur le Pentium G630. Visiblement c'est connu. Un passage à la version 3 voire carrément y mettre un vrai PC sera nécessaire. Sinon il faudra le cantonner à un rôle de pivot.

Un petit schéma fait avec LibreOffice Draw :

Mise à jour le 29/10/2018

J'ai reçu mes petits achat d'eBay. Après quelques essais il s'avère que la latence observée "d'ouverture de port" avec l'adaptateur USB Prolific PL2303 ne se retrouve pas avec un adaptateur du même type USB-RS232C équipé d'un FTDI FT232R. Idem avec le port interne du Raspberry Pi B+ (/dev/ttyAMA0) équipé du module MAX232 (TTL <-> RS232). La latence observée est donc imputable aux adaptateurs aux puces Prolific. Fin de l'enquête.

Suivi consommation électrique compteur EDF Linky (Partie 2)

Tue, 02 Oct 2018 20:04:00 +0200

Après la mise en place du Raspi les problèmes surviennent rapidement. LE gros souci : il ne devient plus accessible via SSH sur son adresse IP au bout d'une heure ou le lendemain, un délai aléatoire. Hum bizarre car il répond au ping. Ce qui signifie que le Raspi n'a pas décroché du Wi-Fi. Par contre impossible d'initier une connexion SSH. Il se trouve qu'un jour je suis arrivé à temps pour comprendre :

Le processus SSH n'a plus de mémoire pour se forker (générer un autre processus à partir de lui-même) et n'arrive donc pas à gérer les arrivants sur le port 22. Ici je suis arrivé presque à temps, dans la capture d'écran c'est cette fois le processus bash qui n'arrive pas à lancer les commandes. La RAM est saturée. Le message est limpide. Impossible de lancer une commande pour savoir ce qu'il se passe. Un reboot violent via alimentation/reset est malheureusement nécessaire dans ces cas là afin de reprendre la main. Au reboot j'ai vite compris :

Un script PHP se lance toutes les minutes pour relever la consommation instantanée, ce qui est normal, mais le script ne se termine jamais. Les processus PHP finissent ainsi par s'empiler (00h57, 00h58, 00h59...) et saturer la mémoire au bout d'un moment.

Alors pourquoi le script ne se termine pas ? En fait il y a une petite faille dans le script PHP.

En ligne 7 on essaie d'ouvrir le device /dev/ttyS0.
En ligne 8 on vérifie que le device a pu être ouvert (création réussie d'un FileHandle), le cas d'erreur est ici bien géré. En cas de problème, si le périphérique est indisponible ou inexistant on termine l'exécution avec le message " not found".
Le problème se situe à la ligne 9, une boucle lit ce qui arrive sur le port série, caractère par caractère, tant que le fanion de fin de trame (chr 2 - STX) n'arrive pas. Ceci afin de démarrer la vraie lecture uniquement à partir de la trame suivante qui elle sera complète. On ignore la trame "courante". Sauf que si rien n'arrive sur le port série, ce caractère n'est jamais trouvé et le script PHP se retrouve à attendre bêtement à l'infini un STX qui n'arrive jamais.

La solution de contournement consiste à placer un timeout sur la commande afin de limiter son temps d'exécution. Cela tombe bien puisqu'une commande existe sur linux pour cela : timeout.

Il n'y a qu'a demander à killer le process (signal n°9 = SIGKILL) au bout de 15 secondes. 15 secondes étant suffisantes pour que le Raspi ait le temps de lire une trame complète et de jouer sa requête INSERT sqlite. On peut éventuellement mettre 20, 30 voire 40 secondes. De ce fait, au pire dans ce cas, les données ne rentrent pas dans la base sqlite mais le système n'est pas pollué/contaminé.

Mais pourquoi cela arrive ? Et bien en effet à de multiples reprises j'ai pu constater l’absence de données arrivant sur le port série de manière aléatoire :

On a rien du tout, j'ai stoppé avec CTRL-C.

C'est quoi ce binz ? Au début je pensais à une connectique foireuse entre le Linky et le module PiTInfo de Charles. Mais au multimètre (je n'ai pas d'oscilloscope portable) ça fluctue bien sur la broche RXD du GPIO. Le problème n'est donc pas matériel, le signal arrive bien au Raspi. Mais alors qu'est-ce que c'est que ce bordel ? J'ai cherché sur le web. J'ai trouvé qu'il fallait se méfier de la vitesse du VPU et du CPU car elle avait une influence sur la bonne tenue de route du port UART intégré. En effet j'avais émis l'hypothèse qu'au bout d'un moment les fréquences devaient varier selon la charge du CPU et que donc, le port déraillait à cause de cela.

Par conséquent j'ai joué un peu avec le gouverneur selon les modes (powersave, performance, ondemand) via une commande jouée au boot via /etc/rc.local et donner une fréquence fixe au CPU. Bilan : idem. Rien sur port série 9 fois sur 10 au démarrage ou alors ça marche 1 heure et puis plus rien. En fait vous aurez beau descendre le VPU à 250Mhz ou utiliser n'importe quel rituel de sorcellerie, c'est exactement pareil. J'ai trouvé la réponse ici. La faute en est au Raspi lui-même. En résumé : le SOC Broadcom embarque deux ports/modules UART implémentés matériellement de manière différentes (pages 10 & 175), l'un intitulé "mini-uart" (fonctionne à base d'un logiciel qui émule) et l'autre nommé "PL011" (circuit matériel réel).

Le premier est une grosse daube :

Citation :

The second serial port you will see referred to as the “mini uart” and lives at /dev/ttyS0. It also calculates it’s bit timing’s from the CPU cores frequency and if the CPU is under heavy load it can corrupt the serial communications. Not good.

Citation :

Relevant differences between PL011 and mini UART
The mini UART has smaller FIFOs. Combined with the lack of flow control, this makes it more prone to losing characters at higher baudrates. It is also generally less capable than the PL011, mainly due to its baud rate link to the VPU clock speed.
The particular deficiencies of the mini UART compared to the PL011 are :
No break detection
No framing errors detection
No parity bit
No receive timeout interrupt
No DCD, DSR, DTR or RI signals

Dans le cas du Raspi Zero Wireless, j'avais désactivé la console et activé le module "mini-uart". C'est lui qui par défaut est relié aux broches du GPIO. Il est ainsi disponible sur /dev/ttyS0, c'est celui que j'ai utilisé au début. Le PL011 est lui utilisé par la puce Bluetooth par défaut, "disponible" sur /dev/ttyAMA0. Si on veut utiliser le PL011 plus costaud sur les broches du GPIO il faut les échanger (re-router) avec les directives overlay pi3-disable-bt & pi3-miniuart-bt. Une fois cela fait, il faut utiliser /dev/ttyAMA0 dans les scripts.

Et voilà fini le port série qui freeze quand ça lui chante et ne retourne plus de données. Ne pas hésiter aussi à placer une réinitialisation à chaque boot dans /etc/rc.local :

Code BASH :

stty -F /dev/ttyAMA0 1200 sane evenp parenb cs7 -crtscts

Suivi consommation électrique compteur EDF Linky avec Raspberry Pi Zero W

Fri, 21 Sep 2018 05:37:00 +0200

C'est un petit projet qui date un peu auquel je ne m'étais jamais attelé. Connecter un Raspberry Pi au compteur EDF. J'avais avant le modèle blanc et bleu avec un afficheur LCD. Depuis quelques mois c'est le sulfureux Linky qui trône au dessus du tableau électrique. Comme l'ancien, ce compteur possède une sortie dite de "téléinformation" coté client. Une sorte de port informatique à relier à un ordinateur pour obtenir des informations avec protocole UART-TTL ("série"). Autant dire de suite que je n'ai rien inventé, j'ai juste appliqué une petite recette que vous pourrez retrouver sur ce site : http://www.magdiblog.fr/gpio/teleinfo-edf-suivi-conso-de-votre-compteur-electrique/ ou sur le blog de Charles (créateur du shield). Recette suivie également par Pierre Dandumont.

Attention il existe deux protocoles de communication, le mode historique (celui que j'ai) et le mode standard. N'hésitez pas à regarder ces liens :

Choix du Raspi

Comme vous le savez sans doute il existe beaucoup de versions différentes du Raspberry Pi. Le plus adapté à cet usage est bien sûr le modèle zéro. Pas la peine d'avoir plein de ports USB, pas besoin de multi-cœurs, pas besoin de sortie son. L'objet devant être le plus discret possible, moins il prend de place et mieux c'est. Le modèle zéro est disponible en plusieurs versions. La plus intéressante étant la version Zero W qui embarque le Bluetooth et le Wi-Fi en intégré. L'appareil est donc accessible à distance sans fil et sans avoir à devoir bricoler une interface réseau ou acheter un dongle USB-Ethernet ou Wi-Fi.

Captation des données & Module

Pour capter les données du compteur, il y juste à lire les données arrivant d'un port série (broche RXD). Il existe deux matériels disponibles pour lire les données du compteur depuis un RPi :

soit depuis le port UART intégré au connecteur GPIO
soit depuis un dongle USB contrôleur UART indépendant

J'ai opté pour la première solution qui est plus classe que de passer par le port USB dans le cas d'un modèle Zéro. Car cela réclame un fil adaptateur micro-USB qui pendouille. Pour les autres modèles 1/2/3 à vous de voir. Dans ce cas il faut le "header" (les broches GPIO à souder soi-même). J'ai acheté le module (shield) PiTInfo de Charles disponible sur Tindie. Il consiste uniquement à un petit PCB rouge :

Concernant la solution via USB, c'est la même chose mais avec un FT230XS qui fait pont USB-UART :

Choix du stockage des données

Le RPi peut dans ce cas être utilisé de plusieurs façons, en lui confiant plus ou moins de tâches à réaliser. Est-il simplement un lecteur de port série et envoyer ce qu'il lit ailleurs ? Doit-il stocker les données collectées en local ? Doit-il intégrer lui-même un site ou une interface de restitution des données ?

Mode IoT actif : le Rpi capte les données de manière active : lecture les données de téléinformation déclenchée via crontab locale et envoi des informations dans une base distante stockée ailleurs sur un serveur local ou internet via appel webservice.
Mode IoT passif : le Rpi capte les données de manière passive : lecture des données de téléinformation sur demande et restitue les données via une connexion distante via SSH ou appel webservice depuis un serveur local ou internet.
Mode serveur : le RPi capte les données de téléinformation déclenchée via crontab locale, stocke les données en local (sur carte SD) et dispose d'un serveur web interne pour l'interroger à distance. Tout se fait sur le RPi. Rien n'est stocké ailleurs.

Pour le moment, c'est la troisième solution que j'ai choisi car c'est la plus simple sinon il faut éparpiller l'application.

Ajout d'une prise au tableau électrique

Un problème se pose, comment alimenter le RPi ? N'ayant pas de prise à proximité, j'ai opté pour la solution la moins chère (4 euros) : ajouter une prise au tableau électrique.

Il existe des solutions plus élégantes à base de modules d'alimentations sur rail DIN mais c'est un peu plus cher. Maintenant que je sais que ça marche, cette solution me tente pour plus tard. Car cela permettrait d'enfouir le RPi. C'est chose faite en novembre 2018.

Préparation de la carte microSD

Bon je ne vais pas trop m'étendre sur cette étape, vue, revue, et re-revue maintes fois sur le web. Prendre le fichier image de la distribution raspbian disponible sur le web et l'installer sur une carte microSD.

Premier démarrage

On boot dessus. Pour cela il faut relier un écran et un clavier. 3 câbles : alimentation en micro-USB, clavier en micro-USB et vidéo en mini-HDMI :

Il est vivant :

Login OK. Utilisateur = "pi" et mot de passe = "raspberry". Attention le clavier est en qwerty il faut donc taper "rqspberry".

Configuration locale

Avant de rendre le RPi autonome il faut le configurer. Déjà passer le clavier en français :
https://raspberrypi.stackexchange.com/questions/10060/raspbian-keyboard-layout

Ensuite il faut que le RPi se connecte de lui-même au Wi-Fi local :
https://core-electronics.com.au/tutorials/raspberry-pi-zerow-headless-wifi-setup.html

On s’aperçoit que le service ssh est désactivé au démarrage. Il faut donc l'activer. Son démarrage est OK.

Ensuite tant qu'on y est un récupère l'adresse MAC de l'interface wi-fi wlan0 :

Reboot final pour test, le RPi a bien récupéré son adresse 192.168.0.5 !

Installation au compteur

Maintenant que le RPi est autonome, il reste à le poser (coller) au disjoncteur général 500mA.
Ok c'est moche, mais ça fonctionne.

Configuration à distance

Il reste encore à peaufiner quelques détails... maintenant on fait ça tranquille via SSH.

On vérifie que le RPi peut accéder au réseau local et à internet.

On configure les fichiers config.txt et cmdline.txt pour activer le port série du GPIO :
https://spellfoundry.com/2016/05/29/configuring-gpio-serial-port-raspbian-jessie-including-pi-3/

Tests de lecture du port série

Après reboot, il y a bien 2 ports série, un ttyS0 qu'il faudra utiliser et le ttyAMA0 pour le Bluetooth.
Un petit essai avec picocom avec une vitesse de 1200 bauds, 7 bits de données, parité paire, aucune gestion du flux de données.

On voit des infos texte débouler du compteur. CTRL-A et CTRL-Q pour quitter picocom.
Si on laisse défiler, on remarque le compteur crache en permanence le même pavé/bloc de 11 lignes séparé par le caractère ASCII n°2 = STX (Start of Text) :

Installation de l'application (scripts PHP)

Après avoir installé Apache2 et PHP 7.0, il faut ensuite déposer les scripts PHP sur le RPi et placer une exécution automatique en crontab. On relève la consommation toutes les minutes 24h/24 7j/7.

On vérifie que les données sont bien stockées dans la base sqlite3 :

En cas de problème, les logs d'erreurs peuvent donner des pistes :

Encore quelques réglages...

Reste à configurer la timezone via l'outil raspi-config :

On installe également NTP pour conserver le RPi toujours à l'heure :

Ne pas oublier aussi de désactiver la mise en veille du Wi-Fi : https://www.raspberrypi.org/forums/viewtopic.php?t=194619

Un outil supplémentaire...

On peut également installer phpliteadmin pour administrer la base sqlite3 à distance via navigateur à la manière d'un phpMyAdmin :

Tadaaaa !

Ça marche. Les graphiques sont construits par la bibliothèque JS Charts de Google. Un accès au net est donc nécessaire pour générer les graphiques.

J'ai l'impression que ça marche moyen (que font ici les années 2030, 2040, 2050 ???). Et j'ai toujours le décalage de l'heure dans les données restituées en web alors que bash me donne la bonne heure système. Les scripts sont prévus pour PHP 5.0 et j'ai installé la 7.0. Cela reste à creuser.

MAJ du 2 octobre 2018

Résolution de problèmes de stabilité du port série. Bascule de module UART.

Récupération des logs OVH (script Shell)

Fri, 20 Jul 2018 20:49:00 +0200

Un script qui automatise la récupération des logs sur un site hébergé mutualisé linux chez OVH en offre perso. Il automatise la connexion à l'URL des logs d'OVH : logs.ovh.net.

En premier : le script env.sh positionne l'environnement OVH avec quelques variables Shell. Toutes ses variables ne servent pas ici. C'est un script qui mutualise tout le nécessaire d'authentification pour plusieurs scripts que j'ai. Les valeurs sont à utiliser/remplacer sont :

Code BASH :

 
export OVH_COURRIEL="mail@fai.fr" # Destinataire courriel rapport
# LOGS
export OVH_USER="xxxxxxx-ovh" # Code client (XXXXXXXX-OVH)
export OVH_PASSWORD="xxxxxxxxxxxxxxxxxxx" # Mot de passe compte OVH

En second : le script backup_log.sh télécharge via la commande curl les logs nécessaires au nombre de trois (access, error et out), puis envoie un courriel récapitulatif. Le script peut prendre comme paramètre :

soit "yesterday" pour récupérer les logs de la veille en flux continu quotidien (comportement par défaut si aucun paramètre donné)
soit "immediate" pour récupérer les logs courants (situation urgente)
soit une date au format "DD/MM/YYYY" pour récupérer les logs d'une date précise (rattrapage)

Crontab de lancement :

Code BASH :

 
# Script de sauvegarde des logs de la veille chez OVH
00 06 * * * cd /docs/taverne/scripts/; . ./env.sh; ./backup_log.sh >> /dev/null 2>&1

Exemple du corps de courriel :

Citation :

--------------------------------------------------------------
Récupération débutée le 25-07-2018 @ 06:00:01
--------------------------------------------------------------
Création du répertoire de stockage si besoin...
Type de lancement du script : yesterday
Récupération des logs chez OVH...
Le fichier n'est pas présent. Téléchargement nécessaire.
Téléchargement via CURL vers /docs/taverne/site_logs/access_logs/2018-07-24-jonathandupre.fr.log.gz
Le fichier n'est pas présent. Téléchargement nécessaire.
Téléchargement via CURL vers /docs/taverne/site_logs/error_logs/2018-07-24-jonathandupre.fr.log.gz
Le fichier n'est pas présent. Téléchargement nécessaire.
Téléchargement via CURL vers /docs/taverne/site_logs/out_logs/2018-07-24-jonathandupre.fr.log.gz
Dézippage des logs reçus...
Fichier dézippé OK.
Fichier dézippé OK.
Fichier dézippé OK.
Contrôle des logs reçus...
Présence du fichier -rw-rw-r-- 1 jonathan jonathan 11525232 juil. 25 06:00 /docs/taverne/site_logs/access_logs/2018-07-24-jonathandupre.fr.log.
Présence du fichier -rw-rw-r-- 1 jonathan jonathan 1370 juil. 25 06:00 /docs/taverne/site_logs/error_logs/2018-07-24-jonathandupre.fr.log.
Présence du fichier -rw-rw-r-- 1 jonathan jonathan 98606 juil. 25 06:00 /docs/taverne/site_logs/out_logs/2018-07-24-jonathandupre.fr.log.
--------------------------------------------------------------
Récupération terminée le 25-07-2018 @ 06:00:02
--------------------------------------------------------------

Importer les sessions de PortaPutty vers le registre (script Perl)

Fri, 18 May 2018 17:33:00 +0200

Petit cas rencontré au travail. Nous utilisons de temps en temps PuTTY pour administrer des serveurs en SSH depuis des postes Windows. Seulement il y a quelques années (2010) j'ai récupéré un poste sur lequel est installé "PortaPuTTY" et je l'ai utilisé comme tel au début. Mais en fait il existe deux logiciels PuTTY, le normal officiel classique et un modifié qui est dénommé "PortaPuTTY". Le second, comme son nom l'indique, est un PuTTY portable, abandonné depuis par son auteur. La différence entre les deux est simple : le PuTTY classique enregistre les sessions et leurs paramètres dans la base de registre Windows. Base de registre qui n'est pas nomade ou portable elle fait partie de Windows. Même si cela reste exportable/importable à la main.

Le second enregistre les sessions dans des fichiers texte plats à coté du .exe. De ce fait on "emporte" les sessions avec son PortaPuTTY.

Sauf que les logiciels comme SuperPuTTY ou encore MobaXTerm ne permettent pas d'importer les sessions depuis ces fameux fichiers texte plats générés par PortaPuTTY, ils vont tous rechercher en base de registre.

Exemple avec MobaXTerm :

Exemple avec SuperPuTTY :

Je ne voulais pas tout ressaisir à la main et comme le problème peut se poser ailleurs j'ai créé un script Perl qui se nomme portaputty2registry.pl, testé fonctionnel avec Perl en version 5.8 (c'est vieux !). Le but du script est de scanner les fichiers d'un dossier de sessions PortaPuTTY, de récupérer tous les paramètres des sessions des fichiers et de créer un un fichier .reg à importer directement dans la base de registre. Le hic étant que les valeurs sont en décimal coté PortaPuTTY et en hexadécimal (dword) dans un fichier .reg. Sauf que bien évidemment certaines valeurs sont des chaînes de caractère à ne pas convertir (à laisser tel quel). Le script se charge de cela.

Coller le script Perl dans le dossier des sessions (vous pouvez aussi le mettre ailleurs comme le bureau, le script est interactif si aucun paramètre n'est donné en ligne de commande) :

Ouvrir une invite de commande dans ce dossier :

Lancer le script :

Je réponds 'oui' ici :

Le traitement des fichiers trouvés est terminé :

Le fichier .reg est bien présent et valide dans sa structure :

Il ne reste plus qu'à l'importer :

Un petit tour avec regedit.exe pour vérifier cela :

All is alright. Maintenant reste à importer les données.