Sauvegarde FTP

Ce sujet contient 64 réponses, 3 participants et a été mis à jour pour la dernière fois par Richard, le il y a 2 années et 8 mois.

Post

- 29 décembre 2022 à 18 h 38 min
Richard
Participant
Bonjour

Via la fonction FTP vous pouvez sauvegarder les .dat et les .csv du TIC et des sondes TMP.

Par contre pour les compteurs pulses vous ne proposer que les .dat pas les .CSV

Cela semble identique pour les pinces ( je ne peux pas voir car pas de pinces)

Peux être que j’ai un problème dans ma config, dans le cas contraire pouvez vous proposez la possibilité de sauvegarde des .csv pour les compteurs pulse et pinces.

Cordialement

0
0

Vous lisez 63 fils de discussion

Replies

- - 5 janvier 2023 à 7 h 15 min
 Richard
 Participant
 Bonjour.
 
 Je reviens sur le sujet quelqu’un a t il une réponse voir une solution à me donner ou ceci ne peux être résolu que par @ Nicolas.
 
 Cordialement
 
 0
 0
- - 10 janvier 2023 à 18 h 32 min
 Richard
 Participant
 Bonjour.
 
 Je reviens encore sur le sujet.
 
 Personne n’utilise la fonction ??
 
 @Nicolas avez vous une réponse et une solution à me donner.
 
 Bonne soirée
 
 0
 0
- - 11 janvier 2023 à 4 h 53 min
 cdlog2
 Modérateur
 Bonjour et Très Bonne Année 2023 à Tous,
 
 @Richard, Concernant votre question sur le Trf FTP, je ne peux pas y répondre car je n’utilise pas cette fonction et je n’en ai aucune expérience d’usage.
 
 Il faut déjà voir si vous avez des fichiers CSV présents dans votre dossier Cpt.Pulse >> /PLS/(année).
 Exemple pour lister les CSV des Cpt.Pulses enregistrés depuis cette nouvelle année 2023 /PLS/2023/
 Si aucun fichier n’est présent, vérifier si l’Option création CSV est bien active dans la config Pulse.
 
 Lorsque la fonction TRF FTP est activée, elle vous permet à priori de recevoir les fichiers Pulses présents du Jour Courant si l’Option TRF Cpt.Pulse est bien activé dans la Page. Je suppose que cela concerne aussi les fichiers CSV.
 Donc il faut pour recevoir ces fichiers Pulses, qu’ils aient été enregistrées dans le Courant de la Journée soit entre 0h30 à 23h30
 
 Si vous avez fixé l’heure du transfert FTP journalier à 0h10 par exemple, il est évident que vous ne recevrez jamais aucun fichier CSV, car à cette heure en début de journée il n’y aura aucun fichier CSV enregistré de si tôt de la Journée.
 Pour être sur de récupérer tous les fichiers journalier, il faut prévoir une heure de transfert défini vers la fin de soirée.
 
 Si effectivement la fonction FTP ne vous envoie pas les fichiers CSV des Pinces et des Pulses, s’ils existent ! cela peut être dû à un Bug
 Côté Serveur, donc seulement Nicolas peut y remédier si effectivement cela est confirmé.
 
 Autrement il y a une autre solution pour récupérer de façon automatique les fichiers CSV qui vous intéresse.
 
 Si vous avez un Serveur domotique annexe externe et que vous avez quelques talent en programmation,
 vous pouvez programmer un Script dans ce Serveur pour extraire les fichiers CSV du WES qui vous intéresse par envoie de requête au WES périodiquement à votre choix.
 
 Exemple de requêtes à envoyer au WES, pour récupérer la liste des fichiers CVS présents dans ce mois de janvier de l’année 2023:
 
 http://login:motpasse@192.168.x.x/AJAX.CGX?CSVY=2023&CSVM=1&CSVS=2
 
 http://login:motpasse192.168.1.20/BOOTSTRAP5/CGX/FILECSV.CGX
 
 La 1ere requête demande au WES de préparer une liste de fichier CSV avec les critères Calendaire que vous souhaitez.
 Cette requête se décompose ainsi : (IP WES) /AJAX.CGX ? CSVY=(année) & CSVM=(mois) & CSVS=(type) ou (année) et (mois)
 correspond à l’année et mois de création des CSV que vous souhaitez voir, et (type) détermine le type des CSV soit :
 
 si CSVS = 0 fait REF. aux CSV TeleInfo,
 si CSVS = 1 fait REF. aux CSV Pinces,
 si CSVS = 2 fait REF. aux CSV Pulses
 si CSVS = 3 fait REF. aux CSV Températures.
 
 Donc pour lister les CSV des Cpt.Pulse de ce mois de janvier 2023 la requête sera formaté : (IP WES) /AJAX.CGX ? CSVY=2023 & CSVM=1 & CSV=2 (sans aucun espace bien sur)
 
 La 2eme requête (IP WES) /WEBPROG/CGX/FILECSV.CGX permet de demander au Serveur de vous envoyer la liste des fichiers CSV qu’il à crée répondant aux critères de la 1ere requête.
 
 Le Serveur va vous renvoyer les Datas sous le format XML.
 ( ci-dessous la liste des CVS Pinces crée cette année dans mon WES )
 
 Les DATA XML reçus en retour de la 2eme requête sur /WEBPROG/CGX/FILECSV.CGX
 Data Brut reçu :
 
 <form>
 <html>
 <id>SRV_date</id>
 <value>Mercredi 11 Janvier 2023</value>
 </html>
 <html>
 <id>SRV_time</id>
 <value>00:41</value>
 </html>
 <html>
 <id>file_csv</id>
 <value>
 <tr bgcolor=#B8C7D3><th>Nr.</th><th>Nom fichier</th><th style= »text-align:center »>Taille</th><th style= »text-align:center »>Dernière modification le</th></tr><tr><td>1.</td><td align=left>PC-01-01.csv</td><td align=right>90.041</td><td align=right>01.01.2023 – 23:59</td></tr> <tr><td>2.</td><td align=left>PC-01-02.csv</td><td align=right>89.481</td><td align=right>02.01.2023 – 23:59</td></tr> <tr><td>3.</td><td align=left>PC-01-03.csv</td><td align=right>89.266</td><td align=right>03.01.2023 – 23:59</td></tr> <tr><td>4.</td><td align=left>PC-01-04.csv</td><td align=right>89.029</td><td align=right>04.01.2023 – 23:59</td></tr> <tr><td>5.</td><td align=left>PC-01-05.csv</td><td align=right>89.330</td><td align=right>05.01.2023 – 23:59</td></tr> <tr><td>6.</td><td align=left>PC-01-06.csv</td><td align=right>89.439</td><td align=right>06.01.2023 – 23:59</td></tr> <tr><td>7.</td><td align=left>PC-01-07.csv</td><td align=right>89.452</td><td align=right>07.01.2023 – 23:59</td></tr> <tr><td>8.</td><td align=left>PC-01-08.csv</td><td align=right>89.499</td><td align=right>08.01.2023 – 23:59</td></tr> <tr><td>9.</td><td align=left>PC-01-09.csv</td><td align=right>89.481</td><td align=right>09.01.2023 – 23:59</td></tr> <tr><td>10.</td><td align=left>PC-01-10.csv</td><td align=right>89.451</td><td align=right>10.01.2023 – 23:59</td></tr> <tr><td>11.</td><td align=left>PC-01-11.csv</td><td align=right>2.661</td><td align=right>11.01.2023 – 00:41</td></tr>
 </value>
 </html>
 </form>
 
 Extraction de la Liste DATA XML reçue, c’est la ZONE XML au milieu donnant les infos des Fichiers CSV présent à Date à mettre en forme
 Data Brut reçu :
 
 <tr bgcolor=#B8C7D3><th>Nr.</th><th>Nom fichier</th><th style= »text-align:center »>Taille</th><th style= »text-align:center »>Dernière modification le</th></tr><tr><td>1.</td><td align=left>PC-01-01.csv</td><td align=right>90.041</td><td align=right>01.01.2023 – 23:59</td></tr> <tr><td>2.</td><td align=left>PC-01-02.csv</td><td align=right>89.481</td><td align=right>02.01.2023 – 23:59</td></tr> <tr><td>3.</td><td align=left>PC-01-03.csv</td><td align=right>89.266</td><td align=right>03.01.2023 – 23:59</td></tr> <tr><td>4.</td><td align=left>PC-01-04.csv</td><td align=right>89.029</td><td align=right>04.01.2023 – 23:59</td></tr> <tr><td>5.</td><td align=left>PC-01-05.csv</td><td align=right>89.330</td><td align=right>05.01.2023 – 23:59</td></tr> <tr><td>6.</td><td align=left>PC-01-06.csv</td><td align=right>89.439</td><td align=right>06.01.2023 – 23:59</td></tr> <tr><td>7.</td><td align=left>PC-01-07.csv</td><td align=right>89.452</td><td align=right>07.01.2023 – 23:59</td></tr> <tr><td>8.</td><td align=left>PC-01-08.csv</td><td align=right>89.499</td><td align=right>08.01.2023 – 23:59</td></tr> <tr><td>9.</td><td align=left>PC-01-09.csv</td><td align=right>89.481</td><td align=right>09.01.2023 – 23:59</td></tr> <tr><td>10.</td><td align=left>PC-01-10.csv</td><td align=right>89.451</td><td align=right>10.01.2023 – 23:59</td></tr> <tr><td>11.</td><td align=left>PC-01-11.csv</td><td align=right>2.661</td><td align=right>11.01.2023 – 00:41</td></tr>
 
 Extraction de la ZONE XML,
 Le 1er index, le 1er sous ensemble de la ZONE XML défini les champs de chaque élément des Infos pour un fichiers CSV
 
 Data remis en forme : Nr. Nom fichier Taille Dernière modification le
 Data Brut reçu :
 
 <tr bgcolor=#B8C7D3>
 <th>Nr.</th>
 <th>Nom fichier</th>
 <th style= »text-align:center »>Taille</th>
 <th style= »text-align:center »>Dernière modification le</th>
 </tr>
 
 Ensuite le 2eme index, le 2eme sous ensembles XML contenant les infos détaillées du 1er fichiers de la Liste
 Data remis en forme : 1. PCE/2023/PC-01-01.csv PC-01-01.csv 90.041 01.01.2023 – 23:59
 Data Brut reçu :
 
 <tr>
 <td>1.</td>
 <td align=left>
 PCE/2023/PC-01-01.csv« >PC-01-01.csv
 </td>
 <td align=right>
 90.041</td>
 <td align=right>01.01.2023 – 23:59</td>
 </tr>
 
 Voici en index 3, le 3 eme sous ensemble, les Infos du 2eme fichier CSV de la liste
 Data remis en forme : 2. PCE/2023/PC-01-02.csv PC-01-02.csv 89.481 02.01.2023 – 23:59
 Data Brut reçu :
 
 <tr>
 <td>2.</td>
 <td align=left>
 PC-01-02.csv
 </td>
 <td align=right>89.481</td>
 <td align=right>02.01.2023 – 23:59</td>
 </tr>
 
 Suite des Infos des autres fichiers de la Liste
 /// …. //// …. //// ….. /////
 
 Finalement, si vous souhaitez téléharger les CSV de la liste renvoyé par le Serveur
 on peut le faire simplement par envoie séquentiellement pour chaque fichier CSV à télécharger
 via une 3eme requêtes : (IP WES) / URL nom du fichier
 
 exemple pour télécharger le 2eme fichier de la liste ci-dessous :
 Nr. Nom fichier Taille Dernière modification le
 1. PCE/2023/PC-01-01.csv 90.041 01.01.2023 – 23:59
 2. PCE/2023/PC-01-02.csv 89.481 02.01.2023 – 23:59
 
 http://login:@motpasse@192.168.x.x/PCE/2023/PC-01-02.csv
 
 Voila on peut facilement créer une moulinette pour télécharger les fichiers qui vous intéresse,
 moyennant quelques lignes de programme dans un Script.
 
 Cordialement
 Christian
 
 0
 0
- - 11 janvier 2023 à 5 h 08 min
 cdlog2
 Modérateur
 re : je corrige ce n’est pas http://login:motpasse@192.168.x.x/BOOTSTRAP5/CGX/FILECSV.CGX qu’il faut envoyer pour lire la liste des CSV mais : http://login:motpasse@192.168.x.x/WEBPROG/CGX/FILECSV.CGX
 
 0
 0
- - 11 janvier 2023 à 7 h 24 min
 nicolas_cartelec
 Maître des clés
 Bonjour,
 
 En effet il n’y a que les graphiques pour les pinces et les compteurs d’impulsions pour le moment.
 
 Les fichiers CSV ne servent pas au WES pour les graphiques, vous pouvez les sauvegarder par FTP car le WES fait aussi serveur FTP donc si vous avez un nas vous pouvez automatiser cela.
 
 Je regarderais pour ajouter ces fichiers.
 
 0
 0
- - 11 janvier 2023 à 7 h 57 min
 Richard
 Participant
 Bonjour @cdlog2
 Tous mes vœux à toi aussi.
 Merci pour ce retour.
 Dans un premier temps je développe le FTP du Wes, après je regarderai la solution script.
 
 J’ai bien cette arborescence GRAPH/PLS/2023/01 avec des fichiers du type 011.dat …. 101.dat et 012.dat …. 102.dat et ceci pour mes 4 cpt
 Et un répertoire PLS/2023 avec les fichiers .CSV
 
 Dans la configuration du Cpt pulse j’ai bien les options activer comptage et activer fichier csv à « on »
 Ma sauvegarde est à 8h
 
 Dans le menu FTP la liste des fichiers à transférer est :
 Fichiers Téléinfo
 Fichiers Pince ampèreremétriques
 Fichiers Compteurs d’impulsions
 Fichiers Sonde 1WIRE
 Fichiers Téléinfo CSV
 Fichiers Sonde 1WIRE CSV
 
 J’ai positionné tous les choix à « Tranferer ! » sauf pour « Pince ampèreremétriques » car absente
 Pour l’ensemble de ces choix cela fonctionne bien
 
 Bans le menu FTP vous sauvegarder donc les .dat et les .csv du Téléinfo et des Sondes 1WIRE
 Par contre pour les Compteurs d’impulsions vous ne proposez que les .dat pas les .CSV
 Donc ceci est peux être une raison du manque de sauvegarde
 
 A la commande
 http://login:motpasse@192.168.x.x/AJAX.CGX?CSVY=2023&CSVM=1&CSVS=2
 J’ai ce retour
 
 Aucune information de style ne semble associée à ce fichier XML. L’arbre du document est affiché ci-dessous.
 <form/>
 
 Et à la commande
 http://login:motpasse192.168.1.20/BOOTSTRAP5/CGX/FILECSV.CGX
 J’ai ce retour
 
 Erreur 404 – Non Trouvé !
 La requète URL n’a pas été trouvée sur le serveur.
 
 Voici donc mes premières infos et tests.
 
 Bonne journées
 
 0
 0
- - 11 janvier 2023 à 8 h 02 min
 Richard
 Participant
 re
 correction de la commande http://login:motpasse@192.168.x.x/BOOTSTRAP5/CGX/FILECSV.CGX.
 je n’avais pas pris la dernière
 http://login:motpasse@192.168.x.x/WEBPROG/CGX/FILECSV.CGX
 
 Maintenant j’ai ce résultat
 
 Aucune information de style ne semble associée à ce fichier XML. L’arbre du document est affiché ci-dessous.
 
 <form>
 <html>
 <id>SRV_date</id>
 <value>Mercredi 11 Janvier 2023</value>
 </html>
 <html>
 <id>SRV_time</id>
 <value>08:10</value>
 </html>
 <html>
 <id>file_csv</id>
 <value>
 <tr bgcolor=#B8C7D3><th>Nr.</th><th>Nom fichier</th><th style= »text-align:center »>Taille</th><th style= »text-align:center »>Dernière modification le</th></tr>
 </value>
 </html>
 </form>
 
 0
 0
- - 11 janvier 2023 à 8 h 11 min
 Richard
 Participant
 Bonjour @Nicolas
 Merci pour ce retour
 
 Effectivement je peux passer en directe via FTP (chose que je fais pour sauvegarder mon WES)
 
 l’idée et l’ intérêt de la fonction que vous proposer via votre interface FTP et de sauvegarder en automatique l’ensemble de mes datas (au cas ou)
 
 Donc votre proposition d’ajouter ces fichiers m’arrangerait bien.
 
 cette amélioration peux t elle être fourni en bêta dans un premier temps
 
 Cordialement
 
 0
 0
