[GELÖST] Das Kopieren großer Dateien über das Netzwerk stoppt

[d3sys]

Hallo, wir haben versucht, ein Paket für eine Business-Software-Suite, ähnlich der Adobe Suite, zu erstellen. Da die Installation sehr groß ist, mussten wir sie zur Verwaltung von Updates und Bugfixes auf einem NAS (über eine SMB3-Netzwerkfreigabe) ablegen.
Aktuell schlägt die Installation fehl, weil der Ordner nicht vollständig auf den Client-Rechner kopiert wird. Wir haben Copytree und filecopy2 erfolglos ausprobiert. Nur `run_powershell copy-item` scheint etwas besser zu funktionieren, aber auch hier ist dies nicht der Fall (manchmal ignoriert Wapt die Befehlszeile komplett und kopiert nichts).

Wapt: 1.8.1,
WaptServer: Debian 10,
ConsoleWapt: Windows 10

[vCardon]

Hallo, wir haben versucht, ein Paket für eine Business-Software-Suite zu erstellen, ähnlich der Adobe Suite. Dabei sind wir auf das Problem gestoßen, dass die Installation sehr groß ist.

Das größte uns bekannte Paket ist ein National Instruments Labview mit vielen Modulen, etwa 70 GB groß, das auf klassische Weise über einen Web-Download vertrieben wird.

