Ruhiges IT-Forum

Hallo,

ich habe mich endlich dazu entschlossen, mein WAPT 1.8.2 Enterprise auf WAPT 2.0 Enterprise zu aktualisieren.

Ich nutze zwei Server:
einen Testserver mit Debian 10
und einen Produktionsserver mit Windows Server.

Logischerweise habe ich mit dem Upgrade des Debian-Testservers begonnen.
Nach einigen Problemen während des Upgrades konnte ich WAPT 2.0 schließlich erfolgreich installieren.

Anschließend habe ich die Hosts und Pakete neu signiert.
Mit den Hosts gab es keine Probleme.
Die Konsole zeigte jedoch mehrere „Read timeout“-Fehler für verschiedene Pakete an (einige davon waren über 4 GB groß).
Daher bin ich der Dokumentation gefolgt und habe versucht, die Pakete direkt vom Server über die Kommandozeile neu zu signieren.
Mehrere Pakete, die zunächst nicht signiert werden konnten, wurden erfolgreich neu signiert, mit Ausnahme von drei Paketen mit einer Größe von 5,7 GB, 5,7 GB und 6,6 GB.
Die Fehlermeldung lautet: BadZipFile('Bad magic number for file header').

Ich bin beim Deployment großer Pakete häufiger auf diesen Fehler gestoßen und konnte ihn bisher durch Bearbeiten des Parameters `client_max_body_size` in der Datei `/etc/nginx/sites-enabled/wapt.conf` des Servers beheben. Die Datei ist weiterhin korrekt konfiguriert (sie hat sich nach dem Update nicht geändert), das Problem besteht aber weiterhin.

Haben Sie Vorschläge, wie ich diese Pakete bereitstellen kann, ohne sie neu kompilieren und eine neue Version installieren zu müssen? Das würde nämlich ein Update auf allen Rechnern auslösen (und angesichts der Paketgröße möchte ich das wirklich vermeiden).

Vielen Dank.

Die Geschichte geht weiter:

Ich habe versucht, den WAPT-Server auf Windows 2.0 zu aktualisieren.

Nach dem Update konnte ich die Konsole nicht mehr starten.

Ich musste die VM wiederherstellen und von vorne beginnen – warum auch immer. Beim zweiten Mal hat es dann funktioniert.

Allerdings konnte ich die Pakete nicht über die Konsole neu signieren (sobald ein Paket größer als 400 MB war, erhielt ich die Fehlermeldung „Zeitüberschreitung beim Lesen“).
Und natürlich gibt es, anders als unter Linux, keine Dokumentation, die erklärt, wie man die Pakete vom Server (Windows) aus neu signiert.

Ich hatte zwar mit Problemen beim 2.0-Update gerechnet, aber nicht in diesem Ausmaß. Ich bin ziemlich enttäuscht.

Nicht sehr zuverlässig.

Wahrscheinlich werde ich Support-Tickets bezahlen müssen, nur um auf Version 2.0 zu aktualisieren. Und ehrlich gesagt finde ich das etwas übertrieben.

Eine günstigere Lösung wäre, die nicht funktionierenden Pakete neu zu erstellen. Das wird zwar Zeit kosten, aber das werde ich wohl tun, um mir die 900 € für Support-Tickets zu sparen.

In der Nginx-Datei - /etc/nginx/sites-enabled/wapt.conf
Vorsicht, client_max_body_size kommt an zwei Stellen vor.

Ich weiß nicht, warum Tranquil IT diese Option nicht standardmäßig auf client_max_body_size 0 setzt;
Aber es gibt dafür sicherlich einen Grund.

Ich habe recherchiert, warum mein Windows10-Upgrade-Datenpaket nicht korrekt auf den WAPT-Server hochgeladen werden konnte

Jacky

Christophe0110 schrieb: ↑9. Juni 2021 - 11:04 Uhr Hallo,

ich habe mich endlich dazu entschlossen, meine WAPT-Version von 1.8.2 Enterprise auf WAPT 2.0 Enterprise zu aktualisieren.

Ich nutze zwei Server:
- Einen Testserver mit Debian 10.
- Einen Produktionsserver mit Windows Server.

Logischerweise habe ich mit dem Update des Debian-Testservers begonnen.
Nach einigen Problemen während des Updates konnte ich WAPT 2.0 erfolgreich installieren.

Anschließend folgte die Neusignierung der Hosts und Pakete.
Mit den Hosts gab es keine Probleme.
Über die Konsole erhielt ich jedoch mehrere „Read timeout“-Fehler bei verschiedenen Paketen (die größten davon waren teilweise über 4 GB groß). Daher
bin ich der Dokumentation gefolgt und habe versucht, die Pakete direkt vom Server aus per Befehl neu zu signieren.
Mehrere Pakete, bei denen die Neusignierung zunächst fehlgeschlagen war, konnten erfolgreich neu signiert werden, mit Ausnahme von drei Paketen mit einer Größe von 5,7 GB, 5,7 GB und 6,6 GB.
Die Fehlermeldung lautet: BadZipFile('Ungültige Magic Number für den Dateikopf').