- - 11 janvier 2023 à 15 h 40 min
 cdlog2
 Modérateur
 Bonjour @Richard,
 
 La 1ere requête : 192.168.x.x/AJAX.CGX?CSVY=2023&CSVM=1&CSVS=2 ne vous renvoie rien d’autre que <form/>. qui est le retour de AJAX.CGX qui est un fichier CGX vide qui se trouve à la racine de la SD. C’est tout à fait normal !. On utilise ce fichier CGX vide pour faire des requêtes type CGX au WES qui ne sont pas censé rendre une réponse de la part du Serveur.
 
 Le retour de cette 1ere requête ne vous affiche rien d’autre. Par contre elle demande au Serveur de Préparer la Liste des CSV correspondant aux Critères Calendaires et Type de CSV que vous souhaitez lire : CSVY=2023 CSVM=1 CSVS=2 ==> Année 2023 Mois janvier Type 2 = Pulse.
 
 C’est la 2eme Requête : 192.168.x.x/WEBPROG/CGX/FILECSV.CGX qui demande au Serveur de vous envoyer la liste des Fichiers CSV qu’il à crée au regard de la 1ere Requête.
 
 La réponse du formulaire vide que vous avez reçue avec votre 2eme Requête , signifie que vous n’avez pas de CSV répondant aux Critères demandés lors de l’envoie de votre 1ere Requête.
 
 <form>
 <html>
 .. .. .. .. ..
 <value>
 <tr bgcolor=#B8C7D3><th>Nr.</th><th>Nom fichier</th><th style= »text-align:center »>Taille</th><th style= »text-align:center »>Dernière modification le</th></tr> < C’est ICI que l’on trouve la Liste des CVS présent et répondant aux critères solicités >
 </value>
 </html>
 </form>
 
 Ces deux Requêtes que je fournis, sont celles qui sont utilisées dans la Page WES Graphique & fichiers > Fichiers CVS pour lister les CSV suivant les critères Calendaire et Option sur le type de CSV que vous cochez dans la Page WES.
 
 Si vous demander de lire vos fichier CSV de type Pulse pour le mois de janvier 2023 depuis la Page Fichiers CSV du WES, vous aurez certainement en retour une Liste de CVS vide comme celle rendu par vos requêtes lancées manuellement..
 
 Essayez de demander la liste des CSV Pulse ( CSVS=2) d’une autre Date dont vous êtes certains d’avoir des CSV
 Exemple : Année 2022 / Mois 1 <> 12 depuis la page Fichier CSV du WES,
 
 Puis ensuite vous lancez les deux Requêtes manuellement en donnant pour la 1ere Requête l’Année , Mois et Type que vous avez sollicité depuis la Page WES. Normalement le Serveur va vous retourner un Formulaire rempli avec la même liste des CSV que ceux affichés dans la Page WES.
 
 Cordialement
 
 Christian
 
 0
 0
- - 11 janvier 2023 à 16 h 18 min
 cdlog2
 Modérateur
 re : Comme il faut un certain Temps au Serveur pour lister les CSV présent dans la carte SD et répondant aux critères de la 1ere Requête, lancez la 2eme Requête avec une petite Pause entre ces 2 Requêtes. Une tempo de 2 secondes entre l’envoie des 2 Requêtes serait un Bon Timing.
 
 Si vous lancer la 2eme Requête trop rapidement après la 1ere Requête, il est possible que le Serveur n’ai pas eu le temps de formater la Liste des CSV présent et dans ce cas le Serveur pourrait vous rendre un formulaire Vide !
 
 Cdt
 
 0
 0