Ich rate davon ab, Ihre Pakete über SMB zu verteilen (siehe https://www.wapt.fr/fr/doc/wapt-common- ... takes.html), es ist hässlich.

Es gibt keinen Grund, warum das nicht funktionieren sollte. Überprüfen Sie die Protokolle Ihres Webservers, um die Ursache der Blockierung zu finden; es muss irgendwo eine technische Einschränkung vorliegen, die Sie beheben müssen.

Aufrichtig.

Vincent

[d3sys]

Ich rate davon ab, Ihre Pakete über SMB zu verteilen (siehe https://www.wapt.fr/fr/doc/wapt-common- ... takes.html), das ist unschön.

Viele Grüße,

Vincent

Danke für den Link, aber ich habe ihn bereits gelesen. Das Problem ist, dass die Dokumentation zwar gut geschrieben und durchdacht ist, aber sehr kurz gefasst und insbesondere im Hinblick auf die Paketerstellung recht unzureichend. Die meisten erklärten Funktionen betreffen die Dateimanipulation, und wofür eignet sich SMB am besten?.

Das bedeutet nun, dass wir einen Webserver auf dem WAPT-Server installieren müssen. Die Frage ist: Wie können wir dies sauber programmieren, um nach der Installation einen kompletten Ordner (ca. 80 GB) in den Ordner unserer Anwendung zu übertragen und anschließend die je nach Benutzer anzuwendenden Patches auszuführen?
- Die Dokumentation (sofern ich sie nicht übersehen habe) ging nicht näher auf den Dateiaustausch über WebServer ein; wir wissen nicht, ob es eine gute Idee ist, einen Webserver auf dem WAPT-Server zu starten.
- Übernimmt WAPT die Wiederherstellung im Falle eines HTTP/FTP-Verbindungsfehlers?

[Sfonteneau]

- Das bedeutet nun, dass wir einen Webserver auf dem WAPT-Server installieren müssen.

Wapt ist bereits ein Webserver, der Wapt-Pakete hostet. Sie müssen nichts weiter installieren.

Die Frage ist: Wie programmiert man das korrekt, um nach der Installation einen kompletten Ordner (ca. 80 GB) in den Anwendungsordner zu übertragen und anschließend die Patches entsprechend dem Benutzer anzuwenden?
– Die Dokumentation (sofern ich sie nicht übersehen habe) geht nicht detailliert auf den Dateiaustausch über den Webserver ein; wir wissen nicht, ob es ratsam ist, einen Webserver auf dem WAPT-Server zu betreiben.

Sie müssen lediglich den Ordner in Ihr Paket einfügen

Code: Alle auswählen

c:\waptdev\tis-copyfile

Dann im Paket:

Code: Alle auswählen

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

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

Für Code innerhalb der Benutzersitzung:

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

- Übernimmt WAPT die Wiederherstellung im Falle eines HTTP/FTP-Verbindungsfehlers?

Ja, absolut

[d3sys]

Wapt ist bereits ein Webserver, der Wapt-Pakete hostet. Sie müssen nichts weiter installieren.

Sie müssen lediglich den Ordner in Ihr Paket einfügen

Code: Alle auswählen

c:\waptdev\tis-copyfile

Dann im Paket:

Genau das wollen wir vermeiden. Es hat fast 24 Stunden gedauert, ein 5-GB-Paket zu versenden, und die Bearbeitung – nun ja, lassen wir das lieber. Stellen Sie sich vor, wie dringend ein Programmierfehler korrigiert werden muss, während die Datei vor und nach der Bearbeitung erneut heruntergeladen werden muss! Deshalb haben wir uns für den Dateiaustausch entschieden. Dadurch sind die Pakete deutlich kleiner (in Kilobyte!) und es gibt keine langwierigen Übertragungen mehr für nur eine einzige Codeänderung.
Es sei denn, wir machen es wirklich falsch (übrigens sind wir Programmierer, aber nicht in Python) Wir lernen also noch! Was ich durchaus verstehen kann... deshalb bitte ich um Klärung, unser Verständnis lässt nach...
Wir haben mit dieser Methode ein weiteres Problem: Unterordner werden bei der Installation scheinbar nicht berücksichtigt. Daher möchte ich zu einer praktischeren (saubereren) Methode zurückkehren ) aber es funktioniert sofort effektiv. Wo liegt also unser Fehler?

[vCardon]

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

+

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

wird Ihr Problem lösen.

Viele Grüße,

Vincent

[Sfonteneau]

Genau das wollen wir vermeiden. Es dauerte fast 24 Stunden, ein 5-GB-Paket zu versenden
, und was die Bearbeitung angeht, nun ja, fangen wir gar nicht erst damit an. Stellen Sie sich vor, wie dringend ein Programmierfehler korrigiert werden muss, während das erneute Herunterladen vor und nach der Bearbeitung so lange dauert! Deshalb haben wir uns für den Dateiaustausch entschieden. Dadurch sind die Pakete viel kleiner (in Kilobyte!) und es gibt keine langwierigen Übertragungen mehr für nur eine einzige Codeänderung.

24 Stunden. Das ist wirklich nicht der Fall Wirklich Das ist nicht normal. Befindet sich der Server in der Cloud oder im selben lokalen Netzwerk?

Wir haben ein weiteres Problem mit dieser Methode: Während der Installation scheinen Unterordner nicht berücksichtigt zu werden.

Ich habe gerade einen Test mit copytree2('sources','C:\\projet') durchgeführt

Die Unterordner wurden korrekt kopiert

Vereinfacht gesagt, verwenden wir die Methode „Alles im Paket“, um Installationsprobleme wie Kopierfehler, Timeouts, Netzwerkprobleme usw. zu vermeiden.

Es gibt auch einen Sicherheitsaspekt: ​​Wenn alles im Paket enthalten ist, ist alles signiert; wenn es nicht im Paket enthalten ist, kann wapt die Integrität der Dateien nicht garantieren, da sie nicht im Paketmanifest aufgeführt sind.

Wir müssen herausfinden, warum Ihr Upload so langsam ist! Liegt es an der Bandbreite oder an etwas anderem?

[d3sys]

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

+

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

wird Ihr Problem lösen.

Viele Grüße,

Vincent

Danke für den Hinweis. Um nicht unfreundlich oder zu stur zu wirken, kehrte ich mit meinem Team und besseren Vorsätzen zurück, um mit diesen wertvollen Informationen von vorn zu beginnen.

Laden Sie Ihr Paket mithilfe von WinSCP in das Verzeichnis `/var/www/html/wapt/` auf Ihrem Linux-Server hoch.

Nach Abschluss der Übertragung müssen Sie die Datei `Packages` in Ihrem Repository neu generieren:

`wapt-scanpackages /var/www/wapt/`

Wir laden hoch/synchronisieren in www/html/wapt dann scannen wir die in www/ enthaltenen Paketewapt/ Ist das ein Fehler?

Uhr 24 Std. Das ist wirklich, wirklich nicht normal

Das haben wir uns selbst gesagt... Abgesehen von einer Serverüberlastung (durchschnittlich 100 gleichzeitige Benutzer) sehe ich keine Ursache dafür, daher die Entscheidung zur Dezentralisierung.

Befindet sich der Server in der Cloud oder im selben lokalen Netzwerk?

Der Server ist eine Proxmox-VM in einem Gigabit-Lokalnetzwerk.

Die vorgeschlagene Lösung behebt zwar das Upload-Problem nach dem Build-Prozess, löst aber das Download-Problem für die Bearbeitung nicht vollständig.
Ich erkläre es Ihnen:
- Mir ist bekannt, dass die Dateien immer lokal gespeichert und auf dem Server synchronisiert werden.
- Aber
1- Jedes Mal, wenn der Scripter bearbeitet oder gestartet wird, wird die zuletzt verwendete Konfiguration geöffnet, selbst wenn das zu bearbeitende Paket geändert wird
2. Die zu verwaltende Paketversion muss daher manuell aktualisiert werden (dies muss in der Dokumentation angegeben werden)
Also, zwei leicht zu vermeidende Fehlerquellen... Irren ist menschlich.
Gibt es keine Möglichkeit, diesen Prozess für große Pakete zu automatisieren, die extern integriert/synchronisiert werden müssen? (Nein, wir sind nicht faul!) Nur Informatiker in einem Raum, der einem ägyptischen Grabmal mit einer Vielzahl von Damoklesschwertern ähnelt direkt über unseren 3 cm Haaren... (Und die Zeit drängt...)

[florentR2]

Wenn ich Sie richtig verstehe, könnte es helfen, Ihr Paket in zwei Teile zu teilen.
Auf der einen Seite die umfangreichen Dateien und auf der anderen die Skripte oder Konfigurationsdateien, die Sie häufig anpassen müssen.
Anschließend fügen Sie das Paket mit den umfangreichen Dateien als Abhängigkeit hinzu.

So können Sie das Paket mit den Skripten und Konfigurationsdateien schnell bearbeiten, und Ihr Problem mit der automatischen Subversionsnummernerhöhung wird gelöst.

[vCardon]

Und füge das Paket mit den großen Dateien als Abhängigkeit hinzu.

Ausgezeichnete Idee, daran hatte ich gar nicht gedacht. Ja, genau das muss getan werden.

Vincent