Dieser Fehler tritt häufig beim Deployment großer Pakete auf. Bisher konnte ich ihn durch Bearbeiten des Parameters `client_max_body_size` in der Datei `/etc/nginx/sites-enabled/wapt.conf` des Servers beheben. Die Datei ist weiterhin korrekt konfiguriert (sie hat sich nach dem Update nicht geändert), das Problem besteht jedoch weiterhin.

Haben Sie Vorschläge, wie ich diese Pakete bereitstellen kann, ohne sie neu kompilieren und eine neue Version installieren zu müssen? Dies würde ein Update auf allen Rechnern auslösen (und angesichts der Paketgröße möchte ich das wirklich vermeiden).

Vielen Dank.

Danke für deine Antwort, jacky35!

Ja, unter Linux konnte ich die Datei und beide Speicherorte bearbeiten.

Unter Windows fand ich eine Datei (mit nur einem Speicherort darin), in der dieser Parameter stand.

Das ändert aber nichts; die WAPT-Konsole scheint große Pakete wirklich nicht zu mögen.
Ich verstehe das nicht; ich bin doch sicher nicht der Einzige mit Paketen über 400 MB...

Na ja, egal, ich muss wohl wie gesagt die 11 Pakete, die nicht funktionieren, neu kompilieren...

Christophe0110 schrieb: ↑9. Juni 2021 - 11:04 Uhr Ich bin beim Deployment großer Pakete häufig auf diesen Fehler gestoßen und konnte ihn beheben, indem ich den Parameter `client_max_body_size` in der Datei `/etc/nginx/sites-enabled/wapt.conf` des Servers angepasst habe. Die Datei ist weiterhin korrekt konfiguriert (sie hat sich nach dem Update nicht geändert), das Problem besteht aber weiterhin.

Wenn client_max_body_size in nginx nach dem Update nicht geändert wurde, liegt das daran, dass Sie postconf nicht gestartet und daher die Prozedur nicht vollständig befolgt haben (client_max_body_size ist in der nginx-Vorlage noch nicht parametrisiert).

jacky35 schrieb: ↑10. Juni 2021 - 15:55 Uhr In der Nginx-Konfigurationsdatei - /etc/nginx/sites-enabled/wapt.conf.
Achtung: Die Einstellung client_max_body_size findet sich an zwei Stellen.

Ich weiß nicht, warum Tranquil IT diese Option nicht standardmäßig auf client_max_body_size 0 setzt;
es gibt aber sicherlich einen Grund dafür.

Der Server muss die Dateien zwischenspeichern. Unbegrenzte Uploads bergen das Risiko, den temporären Speicherplatz oder den verfügbaren Arbeitsspeicher zu erschöpfen und potenziell einen Denial-of-Service-Angriff (DoS) auszulösen. Es gibt also einen Grund dafür. Diese Einstellung wird zukünftig in der Datei waptserver.ini gespeichert und automatisch in der Nginx-Konfigurationsdatei verwendet.

Christophe0110 schrieb: ↑11. Juni 2021 - 13:59 Uhr Danke für deine Antwort, jacky35!

Ja, unter Linux konnte ich die Datei und die beiden Speicherorte bearbeiten.

Unter Windows fand ich eine Datei (mit nur einem Eintrag), in der sich dieser Parameter befand.

Das ändert aber nichts; die WAPT-Konsole scheint große Pakete überhaupt nicht zu mögen.
Ich verstehe das nicht; ich bin doch sicher nicht der Einzige mit Paketen über 400 MB...

Na ja, egal, ich muss wohl wie gesagt die 11 Pakete, die nicht funktionieren, neu kompilieren...

Hinweis: Nginx benötigt ausreichend Speicherplatz, um die Dateifragmente während des Uploads zu speichern.

Hallo Christophe,

Christophe0110 schrieb: ↑10. Juni 2021 - 10:22 Uhr Ich werde wohl Support-Tickets bezahlen müssen, nur um auf Version 2.0 zu aktualisieren... Und ehrlich gesagt finde ich das etwas übertrieben...

Eine günstigere Lösung wäre, die fehlerhaften Pakete neu zu erstellen... Das wird zwar Zeit kosten, aber das werde ich wohl tun, um 900 € für Support-Tickets zu sparen...

Insider-Info: Tranquil IT ist ein Softwarehersteller, kein IT-Dienstleistungsunternehmen. Wir versuchen nicht, Support-Tickets zu verkaufen; das ist bei Weitem nicht unsere Haupteinnahmequelle. Und ich möchte betonen, dass die meisten Supportanfragen, die wir erhalten, in der WAPT-Dokumentation abgedeckt sind. Es geht also im Grunde darum, unseren Kunden Zeit zu sparen (Zeit ist Geld). Wir versuchen, im Upgrade-Prozess so viele Szenarien wie möglich abzudecken (was uns viel Zeit kostet), aber wir können nicht alle Eigenheiten berücksichtigen, die Nutzer in ihren Netzwerken anstellen (Kreativität kennt keine Grenzen, ob notwendig oder überflüssig) oder alle Fehler, die bei der Befolgung von Anweisungen passieren.

Aufrichtig,

