[RESOLU] Copie de dossier volumineux a travers le réseau s'arrête

[d3sys]

bonjour, nous avons essayé de créer un paquet pour une suite logicielle métier un peu comme la suite Adobe. Le problème que nous avons rencontré est que l'install est très volumineux donc pour gérer les éventuelles mises à jour ou correction de programmation du paquet, il a fallut mettre le tout sur un NAS (partage réseau SMB3 donc).
Le problème actuel est que l'installation échoue car le dossier n'est jamais complètement copié dans l'emplacement du poste client. Nous avons essayé avec Copytree, filecopy2 sans succès. Seul run_powershell copy-item a l'air de mieux fonctionner mais non (par moment wapt "saute" carrément la ligne de commande donc ne copie rien).

Wapt : 1.8.1
WaptServer : Debian 10
ConsoleWapt: Windows 10

[vcardon]

bonjour, nous avons essayé de créer un paquet pour une suite logicielle métier un peu comme la suite Adobe. Le problème que nous avons rencontré est que l'install est très volumineux

Le paquet le plus volumineux dont nous avons connaissance est un National Instrument Labview avec plein de modules, genre 70Go, distribué selon la méthode classique par un téléchargement web.

Je vous déconseille de distribuer vos paquets par SMB (voir https://www.wapt.fr/fr/doc/wapt-common- ... takes.html), c'est moche.

Il n'y a pas de raison que vous ne puissiez pas y arriver. Cherchez dans les logs de votre serveur web pourquoi ça bloque, vous devez avoir une limite technique quelque part que vous allez devoir modifier.

Cordialement.

Vincent

[d3sys]

Je vous déconseille de distribuer vos paquets par SMB (voir https://www.wapt.fr/fr/doc/wapt-common- ... takes.html), c'est moche.

Cordialement.

Vincent

Merci pour le lien mais je l'avais déjà lu. Le problème est que la documentation pourtant bien faite et bien pensée est très succincte et plutôt brève quant à l'élaboration de paquets. La plupart des fonctions expliquées concerne la manipulation de fichiers et quoi de plus simple que le SMB pour cela.

- Maintenant cela signifie qu'il nous faut installer un serveur web dans le serveur WAPT. Question est: comment coder cela proprement pour transférer un dossier entier (80Go env) après l'install dans le dossier de notre App puis lancer les patchs à appliquer selon l'utilisateur?
- La doc (sauf si j'ai mal vu) ne s'est pas très attardée sur les échanges de fichiers via WebServer, nous ne savons pas s'il est judicieux de lancer un serveur Web sur le serveur WAPT.
- WAPT gère la reprise en cas de coupure du lien http/ftp ?

[sfonteneau]

- Maintenant cela signifie qu'il nous faut installer un serveur web dans le serveur WAPT.

Wapt est déjà un serveur web qui héberge des paquet wapt. Vous n'avez pas besoin d'installer quelque chose en plus.

Question est: comment coder cela proprement pour transférer un dossier entier (80Go env) après l'install dans le dossier de notre App puis lancer les patchs à appliquer selon l'utilisateur?
- La doc (sauf si j'ai mal vu) ne s'est pas très attardée sur les échanges de fichiers via WebServer, nous ne savons pas s'il est judicieux de lancer un serveur Web sur le serveur WAPT.

Vous avez juste a placer le dossier dans votre paquet

Code : Tout sélectionner

c:\waptdev\tis-copyfile

Puis dans le paquet:

Code : Tout sélectionner

def install():
    copytree2('sources','C:\\projet')

https://doc.tranquil.it/wapt/fr/doc/wap ... -directory

Pour le code dans la session utilisateur:

https://doc.tranquil.it/wapt/fr/doc/wap ... index.html

- WAPT gère la reprise en cas de coupure du lien http/ftp ?

Oui tout a fait

[d3sys]

Wapt est déjà un serveur web qui héberge des paquet wapt. Vous n'avez pas besoin d'installer quelque chose en plus.

Vous avez juste a placer le dossier dans votre paquet

Code : Tout sélectionner

c:\waptdev\tis-copyfile

Puis dans le paquet:

C'est justement ce que nous voulons éviter. Ça nous a pris presque 24h pour envoyer un paquet de 5Go et à l'édition je n'en parle pas vous imaginez un besoin urgent de modifier une erreur dans la programmation le temps que ça prend pour retélécharger avant d'éditer et après édition? C'est pour ça que nous avons opté pour un partage et du coup les paquets sont beaucoup moins volumineux (en kilo octets!) et pas de transferts à rallonge pour juste un code à modifier.
Sauf si on s'y prend vraiment mal (en passant nous sommes programmeurs mais pas sur python donc on est en plein apprentissage!) ce que je comprendrais vraiment mais vraiment.... alors je demande a être éclairé, nos lanternes faiblissent...
Nous avons un autre problème qui se pose sur cette méthode: lors de l'install les sous-dossiers n'ont pas l'air d'être pris en compte. Alors je veux bien revenir à une méthode plus pratique (plus propre ) mais qui fonctionne de façon efficace tout de suite. Où se trouve donc notre erreur?

[vcardon]

https://www.wapt.fr/fr/doc/wapt-common- ... repository ?

+

https://winscp.net/eng/docs/task_synchronize

résoudra votre situation.

Cordialement.

Vincent

[sfonteneau]

C'est justement ce que nous voulons éviter. Ça nous a pris presque 24h pour envoyer un paquet de 5Go
et à l'édition je n'en parle pas vous imaginez un besoin urgent de modifier une erreur dans la programmation le temps que ça prend pour retélécharger avant d'éditer et après édition? C'est pour ça que nous avons opté pour un partage et du coup les paquets sont beaucoup moins volumineux (en kilo octets!) et pas de transferts à rallonge pour juste un code à modifier.

24h C'est n'est vraiment vraiment pas normal, le serveur est en cloud ou bien sur le même réseau local ?

Nous avons un autre problème qui se pose sur cette méthode: lors de l'install les sous-dossiers n'ont pas l'air d'être pris en compte.

Je viens de faire un test avec copytree2('sources','C:\\projet')

Les sous dossier sont bien copier

Pour faire simple nous utilisons la méthode "tout dans le paquet" pour justement éviter les problème pendant l'installation. Copy, timeout, réseau non dispo etc...

Il y a aussi un aspect sécurité, si tout est dans le paquet alors tout est signée, si ce n'est pas dans le paquets alors wapt ne peu garantir l'intégritée des fichier puisque ils ne sont pas dans le manifest du paquet.

Pour moi il faut vérifier si pourquoi votre upload est si long ! Problème de débit ou problème ailleurs ?

[d3sys]

https://www.wapt.fr/fr/doc/wapt-common- ... repository ?

+

https://winscp.net/eng/docs/task_synchronize

résoudra votre situation.

Cordialement.

Vincent

Merci pour la piqure de rappel. ne voulant pas sembler désagréable ni trop têtu je suis revenu avec mon équipe a de meilleures résolution.... recommencer tout à zéro avec ces précieuses informations...

à l’aide de WinSCP, téléversez votre paquet dans le dossier /var/www/html/wapt/ de votre serveur linux.

une fois le transfert terminé, il faut regénérer le fichier Packages sur votre dépôt :

wapt-scanpackages /var/www/wapt/

On upload/synchronise dans www/html/wapt puis on scanne les paquets contenus dans www/wapt/ ? Est-ce une erreur?

24h C'est n'est vraiment vraiment pas normal

C'est ce que nous nous sommes dit... mais à part la surcharge du serveur (100 utilisateurs en moyenne simultané) je ne vois pas ce qui pourrait provoquer cela, d'où la décision de décentralisation.

le serveur est en cloud ou bien sur le même réseau local ?

Le serveur est une VM Proxmox sur un réseau local gigabit.

Mais la solution donnée si elle règle le problème d'upload après build, elle ne règle pas entièrement le problème download pour edit.
Je m'explique:
- j'ai bien compris que les fichiers sont toujours en local et synchronisés sur le serveur.
- mais
1- à chaque edit/lancement de scripter, le dernier setup utilisé est ouvert meme si on change de paquet à éditer
2- la version du paquet dans control doit donc être mise à jour manuellement (il faut le préciser dans la doc)
donc 2 sources faciles d'erreur... l'erreur est humaine.
N'avez-vous pas un moyen d'automatiser ce processus pour les paquets volumineux à intégrer/synchroniser en externe (nooon nous ne sommes pas fainéants juste des informaticiens dans une salle ressemblant à un tombeau égyptien avec une multitude d'épées de Damoclès justes au-dessus de nos 3 cm de chevelure... et chronos contre nous...)

[florentR2]

Si j'ai bien tout suivi, ce qui pourrait vous aider serait de séparer votre package en 2.
D'un coté les fichiers "lourds", et de l'autre les scripts ou fichiers de conf que vous avez besoin de modifier souvent ?
Et mettre le package avec les fichiers lourds en dépendance.

Ce qui fait que vous pourrez éditer rapidement le package avec les scripts et fichiers de conf, ça résoudrait aussi votre souci du numéro de sous version qui s'incrémentera tout seul.

[vcardon]

Et mettre le package avec les fichiers lourds en dépendance.

Excellente idée, je n'y avais pas pensé. Oui, c'est ce qu'il faut faire.

Vincent