- - 11 janvier 2023 à 18 h 52 min
 Richard
 Participant
 re @cdlog
 
 je viens de voir votre dernier post et j’ai relu les autres
 
 Comme vous le savez je ne maitrise pas trop.
 
 Voila je reprends les actions que j’avais fait et déjà je ne suis pas sure d’ avoir pratiqué comme demandé.
 
 Vous avez ecrit « vous pouvez programmer un Script dans ce Serveur pour extraire les fichiers CSV du WES »
 
 Moi j’ai lancé dans une page web
 http://login:motpasse@192.168.x.x/AJAX.CGX?CSVY=2023&CSVM=1&CSVS=2
 
 puis dans une deuxieme page
 http://login:motpasse192.168.1.20/BOOTSTRAP5/CGX/FILECSV.CGX
 
 Je pense que déjà cela n’était pas votre demande car vous parlez de script
 
 Cote serveur je pense que cela ne vas pas le faire.
 J’ai un NAS sous Openmediavault (OMV), j’utilise juste l’interface WEB pour la config et je ne sais pas utiliser linux dans le ssh
 
 N’est t il pas possible de faire un script dans Jeedom (un peu comme le script pour récuperer des infso via le fichier .CGX
 
 Si oui avez vous un modèle à me fournir
 
 Bonne soirée
 
 0
 0
- - 11 janvier 2023 à 23 h 15 min
 cdlog2
 Modérateur
 Bonsoir @richard
 
 En 1er lieu, avez vous bien compris l’interaction de ces 2 requêtes côté Serveur WES ?
 
 Avant d’envisager de faire un Script, avez vous testé ces 2 requêtes directement depuis la barre d’adresse de votre navigateur et avez vous comparé le Formulaire xml rendu par la 2eme requête avec la liste des fichiers CSV affichée dans la page WES > « Fichiers SCV » lorsque vous soumettez les mêmes valeurs calendaire et type >> CSVY=(année) CSVM=(mois) CSVS=2 (Option Pulses)
 
 On peut créer et lancer un script aussi depuis votre NAS que depuis Jeedom.
 Avez vous Python3 installé dans votre NAS ? Si oui cela sera d’autant plus facile de faire un Script Python dans votre NAS, si c’est bien lui qui en final doit sauvegarder ces fichiers CSV.
 
 Pour voir si Python3 est installé dans votre NAS, ouvrez une console SSH et tapez >> python3 -V cela va afficher la version de votre Python si installé.
 
 Comme déjà évoqué, il faut faire une petite pause entre les envoies des 2 requêtes. Il faut laissez le temps au Serveur WES de créer la Liste des CSV sollicitée par la 1ere requête avant de lui demander de vous envoyer cette liste via la 2eme requête.
 
 Cdt
 
 0
 0
- - 12 janvier 2023 à 8 h 48 min
 Richard
 Participant
 Bonjour @cdlog2
 
 j’ai relancer les tests via le navigateur avec une tempo entre les 2 requêtes.
 
 Maintenant j’ai le résultat suivant je retrouve bien des noms de fichier:
 
 <form>
 <html>
 <id>SRV_date</id>
 <value>Jeudi 12 Janvier 2023</value>
 </html>
 <html>
 <id>SRV_time</id>
 <value>08:12</value>
 </html>
 <html>
 <id>file_csv</id>
 <value>
 <tr bgcolor=#B8C7D3><th>Nr.</th><th>Nom fichier</th><th style= »text-align:center »>Taille</th><th style= »text-align:center »>Dernière modification le</th></tr><tr><td>1.</td><td align=left>PL-01-01.csv</td><td align=right>44.565</td><td align=right>01.01.2023 – 23:59</td></tr> <tr><td>2.</td><td align=left>PL-01-02.csv</td><td align=right>44.627</td><td align=right>02.01.2023 – 23:59</td></tr> <tr><td>3.</td><td align=left>PL-01-03.csv</td><td align=right>44.658</td><td align=right>03.01.2023 – 23:59</td></tr> <tr><td>4.</td><td align=left>PL-01-04.csv</td><td align=right>44.658</td><td align=right>04.01.2023 – 23:59</td></tr> <tr><td>5.</td><td align=left>PL-01-05.csv</td><td align=right>44.658</td><td align=right>05.01.2023 – 23:59</td></tr> <tr><td>6.</td><td align=left>PL-01-06.csv</td><td align=right>44.658</td><td align=right>06.01.2023 – 23:59</td></tr> <tr><td>7.</td><td align=left>PL-01-07.csv</td><td align=right>44.658</td><td align=right>07.01.2023 – 23:59</td></tr> <tr><td>8.</td><td align=left>PL-01-08.csv</td><td align=right>44.658</td><td align=right>08.01.2023 – 23:59</td></tr> <tr><td>9.</td><td align=left>PL-01-09.csv</td><td align=right>44.658</td><td align=right>09.01.2023 – 23:59</td></tr> <tr><td>10.</td><td align=left>PL-01-10.csv</td><td align=right>44.658</td><td align=right>10.01.2023 – 23:59</td></tr> <tr><td>11.</td><td align=left>PL-01-11.csv</td><td align=right>44.658</td><td align=right>11.01.2023 – 23:59</td></tr> <tr><td>12.</td><td align=left>PL-01-12.csv</td><td align=right>15.301</td><td align=right>12.01.2023 – 08:12</td></tr>
 </value>
 </html>
 </form>
 
 Pour les tests ssh, PB je ne retrouve pas mon mot de passe (j’avais utilisé à l’installation du NAS après jamais).
 
 Sur Jeedom après recherche web j’ai l’impression qu il y a Python par contre lequel?
 
 Donc est il possible de partir sur cette option.
 
 Cordialement
 
 0
 0
- - 12 janvier 2023 à 13 h 04 min
 cdlog2
 Modérateur
 Bonjour,
 
 Je suppose que vous accédez à l’Admin de votre NAS ? et je suppute que c’est depuis l’Admin du NAS que vous activez SSH ?
 Je suppose que votre Jeedom est installé dans un Raspberry Pi ?
 
 Ou souhaitez vous stocker vos fichier CSV ? dans votre NAS ou dans votre Raspberry Pi ?
 
 Il faut installer le Script Python à l’endroit ou vous voulez archiver vos CSV.
 
 Qu’elle est la version de python dans votre Raspberry Pi ?
 Pour le déterminer c’est la commande que je vous ai déjà donné, sous console SSH tapez : python3 -V (V en majuscule). Si python3 est installé vous verrez sa version sinon une erreur et dans ce cas il faut l’installer :
 
 Pour l’installer tapez les commandes SSH ci-dessous ligne par ligne : répondre Oui « O » si on vous pose une question : Attendre la fin d’un processus avant de lancer la commande suivante.
 
 sudo apt-get update
 sudo apt-get install python3
 sudo apt-get install python3-pip
 sudo pip install virtualenv
 virtualenv -p python3 venv
 source venv/bin/activate
 python3 -m pip install python-dev-tools –user –upgrade
 
 Vérifier que Python3 est bien installé >> python3 -V
 
 Faites un retour
 
 Cdt
 
 0
 0
- - 12 janvier 2023 à 14 h 20 min
 Richard
 Participant
 C’est bon j’avance.
 
 J’ai retrouver mon mot de passe pour accéder à mon NAS sous ssh
 
 Mon Jeedom n’est pas sur Raspberry PI il est dans un container docker sur mon NAS openmediavault.
 
 La commande python3 -V sous ssh de mon NAS donne: Python 3.9.2
 
 Vous écrivez « Il faut installer le Script Python à l’endroit ou vous voulez archiver vos CSV. »
 
 Mes fichiers sont écris sur un disque du NAS, à ce jour via un chemin indiquer dans le menu FTP du WES
 
 ip ftp sur serveur:192.168.1.159
 ftp du serveur:21
 user du ftp:ftprichard
 mot de passse: ***
 Chemin sur le serveur FTP (distant):/Bkup/wes
 
 C’est utile comme infos pour continuer ou faut il faire autre chose
 
 0
 0
- - 12 janvier 2023 à 14 h 29 min
 cdlog2
 Modérateur
 C’est parfait. Je vais vous faire un petit serveur sous python qui ira seul cherchez les fichiers CSV par requête aux WES et vous copira ces fichiers dans un dossier que vous pourrez choisir dans votre NAS. Vous pourrez choisir l’heure du Transfert, plutôt le soir c’est mieux comme vous le savez afin de récupérer tous les CVS de la journée.
 
 Voila c’est tout !
 
 0
 0
- - 12 janvier 2023 à 14 h 32 min
 cdlog2
 Modérateur
 Le petit serveur Python sera installé dans votre NAS, donc pas besoin de faire du FTP pour copier les fichiers localement !
 
 0
 0
- - 12 janvier 2023 à 15 h 03 min
 cdlog2
 Modérateur
 Un complément, J’ai bien compris que votre NAS fonctionne sous Linux ? Pourriez vous m’indiquez la distribution Linux qui est installée ?
 
 C’est du Debian ? , Ubuntu ? , Autre ?
 
 Je suppose que vous avez une interface graphique dans votre NAS pour lancer vos applications ? Je suppose que vous avez aussi un bureau ou sont placés des Icônes pour lancez vos Applications Favoris ?
 
 Si Oui, et pour minimiser le développement, le fichier du serveur Python (environs 50k) sera copié dans un dossier ou sous dossier proche de vos fichiers CSV.
 
 Pour lancer le Serveur, vous aurez une Icône à placer sur le Bureau de votre NAS. En cliquant sur cette Icone, on vous proposera de montrer ou vous avez copié le Serveur Python et cela va le démarrer automatiquement. Si vous voulez déplacer vos CVS dans d’autre Dossier, il suffira de copier le fichier du serveur python dans un autre dossier et toujours via l’icone du Bureau le relancer depuis ce nouveau dossier.
 
 C’est simple, rapide. En ce moment je n’ai pas trop le temps pour vous pondre une Appli plus évoluée !
 
 Cdt
 
 0
 0
- - 12 janvier 2023 à 15 h 29 min
 cdlog2
 Modérateur
 Pour terminer, j’aurais besoin de connaître l’agencement des dossiers ou vous stocker vos CSV. Placez vous vos fichiers CSV dans des dossiers classés par catégorie de type de CVS ou bien copiez-vous pêle-mêle tous les CSV dans un même dossier ?
 
 Le fichier Python devra être copié dans le dossier Parent juste en amont des sous dossiers CSV. Si vous avez plusieurs sous dossier pour stocker vos CSV par catégorie de Type, ll vous faudra me fournir l’arborescence et noms des sous dossiers de chaque catégorie CSV.
 
 0
 0
- - 12 janvier 2023 à 15 h 37 min
 Richard
 Participant
 C’est du debian
 Linux 6.0.0-0.deb11.6-amd64
 Version 6.1.4-2 (Shaitan)
 
 l’interface graphique du NAS openmediavault et juste pour la configuration des disques, utilisateur, des configuration du ftp,nfs,pme/cifs et configuration du portainer/docker
 
 Pas d’autres interface, pas de bureau
 j’ai installer dans un docker « Heimdall » qui sert d’interface pour lancer mes applis un icone par appli avec le chemin du type 192.168.1.46:90800 pour jeedom et 192.168.1.46 pour le wes
 
 Pouvez vous me donnez les commandes et le script et je vais le poser sur mon disque repertoire csv et voir comment le lancer via mon interface « Heimdall »
 
 Bonne journée
 
 0
 0
- - 12 janvier 2023 à 15 h 57 min
 Richard
 Participant
 Pour le chemim voici le detail
 
 Info que j’ai mis dans l’interface ftp du wes
 bkup
 wes
 
 Apres j’ai les autres sous répertoire qui ont êtes crée par le wes
 
 PLS/2023/1
 TIC/2023/1
 TICcsv/2023/1
 
 J’espère que je suis clair.
 
 Bonne journée
 
 0
 0
- - 12 janvier 2023 à 16 h 07 min
 cdlog2
 Modérateur
 Bon si on part de cette façon, il me faudra connaître comment accéder aux dossiers de chaque catégorie de vos CVS dans le NAS pour transférer les CSV que le Serveur Python va réclamer au WES via les 2 requêtes que vous connaissez maintenant.
 
 Je vais devoir rajouter en complément avec le fichier qui contient le Script Python, un fichier type JSON que vous devrez remplir pour y rentrer les chemins des sous dossiers de vos CVS
 
 Je tiens à Eviter si possible de faire un double transfert FTP vers votre NAS, a savoir <WES> ftp <-Python -> ftp <NAS >
 
 !cela va me compliquer et vue le temps qui m’est impartie, je ne ferais pas votre appli de suite. J’ai un gros projet en cours en ce moment !
 
 Pour lancer le Serveur Python, vous devrez à défaut d’autre moyen, le lancer manuellement depuis une console SSH. Une fois lancé, le Serveur Python reste autonome. Vous pourrez Tuer le serveur Python toujours depuis une commande SSH.
 
 SVP, Avant que je commence, dites moi comment je vais accéder aux dossiers de vos fichiers CSV avec des exemples très précis pour chaque catégorie de vos CSV.
 
 Cdt
 
 0
 0
- - 12 janvier 2023 à 16 h 23 min
 cdlog2
 Modérateur
 Comme je n’ai jamais utilisé la Fonction Trf FTP du WES, votre explications ne me servent pas, car je ne sais pas ce que fait le WES dans cette interface !!!.
 
 Il faut que vous me donniez les commandes FTP si on passe par cette passerelle pour accéder à vos dossiers locaux CSV du NAS.
 
 C’est pourquoi mon choix de faire des copies des fichiers CVS directement sur le Disque local ou sont placé vos CVS est plus beaucoup plus simple pour moi que de faire un Double Trf FTP.
 
 Pourquoi on ne peut pas copier le fichier Python dans un dossier proche de vos sous dossier CSV ???.
 
 Quelque soit l’endroit ou vous copiez le Serveur Python dans un des disques du NAS, il vous faudra de toute façon Lancer le serveur Python via une commande SSH n’ayant pas d’autre interface accessible.
 
 0
 0
- - 12 janvier 2023 à 16 h 36 min
 Richard
 Participant
 Si j’ai bien compris @nicolas vas ajouter les fichiers manquants dans le ftp du wes
 
 S il fournit une version bêta ou définitive rapidement il n’est peux être pas utile de vous prendre la tête.
 
 Par contre votre solution peu peux être remplacer les fonctions wes pour moi
 
 Non je donnais juste des infos que je pensé utiles.
 
 Je cherche pas à avoir un truc qui tourne forcement avec le wes, faite au plus simple, je verrai si j’arrive à intégrer dans le répertoire le script et comment lancer la commande
 
 A votre question »Pourquoi on ne peut pas copier le fichier Python dans un dossier proche de vos sous dossier CSV ??? »
 
 Si je peux copier le fichier dans le répertoire.
 
 Peux être un peu plus claire j’espère.
 
 0
 0
- - 12 janvier 2023 à 19 h 30 min
 cdlog2
 Modérateur
 RE: Ok je vais voir à vous faire une maquette, mais ne soyez pas trop pressé !.
 
 Comme c’est encore flou côté structure des dossiers dans votre NAS, Comme je ne sais pas ce que le WES vous transfère dans vos dossiers lors d’un backup, fichiers CVS ? DAT ? et comment le tout est agencé dans vos dossiers NAS ?
 
 je vais utiliser et joindre un 2eme fichiers type JSON associé au fichier Script Python, que vous remplirez et qui permet de donner plus d’ouverture en définissant l’arborescence des dossiers à traiter suivant les types de fichiers à récupérer du WES.
 
 Ce fichier JSON sera organisé de la façon suivante :
 
 Chemin complet du dossier Parent, soit le Dossier Racine commun à tous les fichiers Backup, exemple : /home/user/Backup-WES
 
 Ensuite le Chemin de chaque Sous Dossier par Catégorie en Aval du Dossier Commun Parent :
 
 Nom dossier Catégorie TIC >> Nom du dossier Année >> Nom du dossier Mois >> Nom du dossier des CVS >> Nom du dossier des DAT
 Nom dossier Catégorie PCE >> Nom du dossier Année >> Nom du dossier Mois >> Nom du dossier des CVS >> Nom du dossier des DAT
 Nom dossier Catégorie PLS >> Nom du dossier Année >> Nom du dossier Mois >> Nom du dossier des CVS >> Nom du dossier des DAT
 Nom dossier Catégorie TEMP >> Nom du dossier Année >> Nom du dossier Mois >> Nom du dossier des CVS >> Nom du dossier des DAT
 
 Heure du Backup : Heure du début des Backup Journalier
 
 Ce fichier JSON vous permettra de placer le fichier Script Python et ce fichier JSON ensemble dans le dernier Dossiers Parent soit dans l’exemple /home/user/Backup-WES.
 
 Le Script Python sera nommé : ServBackupWes.py
 Vous pourrez depuis une console SSH lancer ce Script Python comme suit : python3 / [dossier parent] /ServBackupWes.py 8400 &
 Le Serveur Python va utiliser le Port 8400 et l’adresse localhost soit : 127.0.0.1
 Le Serveur Python tournera en permanence dès son lancement et commencera ses Backup Journaliers suivant l’Heure qui est défini dans le JSON.
 
 En cas de coupure du NAS, il faudra relancer ce Serveur Python manuellement et pour finir vous pourrez arrêter le Serveur à tout moment par la commande SSH suivante : pkill -9 -f « python3 / [dossier parent] /ServBackupWes «
 
 Voila en gros ! Dites moi si cela vous convient et si cette installation est possible à réaliser dans votre NAS ? Il faudra donner au Script Python les autorisations en écriture pour les divers Dossiers CSV et DAT et définir ce Script exécutable.
 
 Cdt
 
 0
 0
- - 12 janvier 2023 à 21 h 04 min
 Richard
 Participant
 Bonsoir.
 
 Votre méthode me convient très bien.
 
 De mon coté cela semble possible d’installer les fichiers comme demandé et je peux configurer les droits sur les répertoires.
 
 Bonne soirée
 
 0
 0
- - 16 janvier 2023 à 14 h 06 min
 cdlog2
 Modérateur
 Bonjour,
 
 @Richard, j’ai terminé la partie du Serveur qui effectue les Backups des fichiers CSV du WES. Pour l’instant la sauvegarde des fichiers DAT n’est pas implémenté.
 
 Je vous joins une archive contenant 3 fichiers. Vous devez copier ces fichiers dans votre NAS à l’emplacement ou vous souhaitez créer le Dossier du Backup WES contenant les fichiers CSV classés par Catégories / année / mois.
 
 Vous trouverez un fichier config.json que vous devez configurer. Vous ferez attention de bien respecter les guillemets et les virgules en fin des lignes.
 Adapter l’URL de votre WES (login et mot de passe + IP du WES) et l’heure du Backup des CSV. Les autres Nom des dossiers peuvent rester en l’état s’ils vous conviennent
 
 {« config »: [{
 « UrlWes »: « http://login:password@192.168.x.x/ » , # URL pour accéder à votre WES
 « BakupTime »: « 10:57 » , # Heure de début du Backup des fichiers CSV hh:mm
 « BackupPath »: « BackupWES », # Ref: Sous Dossier BackupWES des CSV
 « TicPath »: « TIC » , # Nom du Dossier Ref: catégorie TIC
 « TicPathCsv »: « CSV » , # Nom du Dossier Ref: des CSV Tic
 « TicPathDat »: « DAT » , #
 « PcePath »: « PCE » , # Nom du Dossier Ref: catégorie PCE
 « PcePathCsv »: « CSV » , # Nom du Dossier Ref: des CSV Pce
 « PcePathDat »: « DAT » , #
 « PlsPath »: « PLS » , # Nom du Dossier Ref: catégorie PLS
 « PlsPathCsv »: « CSV » , # Nom du Dossier Ref: des CSV Pls
 « PlsPathDat »: « DAT » , #
 « TempPath »: « TEMP » , # Nom du Dossier Ref: catégorie TEMP
 « TempPathCsv »: « CSV » , # Nom du dossier Ref : des CSV temp
 « TempPathDat »: « DAT » »
 }]}
 
 Si vous gardez les Noms des Dossiers tel que définis dans le fichier config.json, le dossier de référence du Backup WES est :
 « / [Dossiers Inst. des fichiers] / BackupWES/ »
 
 Les fichiers CSV TIC seront enregistrés dans / [Dossiers Inst. Des fichiers] / BackupWES / TIC/ [Année] / CSV / [mois] / *.csv
 Les fichiers CSV PCE seront enregistrés dans / [Dossiers Inst. Des fichiers] / BackupWES / PCE/ [Année] / CSV / [mois] / *.csv
 Les fichiers CSV PLS seront enregistrés dans / [Dossiers Inst. Des fichiers] / BackupWES / PLS/ [Année] / CSV / [mois] / *.csv
 Les fichiers CSV TEMP seront enregistrés dans / [Dossiers Inst. Des fichiers] / BackupWES / TEMP / [Année] / CSV / [mois] / *.csv
 
 Pour lancer le Serveur Backup tapez la commande suivant sous console SSH ou via une Console Windows CMD :
 python3 / [Dossiers Inst. Des fichiers] /ServBackupWes.py &
 
 Vous pouvez arrêter le Serveur depuis votre navigateur en rentrant http://127.0.0.1:8400/exit dans la barre adresse puis envoie
 
 Ce petit Serveur peut servir aussi à lancer un petit site WEB. Il suffit de rajouter vos fichiers HTML et au moins un fichier index.htm ou index.html dans le Dossier avec les 3 autres fichiers. Vous lancer votre Site WEB depuis votre navigateur via cette url : http://127.0.0.1:8400/
 
 Depuis les fichiers HTML vous pouvez lancer des requêtes type CGX au WES via cette url :
 http://127.0.0.1:8400/~pgesthtml$/directwes/DATA.CGX
 http://127.0.0.1:8400/~pgesthtml$/directwes/WEBPROG/CGX/VotreFichier.CGX
 
 ou bien commander un Relais ou Switch du WES. Exemple pour activer le Relais2=ON du WES
 http://127.0.0.1:8400/~pgesthtml$/directwes/AJAX.cgx?rl2=ON
 
 Je vous rappelle qu’il faut avoir Python3 installé dans le PC pour faire tourner ce petit Serveur Python.
 
 Faites moi un retour dès que vous lisez ce Post afin de m’assurer que vous en avez pris connaissance.
 Faites moi un retour après avoir tester ce Script après vos essais de Backup des CSV du WES.
 
 Cordialement
 
 Christian
 
 Attachments:
 You must be logged in to view attached files.
 
 0
 0
- - 16 janvier 2023 à 20 h 25 min
 Richard
 Participant
 Bonsoir @cdlog2
 
 Je viens de prendre connaissance de votre post.
 
 Je commence à faire des tests demain.
 
 Je vous remercie beaucoup pour votre aide.
 
 Bonne soirée
 
 0
 0
- - 17 janvier 2023 à 6 h 53 min
 cdlog2
 Modérateur
 Bonjour @Richard,
 
 J’ai trouvé un Bug dans l’archive que j’ai déposé. Donc jeter ma 1ere archive et Télécharger celle que je vous renvoie.
 
 Si vous n’avez pas installé un Site WEB avec un fichier index.html dans le dossier d’installation des 3 fichiers de l’archive,
 Alors une fois le Serveur lancé par la Cde SSH : python3 /votre-path-install/ServBackupWes.py & , vous pouvez en vous connectant à http://127.0.0.1:8400 , visualiser les fichiers et Dossier du Serveur.
 
 Cela vous permet depuis votre navigateur de vous promener dans les divers sous dossiers des CSV et visualiser les résultats des Backup. Vous pouvez Ouvrir par un click droit >> ouvrir avec … ou Télécharger les fichier.csv présent en cliquant dessus.
 
 Le dossier BacupWES sera crée lorsque la toute 1ere séquence de Backup sera lancée en fonction de votre horaire défini dans le config.json
 
 Désolé pour le BUG !
 Faites moi un retour de vos essais
 
 Cordialement
 
 Christian
 
 Attachments:
 You must be logged in to view attached files.
 
 0
 0
- - 17 janvier 2023 à 7 h 58 min
 cdlog2
 Modérateur
 RE:
 
 @Richard, je n’ai pas fait attention, mais lorsque l’on ferme la console SSH après avoir lancé le serveur Backup et malgré que le dernier caractère ‘ &‘ soit passé dans la Cde de lancement , le serveur cherche la console pour afficher des infos et bloque et vous ne pouvez plus vous connecter avec votre navigateur.
 
 Donc pour régler ce PB, vous devez lancer le Script Python depuis la console SSH en rajoutant nohup devant la Cde comme ceci :
 nohup python3 /votre-path-install/ServBackupWes.py &
 
 Actuellement pour changer l’heure du Backup dans le fichier config.json, il faut arrêter le Serveur et le relancer. Je vais vous rajouter une requête qui vous permettra de changer l’heure de lancement du Backup depuis votre navigateur sans devoir arrêter le Serveur.
 
 Comme vous le savez le Backup des fichiers DAT n’est pas encore fonctionnel. Je le ferais plus tard car j’ai pas mal de boulot en ce moment. Donc il y aura d’autre archive à vous transmettre plus tard.
 
 Surtout télécharger ma 2eme archive que j’ai transmis dans mon précédent Post
 
 Cdt
 
 0
 0
- - 17 janvier 2023 à 8 h 19 min
 Richard
 Participant
 Bonjour Christian.
 
 Merci pour ce retour.
 Je regarde dans la journée.
 
 Bonne journée à vous
 
 0
 0
- - 17 janvier 2023 à 14 h 33 min
 cdlog2
 Modérateur
 Bonjour,
 
 @Richard je vous ai rajouté une requête qui vous permet de changer l’horaire de démarrage du Backup des fichiers WES directement depuis votre navigateur.
 
 La requête est : http://127.0.0.1:8400/ pconfig$ / hbackup / hh:mm (Sans Espace bien sûr)
 hh:mm doit être 2 paires de chiffres préfixées d’un zéro pour les unités inférieurs à 10 Exemple : 9h10 doit être rentré 09:10.
 Le fichier config.json est mis à jour automatiquement.
 
 Lorsque vous arrêtez le serveur par la requête : http://127.0.0.1:8400/exit il faut attendre environs 30 secondes avant de relancer le serveur.
 
 Comme le navigateur est en prise avec le serveur, ce dernier ne libère le socket de connexion. donc il faut fermer le navigateur et attendre que le socket se libère seul au bout d’un TimeOut qui dure environs 20 à 30 secondes.
 
 Lorsque vous relancez le serveur par SSH : nohup python3 /votre-dossier-install/ServBackupWes.py &
 
 Vous pouvez voir avec la commande SSH : ps -aux | grep python Si le Serveur à bien démarré ou s’il est passé en Erreur. Dans le cas d’une Erreur attendez 20 à 30 secondes avant de le relancer, toujours le même Pb du socket qui n’est pas libéré.
 
 Je vous joins une 3eme Archive avec la modif sur cette requête Horaire
 
 Cdt
 
 Attachments:
 You must be logged in to view attached files.
 
 0
 0
- - 17 janvier 2023 à 14 h 59 min
 cdlog2
 Modérateur
 Re: Si vous avez déjà installé une de mes archives et personnalisé le fichier config.json, vous pouvez seulement remplacer le fichier
 
 Python ServBackupWes.py de la dernière archive n°3 qui vous autorise de modifier l’heure du lancement du backup depuis votre navigateur.
 
 Par contre il faut arrêter le serveur et le relancer sur le nouveau fichier Python. Voir les commandes dans mon précédent Post
 
 0
 0
- - 17 janvier 2023 à 18 h 09 min
 Richard
 Participant
 Bonsoir
 Je commence juste les tests.
 J’ai copié vos fichiers dans:
 Bkup/BackupWES
 
 Ci-dessous arborescence de mon disque NAS
 Le 192.168.1.159 correspond à « OMV » nom du NAS
 
 Au fil des posts vous faite évoluer la commande python
 python3 / [dossier parent] /ServBackupWes.py 8400 &
 python3 / [Dossiers Inst. Des fichiers] /ServBackupWes.py &
 python3 /votre-path-install/ServBackupWes.py &
 Je suis un peu perdu, j’ai pris la dernier et remplacer « votre-path-install » par
 Bkup/BackupWES
 J’ai lancé dans ssh avec:
 python3 /Bkup/BackupWES/ServBackupWes.py
 j’ai l’erreur suivante
 
 Je pense que j’ai une info qui manque dans mon chemin et je ne trouve pas.
 
 Bonne soirée
 
 0
 0
- - 17 janvier 2023 à 18 h 16 min
 Richard
 Participant
 Oups oubli fichiers
 
 Attachments:
 You must be logged in to view attached files.
 
 0
 0
- - 17 janvier 2023 à 20 h 39 min
 cdlog2
 Modérateur
 Bonsoir,
 
 Je ne comprend pas ? Je croyais que vous saviez travailler directement avec le ou les Disques Dur de votre NAS ?
 Que faites vous dans un PC Windows ? Vous semblez donner le Path d’un lien partagé SMB d’une connexion réseau FTP ?
 
 A quoi correspond /Bkup dans votre NAS ? Est le nom de Partage SMB d’un dossier dans un disque du NAS ou bien le nom d’un de vos Disque Dur physique dans le NAS ? Dans ce cas quel est le /dev de ce disque dur ?
 
 Savez vous accéder aux Dossiers de votre Disque Dur système Debian de votre NAS ?
 
 En principe le User de connexion fait référence au dossier /home/nom-du-user/ dans le Disque Dur système linux
 Le dossier mes Documents du User se trouve dans /home/nom_du_user/Documents
 Si /Bakup est un sous dossier du User de connexion du Disque système linux alors vous le trouvez dans /home/nom-du-user/Bakup
 Le User root par exemple se trouve dans le dossier /root du Disque système linux
 
 Si vous avez d’autres disque Dur dans votre NAS, il faut connaître le NOM de MONTAGE de ces Disque Durs ?
 
 Dans votre NAS, vous n’avez un programme Gestionnaire de fichiers Linux ? qui vous permet lire le contenu de votre ou vos Disque(s) Dur NAS ?
 
 Je ne peux pas vous aider si vous ne connaissez pas la structure Physique du ou des Disque Dur(s) installé(s) dans votre NAS !
 
 J’espère que je n’ai pas travaillé pour rien ?
 
 Cdt
 
 0
 0
- - 17 janvier 2023 à 21 h 25 min
 cdlog2
 Modérateur
 RE : Et lisez mieux ce que j’écris dans mes derniers Posts
 
 Une fois que vous aurez trouvé le Path Exact dans le NAS de votre /Bkup il faut lancer le serveur par:
 
 nohup python3 /Chemin->de-Bkup/ServBackupWes.py &
 
 Exemple: Si et uniquement SI >> Bkup est un sous Dossier du USER courant de connexion au NAS ?? alors le Dossier Parent <==> Dossiers Inst. Des fichiers <==> votre-path-install ( c’est le même chemin !? ) est le Chemin, le PATH dans le Disque dur système du NAS ou il faut mettre les fichiers du Serveur Soit dans notre exemple : /home/nom-de votre user/Bkup
 
 Mais Bkup peut faire parti d’un dossier d’un autre Disque dur dans votre NAS si vous avez plusieurs Disques Dur. Dans ce cas il faut connaïtre le Nom de montage Linux de Ce ou Ces Disque(s) Dur
 
 Si par contre Bkup fait référence à un Nom de Partage d’un dossier du NAS alors il faut connaître à quel Disque Dur fait référence ce Nom de Partage et connaître le Chemin exact dans ce Disque Dur pour accéder à ce Dossier Partagé qui à pour Nom de partage Bkup vis à vis de Windows
 
 Cdt
 
 0
 0
- - 17 janvier 2023 à 22 h 31 min
 cdlog2
 Modérateur
 RE: la référence que vous donnez à Putty : 192.168.1.129 / Bkup est un Nom de Partage SMB entre Windows et votre NAS.
 
 Cela n’est pas le Path réel dans le Disque Dur du NAS mais juste un Nom de Partage affecté à un dossier d’un Disque dans le NAS
 
 Il faut connaître sur quel Disque du NAS et quel est le Dossier dans ce Disque Dur qui à pour Nom de Partage SMB >> Bkup
 
 0
 0
- - 17 janvier 2023 à 22 h 34 min
 cdlog2
 Modérateur
 Re : pour terminer, je vous l’ai bien précisé, je ne développerez pas un transfert double FTP soit WES <FTP> Serveur <FTP> NAS
 
 Désolé !
 
 0
 0
- - 18 janvier 2023 à 12 h 44 min
 Richard
 Participant
 Bonjour @cdolg2
 
 Merci pour vos infos, les choses semblent avancer. Maintenant j’ai des retours d’infos dans ssh qui prouvent que j’ accede au fichier json.
 
 Pour info voici un peu de détail sur mon serveur
 
 —–
 
 Information dans l’interface graphique du NAS Openmediavault.
 Mes disques : Je crée, je monte et je partage dans cette interface
 Disque ou se trouvent tous mes partages
 /dev/sda ST1000DM010-2EP102 931,51 Gio
 /dev/sda1 [EXT4, 294,36 Gio (33%) utilisés, 621,43 Gio disponibles]
 Nom du partage pour les sauvegardes
 Nom :Bkup
 Péripherique :données1
 Chemin relatif : Bkup/
 Chemin absolu :/srv/dev-disk-by-uuid-9551b91a-d834-4eb7-bfb7-a61b71018810/Bkup
 Création des répertoires dans l’explorer sur mon PC Windows
 BackupWES
 
 Après modification et suite à vos infos j’ai passé la commandes suivante dans ssh
 
 —–
 root@omv:~# nohup python3 /srv/dev-disk-by-uuid-9551b91a-d834-4eb7-bfb7-a61b71018810/Bkup/ServBackupWes.py &
 [1] 1017907
 root@omv:~# nohup: les entrées sont ignorées et la sortie est ajoutée à ‘nohup.out'
 [1]+ Termine 2 nohup python3 /srv/dev-disk-by-uuid-9551b91a-d834-4eb7-bfb7-a61b71018810/Bkup/ServBackupWes.py
 
 ——
 
 J’ai le résultat ci dessus je ne sais pas si c’est normal, donc j’ai passé l’ autre commande qui semble faire quelque chose de plus correcte
 ——
 root@omv:~# python3 /srv/dev-disk-by-uuid-9551b91a-d834-4eb7-bfb7-a61b71018810/Bkup/BackupWES/ServBackupWes.py
 
 wwwwww Démarrage Serveur à l’adresse 127.0.0.1 Port 8400 wwwwww
 wwwwww URL WES : http://admin:wes@192.168.1.46/ wwwwwwww
 wwwwww Dossier du Backup WES : /srv/dev-disk-by-uuid-9551b91a-d834-4eb7-bfb7-a61b71018810/Bkup/BackupWES/BackupWes wwwwwww
 wwwwww Heure du Backup WES : 10:20 wwwwwwwww
 ———
 
 Après cette commande rien ne se passe dans ssh, je n’arrive pas a reprendre la main et le prompt « root@omv: » ne reviens pas.
 
 Depuis je n’ai pas la main, j’ai regardé dans l’explorer il n’y a pas de fichier.
 
 Suis je dans la donne voix.
 
 Que manque t il pour finaliser l’opération.
 
 Bonne journée
 
 0
 0
- - 18 janvier 2023 à 12 h 56 min
 Richard
 Participant
 Affichage bizarre je re-post
 
 Bonjour @cdolg2
 Merci pour vos infos, les choses semblent avancer. Maintenant j’ai des retours d’infos dans ssh qui prouvent que j’ accède au fichier json.
 Pour info voici un peu de détail sur mon serveur
 —–
 Information dans l’interface graphique du NAS Openmediavault.
 Mes disques : Je crée, je monte et je partage dans cette interface
 Disque ou se trouvent tous mes partages
 /dev/sda ST1000DM010-2EP102 931,51 Gio
 /dev/sda1 [EXT4, 294,36 Gio (33%) utilisés, 621,43 Gio disponibles]
 Nom du partage pour les sauvegardes
 Nom :Bkup
 Péripherique :données1
 Chemin relatif : Bkup/
 Chemin absolu :/srv/dev-disk-by-uuid-9551b91a-d834-4eb7-bfb7-a61b71018810/Bkup
 
 Création des répertoires dans l’explorer sur mon PC Windows
 BackupWES
 
 Après modification et suite à vos infos j’ai passé la commandes suivante dans ssh
 —–
 root@omv:~# nohup python3 /srv/dev-disk-by-uuid-9551b91a-d834-4eb7-bfb7-a61b71018810/Bkup/ServBackupWes.py &
 [1] 1017907
 
 ——–
 
 J’ai le résultat ci dessus je ne sais pas si c’est normal,.
 
 —–
 
 root@omv:~# nohup: les entrées sont ignorées et la sortie est ajoutée à ‘nohup.out’
 [1]+ Termine 2 nohup python3 /srv/dev-disk-by-uuid-9551b91a-d834-4eb7-bfb7-a61b71018810/Bkup/ServBackupWes.py
 ——
 
 Après j’ai passé l’ autre commande qui semble faire quelque chose de plus correcte
 ——
 root@omv:~# python3 /srv/dev-disk-by-uuid-9551b91a-d834-4eb7-bfb7-a61b71018810/Bkup/BackupWES/ServBackupWes.py
 wwwwww Démarrage Serveur à l’adresse 127.0.0.1 Port 8400 wwwwww
 wwwwww URL WES : http://admin:wes@192.168.1.46/ wwwwwwww
 wwwwww Dossier du Backup WES : /srv/dev-disk-by-uuid-9551b91a-d834-4eb7-bfb7-a61b71018810/Bkup/BackupWES/BackupWes wwwwwww
 wwwwww Heure du Backup WES : 10:20 wwwwwwwww
 ———
 Après cette commande rien ne se passe dans ssh, je n’arrive pas à reprendre la main et le prompt « root@omv: » ne reviens pas.
 Depuis je n’ai pas la main, j’ai regardé dans l’explorer il n’y a pas de fichier.
 Suis je dans la donne voix.
 Que manque t il pour finaliser l’opération.
 Bonne journée
 
 0
 0
- - 18 janvier 2023 à 21 h 33 min
 cdlog2
 Modérateur
 Bonsoir,
 
 Bon c’est déjà bien vous avez trouvez le chemin, le Path physique (absolu) du Disque Dur qui contient le dossier Bkup dans le NAS.
 /srv/dev-disk-by-uuid-9551b91a-d834-4eb7-bfb7-a61b71018810/ est le Nom de Montage de ce Disque Dur dans votre NAS et /Bkup/ est un dossier dans ce disque dur.
 Donc il faut copier les 3 fichiers du serveur dans ce Dossier /Bkup en utilisant le Path Complet : Nom du Disque Dur + Dossier d’install. Soit /srv/dev-disk-by-uuid-9551b91a-d834-4eb7-bfb7-a61b71018810/Bkup/ *vos fichiers ici*
 
 Par contre il ne faut pas vous même créer le dossier BackupWes. Je l’ai bien précisé si vous avez bien lu mes directives.
 lisez le fichier config.json
 
 {« config »: [{
 « UrlWes »: « http://login:password@192.168.x.x/ » , # URL pour accéder à votre WES
 « BakupTime »: « 10:57 » , # Heure de début du Backup des fichiers CSV hh:mm
 « BackupPath »: « BackupWES », # Ref: Sous Dossier BackupWES des CSV
 « TicPath »: « TIC » , # Nom du Dossier Ref: catégorie TIC
 « TicPathCsv »: « CSV » , # Nom du Dossier Ref: des CSV Tic
 « TicPathDat »: « DAT » , #
 « PcePath »: « PCE » , # Nom du Dossier Ref: catégorie PCE
 « PcePathCsv »: « CSV » , # Nom du Dossier Ref: des CSV Pce
 « PcePathDat »: « DAT » , #
 « PlsPath »: « PLS » , # Nom du Dossier Ref: catégorie PLS
 « PlsPathCsv »: « CSV » , # Nom du Dossier Ref: des CSV Pls
 « PlsPathDat »: « DAT » , #
 « TempPath »: « TEMP » , # Nom du Dossier Ref: catégorie TEMP
 « TempPathCsv »: « CSV » , # Nom du dossier Ref : des CSV temp
 « TempPathDat »: « DAT »
 }]}
 
 Je vous ai bien spécifiez que les dossiers que vous rentrez dans le fichier config.json seront crée automatiquement par le Serveur dès le 1er lancement du backup du WES.
 
 Donc cela signifie que vous devez seulement rentrer dans le fichier de config les Noms des Dossiers que vous souhaitez que le Serveur crée et qui définissent l’Arborescence des divers fichiers du Backup.
 La ligne 3 du fichier de config vous demande de rentrer le Nom du Dossier Principal, le Nom du Dossier de références, le Nom du dossier Parent, le 1er dossier des Backup que vous souhaitez que le serveur crée.
 C’est à partir de ce Dossier Parent que seront crée les autres Sous Dossier avec les Noms que vous donnez et qui sont définis dans le fichier de Config.json
 
 Vous ce que vous avez fait, vous avez crée le Dossier /Bkup/BackupWes et vous avez copiez les 3 fichiers dans BackupWes ???
 Vous avez réussi à lancer le Serveur en bricolant ??? et il vous a répondu par :
 
 wwwwww Démarrage Serveur à l’adresse 127.0.0.1 Port 8400 wwwwww
 wwwwww URL WES : http://admin:wes@192.168.1.46/ wwwwwwww
 wwwwww Dossier du Backup WES : /srv/dev-disk-by-uuid-9551b91a-d834-4eb7-bfb7-a61b71018810/Bkup/BackupWES/BackupWes wwwwwww
 wwwwww Heure du Backup WES : 10:20 wwwwwwwww
 
 Mais si vous analysez les Infos rendus par le serveur à son lancement : Il vous renseigne sur le dossier qui va servir aux Backup et comme vous avez copié le Serveur dans le Dossier BackupWes que vous avez crée, le Serveur lit le fichier config à son lancemant et trouve le Nom BackupWes comme dossier de référence et donc vous il dit: je vais crée le dossier BackupWes qui sera le dossier de référence des backups:
 soit le Dossier dans votre cas : /srv/dev-disk-by-uuid-9551b91a-d834-4eb7-bfb7-a61b71018810/Bkup/BackupWES/BackupWes
 
 On voit que le Serveur vous donne le Chemin avez 2 fois BackupWes/ le 1er BackupWes parce que vous avez crée et copié le Serveur dans ce Dossier et le 2eme Dossier BackupWes est celui que le serveur va créer lui même depuis son emplacement dans le Disque Dur !.
 
 Donc il faut que vous copiez les 3 fichiers du Serveur dans /srv/dev-disk-by-uuid-9551b91a-d834-4eb7-bfb7-a61b71018810/Bkup
 Et il faut que vous supprimiez le dossier BackupWES que vous avez crée, c’est au Serveur de le créer.
 
 Ensuite vous devez lancer le serveur en spécifiant sont emplacement dans le disque Dur.
 nohup python3 /srv/dev-disk-by-uuid-9551b91a-d834-4eb7-bfb7-a61b71018810/Bkup/ServBackupWes.py &
 
 Vous allez perdre la main du SSH et le serveur va vous afficher dans notre cas :
 
 wwwwww Démarrage Serveur à l’adresse 127.0.0.1 Port 8400 wwwwww
 wwwwww URL WES : http://admin:wes@192.168.1.46/ wwwwwwww
 wwwwww Dossier du Backup WES : /srv/dev-disk-by-uuid-9551b91a-d834-4eb7-bfb7-a61b71018810/Bkup/BackupWES wwwwwww
 wwwwww Heure du Backup WES : 10:20 wwwwwwwww
 
 Mais il y a un problème, vous avez essayé de lancer le serveur plusieurs fois sans vérifier s’il s’était déjà lancé. Cela suppose que vous avez peut être lancé plusieurs session du même serveur !
 Je vous ai précisez de regarder par la commande SSH : ps -aux | grep python Si le Serveur est bien lancé ou s’il est passé en erreur.
 
 Donc Lancez cette commande SSH : ps -aux | grep python
 
 si vous trouvez des lignes avec le nom du Serveur : python3 /srv/dev-disk-by-uuid-9551b91a-d834-4eb7-bfb7-a61b71018810/Bkup/BackupWES/BackupWes/ServBackupWes.py, ou bien
 python3 /srv/dev-disk-by-uuid-9551b91a-d834-4eb7-bfb7-a61b71018810/Bkup/BackupWES/ServBackupWes.py alors il faut arrêter ce ou ces serveurs
 par la commande SSH : pkill -9 -f « python /srv/dev-disk-by-uuid-9551b91a-d834-4eb7-bfb7-a61b71018810/Bkup/BackupWES/BackupWes/ServBackupWes.py » ou bien par
 pkill -9 -f « python /srv/dev-disk-by-uuid-9551b91a-d834-4eb7-bfb7-a61b71018810/Bkup/BackupWES/ServBackupWes.py » en fonction du Dossier que vous lisez par la Cde SSH : ps -aux | grep python
 
 Attention il faut mettre des guillemets, 1 au début avant python et l’autre à la fin du Path.
 répétez les opérations jusqu’à ce que vous ne trouvez plus ce Serveur Python activé.
 
 Donc Concrètement :
 
 Vous devez copier les 3 fichiers du Serveur dans le dossier : /srv/dev-disk-by-uuid-9551b91a-d834-4eb7-bfb7-a61b71018810/Bkup/.
 Vous devez supprimer le Dossiers /Bkup/BackupWES. Le serveur va le rcréer seul !
 Il faut vous assurez qu’aucune session du Serveur est déjà lancé par la commande SSH : ps -aux | grep python
 Il faut tuer les Serveurs qui tournent par : pkill -9 -f « python /srv/dev-disk-by-uuid-9551b91a-d834-4eb7-bfb7-a61b71018810/Bkup/BackupWES/ServBackupWes.py » ou bien
 pkill -9 -f « python /srv/dev-disk-by-uuid-9551b91a-d834-4eb7-bfb7-a61b71018810/Bkup/BackupWES/BackupWES/ServBackupWes.py » suivant le dossier rendu par la Cde SSH : ps -aux | grep python
 
 Maintenant il y a un autre Problème. Si vous lisez bien ce que le Serveur vous à répondu à son lancement dans la 1ere ligne
 
 wwwwww Démarrage Serveur à l’adresse 127.0.0.1 Port 8400 wwwwww
 wwwwww URL WES : http://admin:wes@192.168.1.46/ wwwwwwww
 wwwwww Dossier du Backup WES : /srv/dev-disk-by-uuid-9551b91a-d834-4eb7-bfb7-a61b71018810/Bkup/BackupWES wwwwwww
 wwwwww Heure du Backup WES : 10:20 wwwwwwwww
 
 Le Serveur vous dit qu’il utilise l’adresse IP Démarrage Serveur à l’adresse 127.0.0.1 Port 8400.
 Or cette adresse IP est l’adresse Locale, le LocalHost de votre serveur NAS et vous ne pouvez pas accéder à cette adresse depuis votre PC Windows.
 
 Je n’ai pas développé ce Serveur pour être lancé à distance ! Normalement tout devrait se faire en Natif dans votre NAS !
 
 Par contre l’adresse IP attribué à votre NAS que je crois être 192.168.1.129 est certainement lié au LocalHost du NAS donc il y a une forte chance que vous puissiez vous logguer au Serveur via votre navigateur par http://192.168.1.129;8400/
 
 Si cela fonctionne, vous allez visualiser les fichiers du Serveur du dossier Bkup. Une fois que le Serveur aura fait au moins un 1er Backup vous verrez le Dossier BackupWES qui aura été crée et en vous promenant à l’intérieur vous allez trouver vos fichier CSV.
 
 Pour que cela fonctionne ainsi il faut faire une modif dans le fichier du Serveur ServBackupWes.py
 
 Editer ce fichier avec un éditeur de texte Basic exemple : bloc-note (pas MS-WORD !!!)
 et vous allez trouver à la ligne 89 >> ADRESSE = « 127.0.0.1 »
 
 Remplacer l’adresse « 127.0.0.1 » par l’IP de votre NAS >> je pense que c’est l’IP : ADRESSE = « 192.168.1.129 » à vous de rentrer la Bonne IP, puis vous enregistrez le fichier.
 
 Si vous avez modifiée le fichier PY du Serveur sous votre PC windows, alors il faut copier ce fichier modifié dans le dossier …../Bkup du NAS
 
 Il faut arrêter le Serveur Python via les Cde SSh décrite ci-dessus si vous l’avez relancé entre temps puis une fois arrêter vous pouvez le lancer une dernière fois par :
 
 nohup python3 /srv/dev-disk-by-uuid-9551b91a-d834-4eb7-bfb7-a61b71018810/Bkup/ServBackupWes.py &
 
 Vous devriez lire :
 
 wwwwww Démarrage Serveur à l’adresse 192.168.1.129 Port 8400 wwwwww
 wwwwww URL WES : http://admin:wes@192.168.1.46/ wwwwwwww
 wwwwww Dossier du Backup WES : /srv/dev-disk-by-uuid-9551b91a-d834-4eb7-bfb7-a61b71018810/Bkup/BackupWES wwwwwww
 wwwwww Heure du Backup WES : 10:20 wwwwwwwww
 
 Essayez de vous connecter avec le navigateur du PC windows : http://192.168.1.129:8400/ normalement vous devriez accéder aux dossier du Serveur si l’IP que j’ai mis est bien celle du NAS .
 
 Je vous rappelle que vous pouvez arrêter le serveur par la requête : http://IP-du-Serveur:8400/exit
 que vous pouvez changer l’heure de démarrage des Backups par la requête : http://IP-du-Serveur:8400/pconfig$/hbackup/23:00
 (hh:mm = 23h30 dans l’exemple)
 
 Voila j’ai fait le tour.
 
 Faite un retour si cela fonctionne !
 
 Cdt
 
 0
 0
- - 18 janvier 2023 à 21 h 48 min
 cdlog2
 Modérateur
 RE: (hh:mm = 23h00 dans l’exemple)
 
 0
 0
- - 19 janvier 2023 à 12 h 55 min
 Richard
 Participant
 Bonjour
 Depuis votre dernier post de nouvelles choses fonctionnent, par contre suite à vos commentaires j’ai peux être fait des manips qui ne sont pas correctes
 Comme demandé j’ai modifié dans ServBackupWes.py à la ligne 89 >> ADRESSE = « 127.0.0.1 » par 192.168.1.159 adresse de mon NAS
 J’ai lancé en ssh
 root@omv:~# nohup python3 /srv/dev-disk-by-uuid-9551b91a-d834-4eb7-bfb7-a61b71018810/Bkup/BkpWes/ServBackupWes.py &
 j’ai eu le retour suivant :
 [1] 1552797
 root@omv:~# nohup: les entrées sont ignorées et la sortie est ajoutée à ‘nohup.out'
 
 Après je suis retourné dans mon navigateur
 J’ai lancé dans mon navigateur la ligne <span style= »font-family: ‘Calibri’,’sans-serif’; mso-ascii-theme-font: minor-latin; mso-hansi-theme-font: minor-latin; mso-bidi-font-family: ‘Times New Roman’; mso-bidi-theme-font: minor-bidi; font-weight: normal; »>http://192.168.1.159:8400/ et maintenant je vois cette arborescence
 
 Directory listing for /
 
 <div class= »MsoNormal » style= »margin-bottom: .0001pt; text-align: center; line-height: normal; » align= »center »>
 
 <hr align= »center » size= »2″ width= »100% » />
 
 </div>
 <ul type= »disc »>
 <li class= »MsoNormal » style= »mso-margin-top-alt: auto; mso-margin-bottom-alt: auto; line-height: normal; mso-list: l0 level1 lfo1; tab-stops: list 36.0pt; »>Config.json
 <li class= »MsoNormal » style= »mso-margin-top-alt: auto; mso-margin-bottom-alt: auto; line-height: normal; mso-list: l0 level1 lfo1; tab-stops: list 36.0pt; »>favicon.ico
 <li class= »MsoNormal » style= »mso-margin-top-alt: auto; mso-margin-bottom-alt: auto; line-height: normal; mso-list: l0 level1 lfo1; tab-stops: list 36.0pt; »>ServBackupWes.log
 <li class= »MsoNormal » style= »mso-margin-top-alt: auto; mso-margin-bottom-alt: auto; line-height: normal; mso-list: l0 level1 lfo1; tab-stops: list 36.0pt; »>ServBackupWes.py
 
 
 J’ai lancé dans mon navigateur la ligne <span style= »font-family: ‘Calibri’,’sans-serif’; mso-ascii-theme-font: minor-latin; mso-hansi-theme-font: minor-latin; mso-bidi-font-family: ‘Times New Roman’; mso-bidi-theme-font: minor-bidi; font-weight: normal; »>http://192.168.1.159:8400/exit et j’ai le retour suivant
 # Serveur STOP et EXIT #
 # Veuillez fermer votre navigateur #
 # avant de relancer ce Serveur BackupWES #
 
 # Si vous avez des difficultés pour relancer le Serveur #
 # Tapez la commande ci-dessous dans une Console : #
 # pkill -9 -f « /[path install]/ServBackupWes.py »
 
 Après j’ai re-lancé dans ssh :
 root@omv:~# nohup python3 /srv/dev-disk-by-uuid-9551b91a-d834-4eb7-bfb7-a61b71018810/Bkup/BkpWes/ServBackupWes.py &
 Puis :
 ps -aux | grep python pour voir si serveur démarré et j’ai les lignes suivantes :
 wsdd 672 0.0 0.6 32436 24168 ? Ss janv.16 0:02 python3 /usr/sbin/wsdd.py –chroot=/run/wsdd –shortlog –workgroup=WORKGROUP
 www-data 3287 0.5 3.4 429776 134428 ? Sl janv.16 20:07 /usr/bin/python3 /var/www/html/plugins/zigbee/resources/zigbeed/zigbeed.py –device socket://192.168.1.166:8888 –loglevel error –socketport 57601 –callback http://127.0.0.1:80/plugins/zigbee/core/php/jeeZigbee.php –apikey UrYqQ04tnJQ2fMgEywd0DeK80rNZXFZcFcn60CCWZv9tF0pgFdNxvpj9R3BUZDBv –cycle 0.3 –pid /tmp/jeedom/zigbee/deamon_1.pid –data_folder /var/www/html/plugins/zigbee/data/1 –device_folder /var/www/html/plugins/zigbee/data/device –controller ezsp –sub_controller auto –channel 20
 root 1561763 0.1 0.4 173408 17276 pts/0 Sl 09:54 0:00 python3 /srv/dev-disk-by-uuid-9551b91a-d834-4eb7-bfb7-a61b71018810/Bkup/BkpWes/ServBackupWes.py
 root 1565589 0.0 0.0 6260 700 pts/0 S+ 10:02 0:00 grep python
 Cela semble montrer que j’ai démarré le serveur
 Puis dernière action
 python3 /srv/dev-disk-by-uuid-9551b91a-d834-4eb7-bfb7-a61b71018810/Bkup/BkpWes/ServBackupWes.py
 Voici le retour
 wwwwww Démarrage Serveur à l’adresse 192.168.1.159 Port 8400 wwwwww
 wwwwww URL WES : http://admin:wes@192.168.1.46/ wwwwwwww
 wwwwww Dossier du Backup WES : /srv/dev-disk-by-uuid-9551b91a-d834-4eb7-bfb7-a61b71018810/Bkup/BkpWes/BackupWes wwwwwww
 wwwwww Heure du Backup WES : 08:30 wwwwwwwww
 
 present date= 2023-01-19 time= 11:57 Backup time= 08:30
 
 Jusque-là cela semble fonctionner sauf que je ne vois rien dans le répertoire BkpWes
 
 Précision j’ai porté une modification dans l’arborescence
 Bkup n’est pas un répertoire c’est le partage, je ne peux pas copier des fichiers à ce niveau
 Je dois impérativement créer des répertoires sous le partage, j’ai donc créé le répertoire BkpWes ou j’ai déposé vos fichiers.
 Ceci est peux être la raison du fonctionnement à moitié correcte
 J’ai supprimer le répertoires BackupWes comme demandé
 
 Bonne journée
 
 0
 0
- - 19 janvier 2023 à 14 h 01 min
 Richard
 Participant
 Oups je pense que cela vient d’un copier collé de Word
 
 Bonjour
 Depuis votre dernier post de nouvelles choses fonctionnent, par contre suite à vos commentaire j’ai peux être fait des manips qui ne sont pas correctes
 Comme demandé j’ai modifié dans ServBackupWes.py à la ligne 89 >> ADRESSE = « 127.0.0.1 » par 192.168.1.159 adresse de mon NAS
 J’ai lancé en ssh
 root@omv:~# nohup python3 /srv/dev-disk-by-uuid-9551b91a-d834-4eb7-bfb7-a61b71018810/Bkup/BkpWes/ServBackupWes.py &
 j’ai eu le retour suivant :
 [1] 1552797
 root@omv:~# nohup: les entrées sont ignorées et la sortie est ajoutée à ‘nohup.out’
 
 Apres je suis retourné dans mon navigateur
 J’ai lancé dans mon navigateur la ligne http://192.168.1.159:8400/ et maintenant je vois cette arborescence
 
 Directory listing for /
 ________________________________________
 • Config.json
 • favicon.ico
 • ServBackupWes.log
 • ServBackupWes.py
 
 J’ai lancé dans mon navigateur la ligne http://192.168.1.159:8400/exit et j’ai le retour suivant
 # Serveur STOP et EXIT #
 # Veuillez fermer votre navigateur #
 # avant de relancer ce Serveur BackupWES #
 
 # Si vous avez des difficultés pour relancer le Serveur #
 # Tapez la commande ci-dessous dans une Console : #
 # pkill -9 -f « /[path install]/ServBackupWes.py »
 
 Après j’ai re-lancé dans ssh :
 root@omv:~# nohup python3 /srv/dev-disk-by-uuid-9551b91a-d834-4eb7-bfb7-a61b71018810/Bkup/BkpWes/ServBackupWes.py &
 Puis :
 ps -aux | grep python pour voir si serveur démarré et j’ai les lignes suivantes :
 wsdd 672 0.0 0.6 32436 24168 ? Ss janv.16 0:02 python3 /usr/sbin/wsdd.py –chroot=/run/wsdd –shortlog –workgroup=WORKGROUP
 www-data 3287 0.5 3.4 429776 134428 ? Sl janv.16 20:07 /usr/bin/python3 /var/www/html/plugins/zigbee/resources/zigbeed/zigbeed.py –device socket://192.168.1.166:8888 –loglevel error –socketport 57601 –callback http://127.0.0.1:80/plugins/zigbee/core/php/jeeZigbee.php –apikey UrYqQ04tnJQ2fMgEywd0DeK80rNZXFZcFcn60CCWZv9tF0pgFdNxvpj9R3BUZDBv –cycle 0.3 –pid /tmp/jeedom/zigbee/deamon_1.pid –data_folder /var/www/html/plugins/zigbee/data/1 –device_folder /var/www/html/plugins/zigbee/data/device –controller ezsp –sub_controller auto –channel 20
 root 1561763 0.1 0.4 173408 17276 pts/0 Sl 09:54 0:00 python3 /srv/dev-disk-by-uuid-9551b91a-d834-4eb7-bfb7-a61b71018810/Bkup/BkpWes/ServBackupWes.py
 root 1565589 0.0 0.0 6260 700 pts/0 S+ 10:02 0:00 grep python
 Cela semble montrer que j’ai démarré le serveur
 Puis dernière action
 python3 /srv/dev-disk-by-uuid-9551b91a-d834-4eb7-bfb7-a61b71018810/Bkup/BkpWes/ServBackupWes.py
 Voici le retour
 wwwwww Démarrage Serveur à l’adresse 192.168.1.159 Port 8400 wwwwww
 wwwwww URL WES : http://admin:wes@192.168.1.46/ wwwwwwww
 wwwwww Dossier du Backup WES : /srv/dev-disk-by-uuid-9551b91a-d834-4eb7-bfb7-a61b71018810/Bkup/BkpWes/BackupWes wwwwwww
 wwwwww Heure du Backup WES : 08:30 wwwwwwwww
 
 present date= 2023-01-19 time= 11:57 Backup time= 08:30
 
 Jusque-là cela semble fonctionner sauf que je ne vois rien dans le répertoire BkpWes
 
 Précision j’ai porté une modification dans l’arborescence
 Bkup n’est pas un répertoire c’est le partage, je ne peux pas copier des fichiers à ce niveau
 Je dois impérativement créer des répertoires sous le partage, j’ai donc créé le répertoire BkpWes ou j’ai déposé vos fichiers.
 Ceci est peux être la raison du fonctionner à moitié correcte
 
 0
 0
- - 19 janvier 2023 à 17 h 11 min
 cdlog2
 Modérateur
 Bonjour Richard,
 
 Bon cela commence à bien se présenter.
 Mais @RICHARD, je vous rappelle un point très important :
 
 il NE FAUT JAMAIS QU’IL Y AIT PLUSIEURS SESSIONS DU MEME SERVEUR QUI TOURNE EN MEME TEMPS !
 
 Lorsque vous regardez les processus Pythons actifs avec la Cde SSH : ps -aux | grep python,
 il ne faut pas qu’il y ait plusieurs lignes avec le même fichier Python ServBackupWes.py visible en fin de ligne.
 
 Si vous voyez plusieurs processus lancés avec le même fichier python en fin des lignes, cela va très mal fonctionner !
 Il faut Alors TUER dans ce cas l’ensemble des processus qui tournent avec la Cde SSH :
 
 pkill -9 -f « python3 /LE-PATH-DU-DISQUE-DUR/ServBackupWes.py »
 
 Ce qui correspond pour vous à :
 pkill -9 -f « python3 /srv/dev-disk-by-uuid-9551b91a-d834-4eb7-bfb7-a61b71018810/Bkup/BkpWes/ServBackupWes.py »
 
 (ne pas oublier les guillemets)
 
 UN AUTRE POINT IMPORTANT. Lorsque vous arrêtez le Serveur depuis votre navigateur avec la requête /exit
 Le Serveur vous affiche le MESSAGE qu’il va s’arrêter avec le texte que vous avez reçu :
 
 # Serveur STOP et EXIT #
 # Veuillez fermer votre navigateur #
 # avant de relancer ce Serveur BackupWES #
 
 # Si vous avez des difficultés pour relancer le Serveur #
 # Tapez la commande ci-dessous dans une Console : #
 # pkill -9 -f « /[path install]/ServBackupWes.py »
 
 Il vous dit aussi que si vous avez des Pbs pour le relancer alors qu’il faut faire depuis une console SSH un pKill ….
 
 UNE CHOSE QUE JE N’AI PAS PRECISE : Il faut Toujours Attendre au MINIMUM 20 secondes entre l’arrêt du Serveur soit par un pKill ….
 ou soit via un /exit tapé depuis le navigateur AVANT de RELANCER le Serveur.
 
 Lorsque le serveur s’arrête, parfois Python peut laisser traîner un Socket encore ouvert et qui tourne le processus de la session Linux
 alors que le Serveur Python lui est visiblement bien arrêté. Ce socket va se libérer seul au bout d’un TIME OUT qui peut durer 20s à 30s.
 
 Si vous essayez de relancer le Serveur trop rapidement, alors le Serveur Python va vous dire qu’il à démarré,
 mais si vous faites plusieurs fois ENTER dans la Console après avoir lancé le Serveur par le NOHUP …
 Vous risquez parfois de voir le message : + arrêté.
 
 Donc systématiquement, il faut toujours vérifier avec la Cde SSH : ps -aux | grep python si le Serveur reste actif une fois que vous l’avez relancé
 Vous pouvez lancer plusieurs fois ps -aux | grep python pour en être sur car il y a des Tempo qui entre en jeux dans le démarrage du Serveur.
 
 Donc en résumé :
 
 Ne jamais lancer le Serveur plusieurs fois de suite sans au préalable vérifier s’il ne tourne pas déjà, via la Cde SSH : ps -aux | grep python
 
 Voici chez moi ce que je visualise avec la CDE SSH ps -aux | grep python
 On voit qu’il n’y a qu’une ligne avec le nom du serveur à la FIN
 Et on voit que le dossier du Disque Dur ou tourne mon Serveur python est /media/cdlog2/DISKUSB2/html/
 
 root 709 0.0 0.2 118784 18660 ? Ssl janv.10 0:00 /usr/bin/python3 /usr/share/unattended-upgrades/unattended-upgrade-shutdown –wait-for-signal
 cdlog2 3147590 0.0 0.3 180288 28260 ? Sl 07:56 0:17 python3 /media/cdlog2/DISKUSB2/html/ServBackupWes.py
 cdlog2 3221519 0.0 0.0 6260 636 pts/1 S+ 15:20 0:00 grep python
 
 Lorsque vous lancez le Serveur par SSH :
 nohup python3 /srv/dev-disk-by-uuid-9551b91a-d834-4eb7-bfb7-a61b71018810/Bkup/BkpWes/ServBackupWes.py &
 
 Vous voyez en retour >> root@omv:~# nohup: les entrées sont ignorées et la sortie est ajoutée à ‘nohup.out’ ( c’est normal )
 
 Après avoir lancé le Serveur, Si vous faites plusieurs ENTER dans la console SSH puis si vous lancez la Cde SSH : ps -aux | grep python
 et que vous voyez le Serveur Présent que une fois dans la Liste >> ALORS vous ne touchez plus à rien c’est BON !
 Laissez tourner le Serveur une fois lancé si vous voulez l’utiliser pour faire vos BACKUP CSV.
 
 Lorsque vous vous connectez avec votre navigateur à : http://192.168.1.159:8400/, vous allez voir les Dossiers et Fichiers ou est installé votre Serveur Python.
 
 Lorsque le 1er Backup aura été lancé par le serveur en fonction du créneaux horaire que vous avez défini dans le config.json, vous verrez le dossier Principal des Backup que vous avez paramétré dans le config.json. Si vous voulez changer l’heure des Backup, n’arrêtez pas le serveur pour changer le config.json.
 
 Vous pouvez changer l’heure du début du Backup depuis votre navigateur.
 
 Vous tapez cette requête depuis le navigateur : http://192.168.1.159:8400/pconfig$/hbackup/hh:mm ou hh:mm = l’heure et minute du début du Backup.
 
 Donc concrètement si vous souhaitez que les Backup se fasse tous les jours à 23:15 vous tapez :
 
 http://192.168.1.159:8400/pconfig$/hbackup/23:15
 
 Pour terminer:
 
 Lorsque dans le dossier ou se trouve le fichier du Serveur Python et lorsque il n’y a pas de fichier d’un site WEB INDEX.html
 alors le Serveur vous montre le Dossier et Fichiers ou il est installé, lorsque vous vous connectez avec votre navigateur.
 
 Par contre si vous copiez les fichiers d’un petit site WEB dans le même Dossier que le Serveur et qu’il y ait un fichier Index.html parmi les fichiers du Site alors au lieu de voir les dossiers et fichiers, vous verrez votre site WEB HTML qui s’ouvre.
 
 Cdt
 
 0
 0
- - 20 janvier 2023 à 1 h 50 min
 cdlog2
 Modérateur
 RE : Surtout ne pas oublier de vider le Cache Mémoire de votre Navigateur lorsque vous relancez le Serveur.
 
 Votre Navigateur peut avoir enregistré une mauvaise connexion un moment donné sur l’adresse de votre NAS et conserve cette info dans son Cache et vous renvoie l’erreur même si les nouvelles Cnx sont OK.
 
 0
 0
- - 20 janvier 2023 à 8 h 27 min
 Richard
 Participant
 Bonjour @cdlog2
 
 Voici le dernier test lancer ce matin
 
 Après la commande
 
 python3 /srv/dev-disk-by-uuid-9551b91a-d834-4eb7-bfb7-a61b71018810/Bkup/BkpWes/ServBackupWes.py &
 
 j’ai
 
 ATTENTION EXCEPTION START Serveur >> Voici l’erreur : [Errno 98] Address already in use
 
 Déroulement des commandes et des vérifications dans ssh
 
 ps -aux | grep python (pour vérifier si démarré)
 
 nohup python3 /srv/dev-disk-by-uuid-9551b91a-d834-4eb7-bfb7-a61b71018810/Bkup/BkpWes/ServBackupWes.py & (pour démarrer)
 
 ps -aux | grep python (pour re-vérifier si démarré)
 
 root@omv:~# python3 /srv/dev-disk-by-uuid-9551b91a-d834-4eb7-bfb7-a61b71018810/Bkup/BkpWes/ServBackupWes.py &
 
 Suite à l’exécution de la commande j’ai ce message:
 
 « ATTENTION EXCEPTION START Serveur >> Voici l’erreur : [Errno 98] Address already in use
 
 root@omv:~# ps -aux | grep python pour vérifier l’etat du serveur
 
 Pour info
 
 J’avais fait dans le navigateur la vérification des dossiers (retour avec la liste des fichiers)
 
 Fermeture de la page et CTRL+F5 puis retour ssh pour lancement.
 
 Attente entre les manip environ 1 mn
 
 Copie collé de ma console SSH pour visualiser l’ensemble de mes actions et résultats
 
 **********************
 
 Login as: root
 root@192.168.1.159’s password:
 Linux omv 6.0.0-0.deb11.6-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.0.12-1~bpo11+1 (2022-12-19) x86_64
 
 The programs included with the Debian GNU/Linux system are free software;
 the exact distribution terms for each program are described in the
 individual files in /usr/share/doc/*/copyright.
 
 Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
 permitted by applicable law.
 Last login: Fri Jan 20 07:44:34 2023 from 192.168.1.134
 
 root@omv:~# ps -aux | grep python
 wsdd 672 0.0 0.5 32436 22068 ? Ss janv.16 0:02 python3 /usr/sbin/wsdd.py –chroot=/run/wsdd –shortlog –workgroup=WORKGROUP
 www-data 3287 0.5 2.8 442320 111896 ? Sl janv.16 26:47 /usr/bin/python3 /var/www/html/plugins/zigbee/resources/zigbeed/zigbeed.py –device socket://192.168.1.166:8888 –loglevel error –socketport 57601 –callback http://127.0.0.1:80/plugins/zigbee/core/php/jeeZigbee.php –apikey UrYqQ04tnJQ2fMgEywd0DeK80rNZXFZcFcn60CCWZv9tF0pgFdNxvpj9R3BUZDBv –cycle 0.3 –pid /tmp/jeedom/zigbee/deamon_1.pid –data_folder /var/www/html/plugins/zigbee/data/1 –device_folder /var/www/html/plugins/zigbee/data/device –controller ezsp –sub_controller auto –channel 20
 root 2202297 0.0 0.0 6260 708 pts/0 S+ 07:58 0:00 grep python
 
 root@omv:~# nohup python3 /srv/dev-disk-by-uuid-9551b91a-d834-4eb7-bfb7-a61b71018810/Bkup/BkpWes/ServBackupWes.py &
 [1] 2202382
 root@omv:~# nohup: les entrées sont ignorées et la sortie est ajoutée à ‘nohup.out’
 
 root@omv:~# ps -aux | grep python
 wsdd 672 0.0 0.5 32436 22068 ? Ss janv.16 0:02 python3 /usr/sbin/wsdd.py –chroot=/run/wsdd –shortlog –workgroup=WORKGROUP
 www-data 3287 0.5 2.8 442320 111928 ? Sl janv.16 26:47 /usr/bin/python3 /var/www/html/plugins/zigbee/resources/zigbeed/zigbeed.py –device socket://192.168.1.166:8888 –loglevel error –socketport 57601 –callback http://127.0.0.1:80/plugins/zigbee/core/php/jeeZigbee.php –apikey UrYqQ04tnJQ2fMgEywd0DeK80rNZXFZcFcn60CCWZv9tF0pgFdNxvpj9R3BUZDBv –cycle 0.3 –pid /tmp/jeedom/zigbee/deamon_1.pid –data_folder /var/www/html/plugins/zigbee/data/1 –device_folder /var/www/html/plugins/zigbee/data/device –controller ezsp –sub_controller auto –channel 20
 root 2202382 0.3 0.4 173052 17660 pts/0 Sl 07:58 0:00 python3 /srv/dev-disk-by-uuid-9551b91a-d834-4eb7-bfb7-a61b71018810/Bkup/BkpWes/ServBackupWes.py
 root 2203089 2.2 0.3 18752 12712 ? S 08:00 0:00 python3 /usr/sbin/omv-mkrrdgraph
 root 2203481 0.0 0.0 6260 708 pts/0 S+ 08:00 0:00 grep python
 
 root@omv:~# python3 /srv/dev-disk-by-uuid-9551b91a-d834-4eb7-bfb7-a61b71018810/Bkup/BkpWes/ServBackupWes.py &
 [2] 2203744
 root@omv:~#
 wwwwww Démarrage Serveur à l’adresse 192.168.1.159 Port 8400 wwwwww
 wwwwww URL WES : http://admin:wes@192.168.1.46/ wwwwwwww
 wwwwww Dossier du Backup WES : /srv/dev-disk-by-uuid-9551b91a-d834-4eb7-bfb7-a61b71018810/Bkup/BkpWes/BackupWes wwwwwww
 wwwwww Heure du Backup WES : 08:00 wwwwwwwww
 
 ATTENTION EXCEPTION START Serveur >> Voici l’erreur : [Errno 98] Address already in use
 
 [1]- Processus arrêté nohup python3 /srv/dev-disk-by-uuid-9551b91a-d834-4eb7-bfb7-a61b71018810/Bkup/BkpWes/ServBackupWes.py
 [2]+ Processus arrêté python3 /srv/dev-disk-by-uuid-9551b91a-d834-4eb7-bfb7-a61b71018810/Bkup/BkpWes/ServBackupWes.py
 
 root@omv:~# ps -aux | grep python
 wsdd 672 0.0 0.5 32436 22068 ? Ss janv.16 0:02 python3 /usr/sbin/wsdd.py –chroot=/run/wsdd –shortlog –workgroup=WORKGROUP
 www-data 3287 0.5 2.8 442320 111944 ? Sl janv.16 26:48 /usr/bin/python3 /var/www/html/plugins/zigbee/resources/zigbeed/zigbeed.py –device socket://192.168.1.166:8888 –loglevel error –socketport 57601 –callback http://127.0.0.1:80/plugins/zigbee/core/php/jeeZigbee.php –apikey UrYqQ04tnJQ2fMgEywd0DeK80rNZXFZcFcn60CCWZv9tF0pgFdNxvpj9R3BUZDBv –cycle 0.3 –pid /tmp/jeedom/zigbee/deamon_1.pid –data_folder /var/www/html/plugins/zigbee/data/1 –device_folder /var/www/html/plugins/zigbee/data/device –controller ezsp –sub_controller auto –channel 20
 root 2204009 0.0 0.0 6260 644 pts/0 S+ 08:01 0:00 grep python
 root@omv:~#
 *****************
 
 Bonne journée
 
 0
 0
- - 20 janvier 2023 à 15 h 37 min
 cdlog2
 Modérateur
 Bonjour Richard
 
 Attention ne copiez pas les commandes depuis le Blog car les guillemets sont transformé en un autre caractère qui leur ressemble.
 Attention ne copiez pas les commandes depuis le Blog car les guillemets sont transformé en un autre caractère qui leur ressemble.
 
 Je suis désolé, mais on n’arrive pas se comprendre !
 
 Lorsque vous avez lancé le serveur avec Nohup … Le serveur vous a rendu une Erreur :
 
 ATTENTION EXCEPTION START Serveur >> Voici l’erreur : [Errno 98] Address already in use
 
 Je ne sais pas si vous comprenez l’anglais, mais quand je lis : Voici l’erreur : [Errno 98] Address already in use
 
 « Address already in use«
 
 Veut dire en Français : Serveur déjà Occupé !!!!!!
 
 Cela veut dire que le Serveur tourne quelque part ou bien un de ses Sockets est occupé.
 
 Je vais une dernière fois vous dire ce qu’il faut faire lorsque le serveur est occupé,
 
 il faut fermer le navigateur puis il faut faire plusieurs (3 à 4) :
 
 pkill -9 -f « /srv/dev-disk-by-uuid-9551b91a-d834-4eb7-bfb7-a61b71018810/Bkup/BkpWes/ServBackupWes.py »
 
 Attention ne copiez pas les commandes depuis le Blog car les guillemets sont transformé en un autre caractère qui leur ressemble.
 
 Vous fermer après la connexion Putty, car il est possible que c’est la connexion SSH qui pose PB. Vous attendez 30 secondes.
 Vous laissez le navigateur toujours fermé. Vous relancer le SSH, vous faite un ps -aux | grep python pour voir si le Serveur est bien arrêté
 Vous refaites 3 à 4 >> pkill -9 -f « /srv/dev-disk-by-uuid-9551b91a-d834-4eb7-bfb7-a61b71018810/Bkup/BkpWes/ServBackupWes.py »
 pour être certain que tous les Process sont tombé
 
 Attention ne copiez pas les commandes depuis le Blog car les guillemets sont transformé en un autre caractère qui leur ressemble.
 
 Le navigateur est toujours fermé, vous lancez le serveur UNE SEULE FOIS avec le
 
 nohup python3 /srv/dev-disk-by-uuid-9551b91a-d834-4eb7-bfb7-a61b71018810/Bkup/BkpWes/ServBackupWes.py &
 
 Vérifiez que le serveur vous affiche son message de lancement : root@omv:~# nohup: les entrées sont ignorées et la sortie est ajoutée à ‘nohup.out’
 
 Si vous voyez ce message du Serveur : Vous faites plusieurs fois Enter dans la console SSH pour voir si une erreur apparaît
 Vous vérifiez avec ps -aux | grep python si tout est OK et qu’une seule instance du Serveur tourne. Si tout est OK >> Vous fermez Putty. Vous ouvrez votre navigateur et vous testez la connexion http://192.168.1.159:8400 Si vous voyez les fichiers dans le Directory du Serveur alors cela fonctionne.
 
 Si vous n’avez pas eu le message de démarrage du Serveur > Alors vous recommencer le cycle depuis le début avec les pKILL….
 
 Une fois que vous aurez réussi à lancer ce Serveur !
 
 Faites un test de backup du WES en lançant la requête qui permet de changer l’horaire du Backup >>
 Faites en sorte de lancer le Backup dans les 2 à 3 minutes qui suivent pour faire le test.
 http://admin:wes@192.168.1.46:8400/pconfig$/hbackup/hh:mm
 
 Rafraîchir la Page de votre Navigateur et vérifier si vous voyez les dossiers qui ont été crée avec les CSV.
 
 Le Nom du dossier de référence des CSV est BackupWes par défaut, si vous n’avez pas changé ce nom dans le fichier config.json
 
 ##############################
 
 Je pense que c’est du fait que vous faites vos Manip via une console SSH Distante qui ne plait pas à Python
 
 Il peut arriver que le Serveur soit occupé, mais uniquement lorsque vous l’arrêtez depuis le navigateur par un /exit et cela dure pas plus de 30secondes.
 
 Vous n’êtes pas dans les meilleures condition du fait de faire tout cela via le SFTP depuis un PC distant.
 Normalement il faudrait accéder au SSH du Serveur NAS directement pour pouvoir lancer le moniteurs système et voir les Sockets qui restent occupé. On peut alors les tuer très facilement depuis cette interface.
 
 Mais vous faites aussi des *ERREURS de MANIP !!!!!
 Pourquoi encore lancer 2 fois le Serveur alors qu’il est lancé ?????
 
 JE REPREND VOS CAPTURES SSH POUR VOUS MONTRER :
 
 ICI VOUS REGARDEZ SI LE SERVEUR A DEMARRE
 
 root@omv:~# ps -aux | grep python
 wsdd 672 0.0 0.5 32436 22068 ? Ss janv.16 0:02 python3 /usr/sbin/wsdd.py –chroot=/run/wsdd –shortlog –workgroup=WORKGROUP
 www-data 3287 0.5 2.8 442320 111896 ? Sl janv.16 26:47 /usr/bin/python3 /var/www/html/plugins/zigbee/resources/zigbeed/zigbeed.py –device socket://192.168.1.166:8888 –loglevel error –socketport 57601 –callback http://127.0.0.1:80/plugins/zigbee/core/php/jeeZigbee.php –apikey UrYqQ04tnJQ2fMgEywd0DeK80rNZXFZcFcn60CCWZv9tF0pgFdNxvpj9R3BUZDBv –cycle 0.3 –pid /tmp/jeedom/zigbee/deamon_1.pid –data_folder /var/www/html/plugins/zigbee/data/1 –device_folder /var/www/html/plugins/zigbee/data/device –controller ezsp –sub_controller auto –channel 20 root 2202297 0.0 0.0 6260 708 pts/0 S+ 07:58 0:00 grep python
 
 ICI COMME IL N’EST PAS VISIBLE , VOUS LANCEZ LE SERVEUR AVEC LE NOHUP ……
 root@omv:~# nohup python3 /srv/dev-disk-by-uuid-9551b91a-d834-4eb7-bfb7-a61b71018810/Bkup/BkpWes/ServBackupWes.py &
 
 ICI LE SERVEUR VOUS REPOND QU’IL A DEMARRE
 [1] 2202382 root@omv:~# nohup: les entrées sont ignorées et la sortie est ajoutée à ‘nohup.out’
 
 ICI VOUS VERIFIEZ SI VOUS VOYEZ LE SERVEUR ACTIF avec le ps -aux | grep python
 *****************************************
 root@omv:~# ps -aux | grep python
 wsdd 672 0.0 0.5 32436 22068 ? Ss janv.16 0:02 python3 /usr/sbin/wsdd.py –chroot=/run/wsdd –shortlog –workgroup=WORKGROUP
 www-data 3287 0.5 2.8 442320 111928 ? Sl janv.16 26:47 /usr/bin/python3 /var/www/html/plugins/zigbee/resources/zigbeed/zigbeed.py –device socket://192.168.1.166:8888 –loglevel error –socketport 57601 –callback http://127.0.0.1:80/plugins/zigbee/core/php/jeeZigbee.php –apikey UrYqQ04tnJQ2fMgEywd0DeK80rNZXFZcFcn60CCWZv9tF0pgFdNxvpj9R3BUZDBv –cycle 0.3 –pid /tmp/jeedom/zigbee/deamon_1.pid –data_folder /var/www/html/plugins/zigbee/data/1 –device_folder /var/www/html/plugins/zigbee/data/device –controller ezsp –sub_controller auto –channel 20 *******************************************************************************************************
 root 2202382 0.3 0.4 173052 17660 pts/0 Sl 07:58 0:00 python3 /srv/dev-disk-by-uuid-9551b91a-d834-4eb7-bfb7-a61b71018810/Bkup/BkpWes/ServBackupWes.py
 ****************************************************************************************************************
 root 2203089 2.2 0.3 18752 12712 ? S 08:00 0:00 python3 /usr/sbin/omv-mkrrdgraph
 root 2203481 0.0 0.0 6260 708 pts/0 S+ 08:00 0:00 grep python
 
 ICI ON VOIT BIEN, dans la liste ci-dessus, QUE LE SERVEUR EST BIEN ACTIF DANS LA LISTES DES PROCESSUS PYTHON. Votre SERVEUR TOURNE BIEN. Il suffisait de fermer Putty et lancer votre navigateur. Le serveur Tourne !
 
 MAIS JE NE COMPREND PAS POURQUOI VOUS LE RELANCEZ CI-DESSOUS UNE 2EME FOIS DE SUITE !!!!!!!!
 VOTRE SERVEUR TOURNE ET IL EST BIEN VISIBLE DANS LA LISTE ci-dessus RENDU PAR ps -aux | grep python
 
 ***************************************************************************************************
 ICI VOUS FAITES L’ERREUR DE LE RELANCER ENCORE !! ALORS QUE LE SERVEUR TOURNE DEJA !!!
 *****************************************************************************************************
 root@omv:~# python3 /srv/dev-disk-by-uuid-9551b91a-d834-4eb7-bfb7-a61b71018810/Bkup/BkpWes/ServBackupWes.py &
 [2] 2203744
 root@omv:~#
 wwwwww Démarrage Serveur à l’adresse 192.168.1.159 Port 8400 wwwwww
 wwwwww URL WES : http://admin:wes@192.168.1.46/ wwwwwwww
 wwwwww Dossier du Backup WES : /srv/dev-disk-by-uuid-9551b91a-d834-4eb7-bfb7-a61b71018810/Bkup/BkpWes/BackupWes wwwwwww
 wwwwww Heure du Backup WES : 08:00 wwwwwwwww
 
 ET PLOUF GROSSE ERREUR EXECPTION ON VOUS REPOND QUE LE SERVEUR EST DEJA EN SERVICE >> Address already in use
 
 ATTENTION EXCEPTION START Serveur >> Voici l’erreur : [Errno 98] Address already in use
 
 [1]- Processus arrêté nohup python3 /srv/dev-disk-by-uuid-9551b91a-d834-4eb7-bfb7-a61b71018810/Bkup/BkpWes/ServBackupWes.py
 [2]+ Processus arrêté python3 /srv/dev-disk-by-uuid-9551b91a-d834-4eb7-bfb7-a61b71018810/Bkup/BkpWes/ServBackupWes.py
 
 Mais Je pense comprendre pour vous l’avez relancé une 2eme fois de suite.
 
 Lorsque vous Lancer le Serveur en mettant le terme NOHUP devant Python ………….. Lorsque le Serveur démarre il vous affiche uniquement la ligne [1] 2202382 root@omv:~# nohup: les entrées sont ignorées et la sortie est ajoutée à ‘nohup.out’ Cette ligne vous indique que le Serveur à bien démarré et que tous les Messages SSH du Serveur sont masqué et envoyé dans un fichier
 
 Sous LINUX les Entrées sont ceux du Clavier. Et la Sortie et soit l’envoie dans une console SSH ou un Transfert vers un fichier.
 
 Lorsque vous lancer le Serveur sans mettre NOHUP devant Python ……… Les Messages du SERVEUR sont alors Affichés dans la Console SSH et vous Voyez:
 
 wwwwww Démarrage Serveur à l’adresse 192.168.1.159 Port 8400 wwwwww
 wwwwww URL WES : http://admin:wes@192.168.1.46/ wwwwwwww
 wwwwww Dossier du Backup WES : /srv/dev-disk-by-uuid-9551b91a-d834-4eb7-bfb7-a61b71018810/Bkup/BkpWes/BackupWes wwwwwww
 wwwwww Heure du Backup WES : 08:00 wwwwwwwww
 
 Mais comme votre CONSOLE SSH n’est pas LOCALE au NAS, Lorsque vous allez fermer PUTTY, Lorsque le Serveur va chercher à envoyer des messages SSH, cela va créer un PB pour Python qui peut passer en erreur car il ne trouve plus le lien de votre console SSH. J’ai déjà expliqué ce PB dans mes précédents POST !
 
 Donc dans l’avenir lancer bien le SERVEUR avec NOHUP devant la Cde et bien rajouter le signe espace + & à la fin de la cde.
 
 Si vous faites 3 ou 4 ENTRER au clavier et qu’aucun message d’erreur ne s’affiche. Si vous voyez votre serveur dans la Liste avec ps -aux | grep python Alors vous fermez tout, surtout PUTTY et vous tester la connexion avec votre navigateur.
 
 J’espère que maintenant vous avez bien compris les PROCESS ???
 
 Cdt
 
 0
 0
- - 20 janvier 2023 à 16 h 01 min
 cdlog2
 Modérateur
 Une dernière chose : Je pense que vous le savez, mais un Backup des fichiers CSV prend environ +- 1 Minute suivant le nombre de fichier à transférer.
 
 Donc lorsque vous êtes proche de l’heure d’activation du Backup, n’essayez pas de lire les fichiers qui seront copiés, vous risquez de créer des erreurs surtout en connexion SFTP. avec PUTTY. Vous patientez un peu avant d’aller voir les dossiers CSV.
 
 0
 0
- - 20 janvier 2023 à 16 h 51 min
 Richard
 Participant
 Merci pour ces dernières informations.
 
 il y avait une manipe que je n’avais pas comprise entre:
 
 nohup python3 /sr….
 
 python3 /sr….
 
 Pour moi
 
 nohup python3 /sr…. servait à lancer le serveur et
 
 python3 /sr…. à lancer le programme
 
 C’était la raison pour laquelle je lançais ces 2 actions l’une derrière l’autre
 
 Je reprend les tests
 
 Merci pour votre patience.
 
 Bonne journée
 
 0
 0
- - 20 janvier 2023 à 18 h 45 min
 Richard
 Participant
 Re
 
 j’ai exécuter le requête comme demandé, en respectant les tempos entre les actions et les répétition de certaines actions
 
 A aucun moment j’ai eu de création de répertoires et de fichiers.
 
 Par contre j’ai trouvé un fichier log qui c’est créer dans le répertoire BkpWes ou se trouvent les fichiers json et python
 
 Ceci peut il aider pour avancer
 
 Dans ce fichier il y avait les infos suivantes:
 
 2023-01-19 08:30:01,727 — ServBackupWes — CRITICAL — ATTENTION EXCEPTION Proc StartbackupCSV >> Voici l’erreur : [Errno 2] No such file or directory: ‘curl’
 2023-01-20 08:00:02,387 — ServBackupWes — CRITICAL — ATTENTION EXCEPTION Proc StartbackupCSV >> Voici l’erreur : [Errno 2] No such file or directory: ‘curl’
 2023-01-20 17:05:03,311 — ServBackupWes — CRITICAL — ATTENTION EXCEPTION Proc StartbackupCSV >> Voici l’erreur : [Errno 2] No such file or directory: ‘curl’
 2023-01-20 17:25:00,512 — ServBackupWes — CRITICAL — ATTENTION EXCEPTION Proc StartbackupCSV >> Voici l’erreur : [Errno 2] No such file or directory: ‘curl’
 
 C’est peux etre pas utile, je me lance
 
 Dans le programme ServBackupWes.py j’ai trouvé ceci alors que l’adresse du WES est 192.168.1.46 (c’est peux être normal comme je ne maitrise pas je lance juste ceci comme info)
 
 ADRESSE_WES = confUrlWes
 PORT = 8400
 ADRESSE = « 192.168.1.159 »
 
 Bonne journée
 
 0
 0
- - 21 janvier 2023 à 2 h 31 min
 cdlog2
 Modérateur
 Bonsoir,
 
 C’est bien vous avez trouvé mon fichier LOG qui est créé effectivement lorsque mon programme tombe en Erreur.
 
 Le message que vous lisez dans le fichier LOG indique que le Serveur cherche la fonction CURL qui est normalement installé de BASE dans la plupart des Systèmes LINUX DEBIAN, UBUNTU et autres. C’est curieux que dans la version Debian de votre NAS que Curl ne soit pas installé.
 
 J’utilise Curl pour faire mes accès GET HTTP pour envoyer les requêtes au WES. C’est grâce à l’interface Curl que je peux très simplement télécharger les fichiers CSV. Le Serveur à tenté de faire 4 accès au WES, pour réaliser les Backup des TIC, PCE, PLS et TEMP ! donc vous à affiché 4 erreurs identiques
 
 Pour confirmer que CURL est installé ou pas dans votre NAS, taper sous console SSH : curl –version (curl en minuscule)
 
 Soit CURL est installé ? dans votre NAS, Alors vous aurez la version de l’interface curl ,
 Soit CURL N’est Pas installé dans votre NAS alors vous aurez une erreur de commande introuvable.
 
 Si Curl est Installé dans votre NAS, alors cela signifie que le Fichier du Serveur Python ServBackupWes.py n’a pas les privilège pour lancer CURL. Dans cas Vous devez lancer le Serveur Python En Rajoutant sudo devant le nohup de la commande qui lance votre Serveur soit :
 sudo nohup python3 /srv/dev-disk-by-uuid-9551b91a-d834-4eb7-bfb7-a61b71018810/Bkup/BkpWes/ServBackupWes.py
 
 Il faudra d’abord arrêter le Serveur via le navigateur : http://192.168.1.159:8400/exit et relancer le Serveur comme vous savez le faire maintenant mais en rajoutant sudo devant la commande nohup
 
 Par contre S’il est confirmé que Curl n’est pas installé dans votre NAS, alors il faut l’installer. C’est très simple :
 Tout d’abord il faut voir si vous pouvez installer des Programmes dans votre NAS depuis la console SSH
 
 Pour le vérifier, Toujours via la console SSH vous tapez les 2 commandes suivantes l’une après l’autre pour voir si vous avez accès aux Cdes d’installation de votre NAS depuis le SSH. En premier lieu vous tapez : apt-get –version et ensuite vous tapez : apt –version
 
 Soit apt ou apt-get sont installés, vous aurez leur version,
 Soit une seule des 2 cde APT existe alors il faudra utiliser la Cde apt en relatif
 Soit ni apt et ni apt-get existe Alors là cela devient très très très compliqué pour vous ! Curl pas Installé et impossible pour vous de l’Installer par SSH. Il faudra voir alors du côté de l’ADMIN du NAS pour installer CURL
 
 En espérant que l’une des 2 commandes APT est bien installée dans votre NAS, vous utilisez de préférence la cde apt si elle existe sinon l’autre cde apt
 Le format de ces 2 commandes dépendent de la version Debian de votre NAS.
 
 Pour installer CURL Si vraiement l’interface n’est pas installé, vous taperez les lignes ci-dessous une à une et vous répondrez aux questions par o (oui) si les textes sont en Français ou par y (yes) si on vous parle anglais !. je vais utilisez la cde simple apt mais vous de votre côté vous taperez apt-get >> SI apt seul n’est pas installé dans votre NAS !?
 
 Avant d’installer Curl, Vous devez arrêtez le Serveur Python avec votre navigateur : vous tapez : http://192.168.1.159:8400/exit
 
 Ensuite, Voici les commandes d’installation de CURL : Comme vous êtes déjà Loggué en User ROOT avec le SSH pas besoin de rajouter sudo devant les commandes :
 
 apt update (vous patentez la fin du process)
 apt install curl (vous patientez la fin du process et répondez aux questions par o ou y SI posées !? )
 
 Lorsque l’installation de CURL sera terminé, vous vérifiez si Curl est bien installé par la cde : curl –version
 Cette fois Curl devrait vous montrer sa version.
 
 Comme vous avez arrêtez le Serveur au préalable comme précisé ci-dessus
 Vous faite 1 ou 2 PKILL …. pour tuer d’éventuelle tache du Serveur encore Actif.
 Vérifier par ps -aux | grep python que le serveur est bien Absent
 Supprimer le fichier LOG, il sera reconstruit en cas d’autre d’Erreur.
 
 Ensuite vous relancez le Serveur comme vous savez le faire maintenant.
 
 Faites un Test de Backup du WES en lançant la requête qui permet de changer l’horaire du début des backup.
 http://admin:wes@192.168.1.46:8400/pconfig$/hbackup/hh:mm
 
 Mettez votre heure actuelle plus 2 minutes pour faire démarrer le Backup d’ici 2 minutes plus tard.
 Attendez au moins 1mn et ensuite vous pourrez voir si les dossiers CSV ont bien été crée.
 Vérifier si le fichier LOG est bien resté à la taille ZERO ou n’existe plus. (pas d’erreur)
 
 Vérifier les dossiers du Backup si le fichier LOG est resté à ZERO en taille ou n’a pas été recréé
 
 Si le fichier LOG vous signale la même erreur, alors vous arrêter le Serveur à nouveau
 et vous relancez la procédure d’activation du Serveur en rajoutant cette fois sudo devant le NOHUP …
 
 N’oubiez pas de modifier l’horaire du Backup des CSV (plus tôt le soir) lorsque tout sera OK
 
 Faites moi un retour.
 
 Cdt
 
 0
 0
- - 21 janvier 2023 à 2 h 48 min
 cdlog2
 Modérateur
 RE : ADRESSE_WES = confUrlWes signifie que l’adresse du WES sera l’adresse IP que vous avez rentré dans le fichier config.json
 
 Cette ligne de programme récupère l’info de la ligne « confUrlWes » : « x.x.x.x » du fichier config
 
 0
 0
- - 21 janvier 2023 à 8 h 11 min
 Richard
 Participant
 Bonjour
 
 Pour simple j’ai suivit à la lettre vos instructions
 
 Vérification de la présence de Curl >> retour d’état comme absent
 
 Exécution de l’ensemble des actions pour installation >> à la fin du processus curl –version
 Résultat de la commande:
 
 root@omv:~# curl –version
 curl: (3) Failed to convert –version to ACE; string contains a disallowed charac
 
 Pour faciliter l’analyse voici ci dessous le déroulement ssh de mes actions:
 
 J’espère que cela sera utile et que je n’ai pas fait une mauvaise manip
 
 ****************************
 
 root@omv:~# curl –version
 -bash: curl : commande introuvable
 root@omv:~#
 root@omv:~# apt-get –version
 E: L’opération –version n’est pas valable
 root@omv:~# apt –version
 E: L’opération –version n’est pas valable
 root@omv:~#
 root@omv:~# apt update
 Réception de :1 file:/var/cache/openmediavault/archives InRelease
 Ign :1 file:/var/cache/openmediavault/archives InRelease
 Réception de :2 file:/var/cache/openmediavault/archives Release
 Ign :2 file:/var/cache/openmediavault/archives Release
 Réception de :3 file:/var/cache/openmediavault/archives Packages
 Ign :3 file:/var/cache/openmediavault/archives Packages
 Réception de :4 file:/var/cache/openmediavault/archives Translation-en
 Ign :4 file:/var/cache/openmediavault/archives Translation-en
 Réception de :5 file:/var/cache/openmediavault/archives Translation-fr
 Ign :5 file:/var/cache/openmediavault/archives Translation-fr
 Réception de :6 file:/var/cache/openmediavault/archives Translation-fr_FR
 Ign :6 file:/var/cache/openmediavault/archives Translation-fr_FR
 Réception de :3 file:/var/cache/openmediavault/archives Packages
 Ign :3 file:/var/cache/openmediavault/archives Packages
 Réception de :4 file:/var/cache/openmediavault/archives Translation-en
 Ign :4 file:/var/cache/openmediavault/archives Translation-en
 Réception de :5 file:/var/cache/openmediavault/archives Translation-fr
 Ign :5 file:/var/cache/openmediavault/archives Translation-fr
 Réception de :6 file:/var/cache/openmediavault/archives Translation-fr_FR
 Ign :6 file:/var/cache/openmediavault/archives Translation-fr_FR
 Réception de :3 file:/var/cache/openmediavault/archives Packages
 Ign :3 file:/var/cache/openmediavault/archives Packages
 Réception de :4 file:/var/cache/openmediavault/archives Translation-en
 Ign :4 file:/var/cache/openmediavault/archives Translation-en
 Réception de :5 file:/var/cache/openmediavault/archives Translation-fr
 Ign :5 file:/var/cache/openmediavault/archives Translation-fr
 Réception de :6 file:/var/cache/openmediavault/archives Translation-fr_FR
 Ign :6 file:/var/cache/openmediavault/archives Translation-fr_FR
 Réception de :3 file:/var/cache/openmediavault/archives Packages
 Ign :3 file:/var/cache/openmediavault/archives Packages
 Réception de :4 file:/var/cache/openmediavault/archives Translation-en
 Ign :4 file:/var/cache/openmediavault/archives Translation-en
 Réception de :5 file:/var/cache/openmediavault/archives Translation-fr
 Ign :5 file:/var/cache/openmediavault/archives Translation-fr
 Réception de :6 file:/var/cache/openmediavault/archives Translation-fr_FR
 Ign :6 file:/var/cache/openmediavault/archives Translation-fr_FR
 Réception de :3 file:/var/cache/openmediavault/archives Packages
 Ign :3 file:/var/cache/openmediavault/archives Packages
 Réception de :4 file:/var/cache/openmediavault/archives Translation-en
 Ign :4 file:/var/cache/openmediavault/archives Translation-en
 Réception de :5 file:/var/cache/openmediavault/archives Translation-fr
 Ign :5 file:/var/cache/openmediavault/archives Translation-fr
 Réception de :6 file:/var/cache/openmediavault/archives Translation-fr_FR
 Ign :6 file:/var/cache/openmediavault/archives Translation-fr_FR
 Réception de :3 file:/var/cache/openmediavault/archives Packages
 Ign :3 file:/var/cache/openmediavault/archives Packages
 Réception de :4 file:/var/cache/openmediavault/archives Translation-en
 Ign :4 file:/var/cache/openmediavault/archives Translation-en
 Réception de :5 file:/var/cache/openmediavault/archives Translation-fr
 Ign :5 file:/var/cache/openmediavault/archives Translation-fr
 Réception de :6 file:/var/cache/openmediavault/archives Translation-fr_FR
 Ign :6 file:/var/cache/openmediavault/archives Translation-fr_FR
 Réception de :3 file:/var/cache/openmediavault/archives Packages
 Réception de :4 file:/var/cache/openmediavault/archives Translation-en
 Ign :4 file:/var/cache/openmediavault/archives Translation-en
 Réception de :5 file:/var/cache/openmediavault/archives Translation-fr
 Ign :5 file:/var/cache/openmediavault/archives Translation-fr
 Réception de :6 file:/var/cache/openmediavault/archives Translation-fr_FR
 Ign :6 file:/var/cache/openmediavault/archives Translation-fr_FR
 Réception de :7 http://security.debian.org/debian-security bullseye-security InR elease [48,4 kB]
 Réception de :8 http://httpredir.debian.org/debian bullseye-backports InRelease [49,0 kB]
 Atteint :9 http://deb.debian.org/debian bullseye InRelease
 Réception de :10 http://deb.debian.org/debian bullseye-updates InRelease [44,1 k B]
 Atteint :11 https://openmediavault.github.io/packages shaitan InRelease
 Atteint :12 https://openmediavault-plugin-developers.github.io/packages/debian s haitan InRelease
 Réception de :13 https://download.docker.com/linux/debian bullseye InRelease [43 ,3 kB]
 Réception de :14 http://httpredir.debian.org/debian bullseye-backports/main amd6 4 Packages.diff/Index [63,3 kB]
 Réception de :15 http://httpredir.debian.org/debian bullseye-backports/main amd6 4 Packages T-2023-01-21-0217.34-F-2023-01-20-0812.31.pdiff [1 794 B]
 Réception de :15 http://httpredir.debian.org/debian bullseye-backports/main amd6 4 Packages T-2023-01-21-0217.34-F-2023-01-20-0812.31.pdiff [1 794 B]
 Atteint :16 http://packages.openmediavault.org/public shaitan InRelease
 250 ko réceptionnés en 6s (45,4 ko/s)
 Lecture des listes de paquets… Fait
 Construction de l’arbre des dépendances… Fait
 Lecture des informations d’état… Fait
 6 paquets peuvent être mis à jour. Exécutez « apt list –upgradable » pour les v oir.
 root@omv:~#
 root@omv:~# apt install curl
 Lecture des listes de paquets… Fait
 Construction de l’arbre des dépendances… Fait
 Lecture des informations d’état… Fait
 Les paquets supplémentaires suivants seront installés :
 libcurl4 libnghttp2-14 librtmp1 libssh2-1
 Les NOUVEAUX paquets suivants seront installés :
 curl libcurl4 libnghttp2-14 librtmp1 libssh2-1
 0 mis à jour, 5 nouvellement installés, 0 à enlever et 6 non mis à jour.
 Il est nécessaire de prendre 908 ko dans les archives.
 Après cette opération, 1 873 ko d’espace disque supplémentaires seront utilisés.
 Souhaitez-vous continuer ? [O/n] O
 Réception de :1 http://deb.debian.org/debian bullseye/main amd64 libnghttp2-14 a md64 1.43.0-1 [77,1 kB]
 Réception de :2 http://deb.debian.org/debian bullseye/main amd64 librtmp1 amd64 2.4+20151223.gitfa8646d.1-2+b2 [60,8 kB]
 Réception de :3 http://deb.debian.org/debian bullseye/main amd64 libssh2-1 amd64 1.9.0-2 [156 kB]
 Réception de :4 http://deb.debian.org/debian bullseye/main amd64 libcurl4 amd64 7.74.0-1.3+deb11u3 [345 kB]
 Réception de :5 http://deb.debian.org/debian bullseye/main amd64 curl amd64 7.74 .0-1.3+deb11u3 [269 kB]
 908 ko réceptionnés en 0s (6 252 ko/s)
 Sélection du paquet libnghttp2-14:amd64 précédemment désélectionné.
 (Lecture de la base de données… 40494 fichiers et répertoires déjà installés.)
 Préparation du dépaquetage de …/libnghttp2-14_1.43.0-1_amd64.deb …
 Dépaquetage de libnghttp2-14:amd64 (1.43.0-1) …
 Sélection du paquet librtmp1:amd64 précédemment désélectionné.
 Préparation du dépaquetage de …/librtmp1_2.4+20151223.gitfa8646d.1-2+b2_amd64. deb …
 Dépaquetage de librtmp1:amd64 (2.4+20151223.gitfa8646d.1-2+b2) …
 Sélection du paquet libssh2-1:amd64 précédemment désélectionné.
 Préparation du dépaquetage de …/libssh2-1_1.9.0-2_amd64.deb …
 Dépaquetage de libssh2-1:amd64 (1.9.0-2) …
 Sélection du paquet libcurl4:amd64 précédemment désélectionné.
 Préparation du dépaquetage de …/libcurl4_7.74.0-1.3+deb11u3_amd64.deb …
 Dépaquetage de libcurl4:amd64 (7.74.0-1.3+deb11u3) …
 Sélection du paquet curl précédemment désélectionné.
 Préparation du dépaquetage de …/curl_7.74.0-1.3+deb11u3_amd64.deb …
 Dépaquetage de curl (7.74.0-1.3+deb11u3) …
 Paramétrage de libnghttp2-14:amd64 (1.43.0-1) …
 Paramétrage de librtmp1:amd64 (2.4+20151223.gitfa8646d.1-2+b2) …
 Paramétrage de libssh2-1:amd64 (1.9.0-2) …
 Paramétrage de libcurl4:amd64 (7.74.0-1.3+deb11u3) …
 Paramétrage de curl (7.74.0-1.3+deb11u3) …
 Traitement des actions différées (« triggers ») pour libc-bin (2.31-13+deb11u5) …
 root@omv:~#
 root@omv:~# curl –version
 curl: (3) Failed to convert –version to ACE; string contains a disallowed charac ter
 root@omv:~#
 root@omv:~# apt –version
 E: L’opération –version n’est pas valable
 root@omv:~# apt-get –version
 E: L’opération –version n’est pas valable
 root@omv:~#
 root@omv:~# apt list –upgradable
 En train de lister… Fait
 containerd.io/bullseye 1.6.15-1 amd64 [pouvant être mis à jour depuis : 1.6.14-1]
 docker-ce-cli/bullseye 5:20.10.23~3-0~debian-bullseye amd64 [pouvant être mis à jour depui s : 5:20.10.22~3-0~debian-bullseye]
 docker-ce/bullseye 5:20.10.23~3-0~debian-bullseye amd64 [pouvant être mis à jour depuis : 5:20.10.22~3-0~debian-bullseye]
 docker-compose-plugin/bullseye 2.15.1-1~debian.11~bullseye amd64 [pouvant être mis à jour depuis : 2.14.1~debian-bullseye]
 openmediavault/shaitan 6.1.7-1 all [pouvant être mis à jour depuis : 6.1.4-2]
 sudo/stable-security 1.9.5p2-3+deb11u1 amd64 [pouvant être mis à jour depuis : 1.9.5p2-3]
 root@omv:~#
 
 ************************
 
 Bonne journée
 
 0
 0
- - 21 janvier 2023 à 9 h 46 min
 cdlog2
 Modérateur
 Bonjour,
 
 C’est de ma faute, J’ai précisé par des Warning comme quoi le BLOG transforme les guillemets par un autre caractère et qu’il ne faut pas faire du copier collé depuis le Blog.
 
 Mais c’est la même chose pour les doubles Tirets, Le blog le transforme en un Tiret Long.
 
 Donc pour voir la version de CURL ou des APT il faut écrire curl – – version (2 tirets sans espace suivi de version sans espace)
 
 et apt ou apt-get — version (2 tirets sans espace suivi de version sans espace)
 
 Si vous avez gardez mon n° de téléphone appelez moi. Sinon envoyez moi un MAil, On sature le Blog avec cette affaire !!!!!
 
 Cdt
 
 0
 0
- - 21 janvier 2023 à 9 h 57 min
 cdlog2
 Modérateur
 RE : En tout cas Curl manifestement n’était pas installé dans votre NAS et vous avez très bien réussi à l’installer.
 
 Maintenant il faut relancer le serveur et faire un test de backup CSV.
 
 Si le fichier LOG affiche encore les mêmes erreur sur CURL alors vous arrêtez le Serveur et puis vous le relancez n rajoutant sudo devant le nohup python …. >> sudo nohup python ……
 
 0
 0
- - 21 janvier 2023 à 16 h 56 min
 Richard
 Participant
 Merci pour ces infos
 
 J’ai effectué les corrections, lancé deux trois manips pour vérifier si c’était correcte puis j’ai lancé « nohup python3 /srv/dev-d……. »
 
 Et miracle j’ai la création de BackupWes avec PLS, TEMP et TIC et après les années les mois et tous les fichiers .cvs
 
 Beau travail de votre part, merci de m’avoir aidé jusqu’au bout malgré mes difficultés à comprendre et à bien faire les choses demandées
 
 Pensez vous ajouter la sauvegarde des .dat
 
 Bonne journée et encore merci
 
 0
 0
- - 21 janvier 2023 à 17 h 55 min
 cdlog2
 Modérateur
 Bonsoir,
 
 Ok, Parfait pour tout.
 
 Pour les DAT plus tard, j’ai trop de boulot en ce moment. Mais que faîtes vous de ces DAT ? Les info dans les CSV sont ceux des DAT !
 
 Les DAT servent au WES juste pour afficher les graphiques.
 
 Cdt
 
 0
 0
- - 21 janvier 2023 à 18 h 38 min
 Richard
 Participant
 Le but et d’avoir une sauvegarde de ces fichiers au cas ou ma SD lâche pour reconstruire mon WES et donc de pouvoir le réutiliser avec ces datas.
 
 Juste un petit truc qui ne fonctionne pas la commande:
 
 http://admin:wes@192.168.1.46:8400/pconfig$/hbackup/17:05
 http://admin:wes@192.168.1.46:8400/pconfig$/hbackup/hh:mm
 
 J’ai le message suivant:
 
 Le délai d’attente est dépassé
 Le serveur à l’adresse 192.168.1.46 met trop de temps à répondre.
 
 Pas grave car je suis passé à chaque tests par la modif de l’heure directement dans le fichier Json
 
 Si vous avez une explication je suis quand même preneur.
 
 Bonne soirée
 
 0
 0
- - 21 janvier 2023 à 20 h 36 min
 cdlog2
 Modérateur
 laquelle des 2 commandes ?
 
 0
 0
- - 21 janvier 2023 à 21 h 33 min
 cdlog2
 Modérateur
 Votre IP 192.168.1.46 ne répond pas à mon Serveur, cela vient du WES!
 
 0
 0
- - 21 janvier 2023 à 21 h 47 min
 cdlog2
 Modérateur
 wwwwww Démarrage Serveur à l’adresse 192.168.1.159 Port 8400 wwwwww
 wwwwww URL WES : http://admin:wes@192.168.1.46/ wwwwwwww
 wwwwww Dossier du Backup WES : /srv/dev-disk-by-uuid-9551b91a-d834-4eb7-bfb7-a61b71018810/Bkup/BkpWes/BackupWes wwwwwww
 
 Pourquoi vous envoyez cette requête à votre WES ???
 
 Il faut mettre l’IP du serveur Python ? C’est le serveur Python qui gère l’heure du backup mais pas votre WES.
 
 l’IP de votre serveur Python est 192.168.1.59 et pas 192.168.1.46 !!!!
 
 0
 0
- - 22 janvier 2023 à 7 h 17 min
 Richard
 Participant
 Bonjour @cdlol2.
 
 Dernier test ce matin
 
 Lancement de:
 
 http://192.168.1.159:8400/pconfig$/hbackup/07:05
 
 Résultat:
 
 Le nouvel horaire du début Backup WES est : 07:05
 
 Vérification dans les répertoires après 7h05, il y a bien ajout des fichiers du jour.
 
 Maintenant tout est nickel
 
 Merci encore pour votre aide
 
 Bonne journée
 
 Cette réponse a été modifiée le il y a 2 années et 8 mois par Richard.
 
 0
 0