cdlog2

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

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

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

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

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

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

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