Denis Cardon

Guten Morgen,

dcardon schrieb: ↑15. Juni 2021 - 10:49 Wenn die client_max_body_size in nginx nach dem Update nicht geändert wurde, liegt das daran, dass Sie postconf nicht ausgeführt und daher die Prozedur nicht vollständig befolgt haben (die client_max_body_size ist in der nginx-Vorlage noch nicht parametrisiert).

Wenn es um den Befehl /opt/wapt/waptserver/scripts/postconf.sh geht, ja, ich habe ihn ausgeführt und die Prozedur bis zum Ende befolgt.
Ich habe daher (noch innerhalb des Verfahrens) die folgende Anweisung direkt über dem Befehl gelesen:

Wenn Sie die Nginx-Konfiguration angepasst haben, antworten Sie nicht mit Ja, wenn postconf Sie auffordert, Nginx zu konfigurieren

Da dies der Fall war, habe ich nicht mit „Ja“ geantwortet, und deshalb hat sich die nginx-Konfiguration in meinem Fall wahrscheinlich nicht geändert...

dcardon schrieb: ↑15. Juni 2021 - 10:53 Hinweis: Nginx benötigt ausreichend Speicherplatz, um die Dateiteile während des Uploads zu speichern.

Wenn wir über den verbleibenden Speicherplatz auf dem Windows-Server sprechen, auf dem WAPT installiert ist, stehen 443 GB freier Speicherplatz zur Verfügung... Ich glaube daher nicht, dass dies die Ursache des Problems ist.

dcardon schrieb: ↑15. Juni 2021 - 11:06 Uhr Hallo Christophe,

Insider-Info: Tranquil IT ist ein Softwarehersteller, kein IT-Dienstleistungsunternehmen. Wir versuchen nicht, Support-Tickets zu verkaufen; das ist bei Weitem nicht unsere Haupteinnahmequelle. Und ich möchte betonen, dass die meisten Supportanfragen, die wir erhalten, in der WAPT-Dokumentation abgedeckt sind. Es geht also im Grunde darum, unseren Kunden Zeit zu sparen (Zeit ist Geld). Wir versuchen, in den Upgrade-Prozessen so viele Szenarien wie möglich abzudecken (was uns viel Zeit kostet), aber wir können nicht alle ungewöhnlichen Aktionen der Nutzer in ihren Netzwerken berücksichtigen (der Kreativität sind keine Grenzen gesetzt, ob notwendig oder überflüssig) oder alle Fehler, die bei der Befolgung der Anweisungen passieren.

Beste Grüße,

Denis Cardon

Ich halte meine Pakete nicht für ungewöhnlich. Sie sind recht einfach, und wenn ich ein AutoCAD-Paket massenhaft verteilen möchte (und ich bin sicher nicht der Einzige in dieser Situation), erscheint es mir logisch, dass das Paket über 400 MB groß ist. Was die Vorgehensweise angeht, kann ich Ihnen versichern, dass ich sie genau befolgt habe (und im Fall des Windows-Servers sogar zweimal, wie ich bereits erwähnt habe). Ich habe kein Problem damit, für Support-Tickets zu bezahlen, wenn ich einen Server neu installieren muss und dabei auf ein Problem stoße oder wenn ich versuche, ein Paket zu erstellen, das nicht funktioniert. Aber für Support für ein Update bezahlen zu müssen, das nicht funktioniert, obwohl ich die Dokumentation korrekt befolgt habe, finde ich nicht in Ordnung. Das ist nur meine Meinung.

Christophe.

Die Dokumentation besagt jedoch eindeutig, dass ein Linux-Server besser für den Produktivbetrieb geeignet ist.

Ich möchte hier allen Lesern, die diesen Beitrag finden, verdeutlichen, dass ein WAPT-Server unter Windows eine Option, aber keine Verpflichtung ist.

Die Lösung für Ihr Problem finden Sie in Ihrem ersten Beitrag. Warum verwenden Sie nicht Debian 10 für Ihre Produktionsumgebung, wie Sie es bereits erfolgreich in Ihrer Testumgebung tun? Falls Ihre Geschäftsleitung auf einem unterstützten Betriebssystem für Ihre Produktionsumgebung besteht, ist Red Hat die beste Wahl.

Ruhiges IT-Forum

Paketabbruchfehler (WAPT 2.0-Übergang)

Paketabbruchfehler (WAPT 2.0-Übergang)

Betreff: Paketabbruchfehler (WAPT 2.0-Umstellung)

Betreff: Paketabbruchfehler (WAPT 2.0-Umstellung)

Betreff: Paketabbruchfehler (WAPT 2.0-Umstellung)

Betreff: Paketabbruchfehler (WAPT 2.0-Umstellung)

Betreff: Paketabbruchfehler (WAPT 2.0-Umstellung)

Betreff: Paketabbruchfehler (WAPT 2.0-Umstellung)

Betreff: Paketabbruchfehler (WAPT 2.0-Umstellung)

Betreff: Paketabbruchfehler (WAPT 2.0-Umstellung)

Betreff: Paketabbruchfehler (WAPT 2.0-Umstellung)