Page 1 of 2
Packet resignation error (WAPT 2.0 transition)
Published: June 9, 2021 - 11:04 AM
by Christophe0110
Hello,
I've finally decided to take the time to upgrade my WAPT 1.8.2 Enterprise version to WAPT 2.0 Enterprise.
I'm using two servers:
- A test server running Debian 10.
- A production server running Windows Server.
Logically, I started by upgrading the test server running Debian.
After encountering some problems during the upgrade, I successfully upgraded to WAPT 2.0.
Next came the resigning of the hosts and packages.
No problems with the hosts.
However, the console showed several "Read timeout" errors for various packages (some of which were over 4 GB).
So, I followed the documentation's method and tried resigning directly from the server using a command line.
Several packages that initially failed were successfully resigned, except for three that were 5.7 GB, 5.7 GB, and 6.6 GB.
The error displayed is: BadZipFile('Bad magic number for file header').
I've often encountered this error when deploying large packages, and I was able to avoid it by editing the client_max_body_size parameter in the server's /etc/nginx/sites-enabled/wapt.conf file. The file is still correctly configured (it hasn't changed after the update), and the problem persists.
Do you have any suggestions on how I can deploy these packages without having to rebuild and install a new version, which would trigger an update on all machines (and given the package size, I really don't want to go down that road)?
Thank you.
Re: Package resignation error (WAPT 2.0 transition)
Published: June 10, 2021 - 10:22
by Christophe0110
Continuing the saga:
I then tried to upgrade the WAPT server to Windows 2.0.
After the update, I couldn't start the console...
I had to restore the VM and start over, and who knows why... It worked the second time...
However, I couldn't resign the packages via the console (I got a "Read timed out" message as soon as a package was over 400 MB)...
And of course, there's no documentation explaining how to resign them from the server (Windows), unlike under Linux...
I expected to have problems during the 2.0 update, but not to this extent... I'm rather disappointed...
Not very reliable.
So I'll probably have to pay for support tickets just to upgrade to version 2.0... And frankly, I find that a bit much...
A cheaper solution would be to rebuild the packages that aren't working... It will take time, but that's probably what I'll do to avoid €900 in support tickets...
Re: Package resignation error (WAPT 2.0 transition)
Published: June 10, 2021 - 3:55 PM
by jacky35
In the Nginx file - /etc/nginx/sites-enabled/wapt.conf
Be careful, there are two places where client_max_body_size is found.
I don't know why Tranquil IT doesn't set this option to client_max_body_size 0 by default;
But there is certainly a reason.
I did some research to find out why my windows10-upgrade-data package wouldn't upload correctly to the WAPT server
Jacky
Christophe0110 wrote: ↑June 9, 2021 - 11:04 AM
Hello,
I finally decided to take the time to upgrade my WAPT version from 1.8.2 Enterprise to WAPT 2.0 Enterprise.
I use two servers:
- A test server running Debian 10.
- A production server running Windows Server.
Logically, I started by updating the test server running Debian.
After encountering some problems during the update, I successfully upgraded to WAPT 2.0.
Then came the resigning of the hosts and packages.
No problems with the hosts.
However, via the console, I got several "Read timeout" errors on several packages (the largest of which were, in some cases, over 4 GB).
So I followed the documentation's method by trying a resignation directly from the server using a command.
Several packages that initially failed were successfully resigned, except for three of them, which were 5.7 GB; 5.7 GB and 6.6 GB.
The error displayed is: BadZipFile('Bad magic number for file header').
I've often encountered this error when deploying large packages, and I was able to avoid it by editing the client_max_body_size parameter in the server's /etc/nginx/sites-enabled/wapt.conf file. The file is still correctly configured (it hasn't changed after the update), and the problem persists.
Do you have any suggestions on how I can deploy these packages without having to rebuild and install a new version, which would trigger an update on all machines (and given the package size, I really don't want to go down that road)?
Thank you.
Re: Package resignation error (WAPT 2.0 transition)
Published: June 11, 2021 - 1:59 PM
by Christophe0110
Thanks for your reply, jacky35!
Yes, under Linux I was able to edit that file and both locations.
Under Windows, I found a file (with only one location within it) where that parameter was located.
However, it doesn't change anything; the WAPT console seems to have a real aversion to large packages.
I don't understand it; surely I'm not the only one with packages larger than 400MB...
Oh well, never mind, I'll have to do as I said and rebuild the 11 packages that won't work...
Re: Package resignation error (WAPT 2.0 transition)
Published: June 15, 2021 - 10:49
by dcardon
Christophe0110 wrote: ↑June 9, 2021 - 11:04 AM
I've often encountered this error when deploying large packages, and I was able to avoid it by editing the `client_max_body_size` parameter in the server's `/etc/nginx/sites-enabled/wapt.conf` file. The file is still correctly configured (it hasn't changed after the update), and the problem persists.
If client_max_body_size in nginx has not been modified following the update, it is because you have not launched the postconf and therefore have not followed the procedure to the end (client_max_body_size is not yet parameterized in the nginx template).
Re: Package resignation error (WAPT 2.0 transition)
Published: June 15, 2021 - 10:52 AM
by dcardon
jacky35 wrote: ↑June 10, 2021 - 3:55 PM
In the Nginx file - /etc/nginx/sites-enabled/wapt.conf
Be careful, there are two places where you can find client_max_body_size.
I don't know why Tranquil IT doesn't set this option to client_max_body_size 0 by default;
but there's certainly a reason.
The server needs to cache the files somewhere. Allowing unlimited uploads risks saturating its temporary disk space or available RAM, potentially leading to a DoS attack. So yes, there's a reason. However, this setting will be stored in waptserver.ini in the future and automatically used in the nginx configuration file.
Re: Package resignation error (WAPT 2.0 transition)
Published: June 15, 2021 - 10:53
by dcardon
Christophe0110 wrote: ↑June 11, 2021 - 1:59 PM
Thanks for your reply, jacky35!
Yes, under Linux I was able to edit that file and those two locations.
Under Windows, I found a file (with only one location within the file) where that parameter was located.
However, it doesn't change anything; the WAPT console seems to be completely allergic to large packages.
I don't understand; surely I'm not the only one with packages larger than 400MB...
Oh well, never mind, I'll have to do as I said and rebuild the 11 packages that won't work...
Note: Nginx needs to have enough disk space available to store the file chunks during the upload.
Re: Package resignation error (WAPT 2.0 transition)
Published: June 15, 2021 - 11:06 AM
by dcardon
Hello Christophe,
Christophe0110 wrote: ↑June 10, 2021 - 10:22 AM
So I'll probably have to pay for support tickets just to upgrade to version 2.0... And frankly, I find that a bit much...
A cheaper solution would be to rebuild the faulty packages... It will take time, but that's probably what I'll do to avoid €900 in support tickets...
Insider info: Tranquil IT is a software publisher, not an IT services company. We don't try to push ticket sales; it's not our main revenue stream (not by a long shot). And I want to emphasize that most of the support requests we receive are documented in the WAPT documentation, so in a way, it's more about saving customers time (time is money)... We try to cover as many scenarios as possible in the upgrade process (and it takes us a lot of time), but we can't account for all the oddities people do on their network (creativity, whether necessary or superfluous, knows no bounds) or account for all the mistakes people make while following procedures.
Sincerely,
Denis Cardon
Re: Package resignation error (WAPT 2.0 transition)
Published: June 17, 2021 - 08:59
by Christophe0110
Good morning,
dcardon wrote: ↑June 15, 2021 - 10:49
If the client_max_body_size in nginx has not been modified following the update, it is because you have not launched the postconf and therefore have not followed the procedure to the end (the client_max_body_size is not yet parameterized in the nginx template).
If we are talking about the command /opt/wapt/waptserver/scripts/postconf.sh, yes, I did launch it and I followed the procedure to the end.
I have therefore read (still within the procedure) the following instruction just above the command:
If you have customized the Nginx configuration, do not answer Yes when postconf asks you to configure Nginx
Since that was the case, I didn't answer "Yes," and therefore, that's probably why the nginx configuration didn't change in my case...
dcardon wrote: ↑June 15, 2021 - 10:53
Note: Nginx needs to have enough disk space available to store the file chunks during the upload.
If we are talking about the remaining space on the Windows server on which WAPT is installed, there is 443 GB of free space... I don't think, therefore, that this is the cause of the problem.
dcardon wrote: ↑June 15, 2021 - 11:06 AM
Hello Christophe,
Insider info: Tranquil IT is a software publisher, not an IT services company. We don't try to push ticket sales; it's not our main source of revenue (not by a long shot). And I want to emphasize that most of the support requests we receive are documented in the WAPT documentation, so in a way, it's more about saving customers time (time is money)... We try to cover as many scenarios as possible in the upgrade processes (and it takes us a lot of time), but we can't account for all the odd things people do on their network (creativity, whether necessary or superfluous, knows no bounds) or account for all the mistakes people make while following the procedures.
Best regards,
Denis Cardon
I don't consider my packages to be anything unusual. They're quite basic, and when I want to deploy an AutoCAD package en masse (and I can't be the only one in this situation), it seems logical to me that the package would be over 400MB... And as for following the procedure, I can tell you that I followed it to the letter (and in the case of the Windows server, twice, as I explained earlier). I don't mind paying for support tickets if I have to reinstall a server and encounter a problem, or if I try to create a package that doesn't work. But having to pay for support for an update that doesn't work, even though I followed the documentation correctly, I don't think that's right. That's just my opinion.
Christophe.
Re: Package resignation error (WAPT 2.0 transition)
Published: June 18, 2021 - 5:17 PM
by vcardon
However, the documentation clearly states that a Linux server is better suited for production.
I'm writing here to emphasize to any readers who might come across this post that a WAPT server running Windows is a courtesy, not a commitment.
You have the solution to your problem in your first post. Why not use Debian 10 for your production environment, as you successfully do for your pre-production environment? If your management insists on using a supported OS for your production environment, then Red Hat will be your best choice.