either debian 12 or ubuntu 22.04 running in an LXC container on proxmox
Webmin version
2.105
Virtualmin version
7.10
Related packages
fresh install, then installing Wordpress Script - Ver: 6.5.2
Hi all
I’m pulling my hair out. a few weeks ago, I noticed that Wordpress failed to update and the error message showed that curl did not receive the expected number of bytes (or something like that). I did some googling and could not find a fix for this, other than the basic 101 - 5 things to check, blah blah… as well as making sure the latest patches/updates were installed.
So, I dug out a new machine, installed the latest proxmox 8.1.10 updated the container templates for ubuntu and debian, created the containers, gave plenty of disk space (32GB) for testing and 4GB ram.
On both, I updated and upgraded the OS and then installed curl (+ sudo on debian) and then applied the Virtualmin curl script from the virtualmin install guide.
In webmin, I created a new virtual server and then tried to install the Wordpress script. After downloading a few MB, I receive the error Fatal Error!
Failed to install script : Download of https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar failed : Download incomplete
This is after a fresh install of all of the latest patches and software.
I’ve checked for solutions, and checked the logs and other than the error showing in the webmin error log I’m stumped. This problem has only been around this last few weeks and I’m wondering where I start to get this fixed.
One day it works and without any changes, the next day - boom.
I fudged the virtualmin Wordpress install script to get the file from a local domain on my network and it came down just fine.
Installing other scripts - phpMyadmin and Roundcube installed just fine. If there was a network problem, lets say, then I should not even have been able to install virtualmin - no?
I managed to install the scripts for phpMyadmin and roundcube just fine, but not concerning Wordpress.
Coming back to your suggestion that it’s a network issue - how exactly can that be so? If you have specific ideas, I would like to look into them. Both my router and switch have not changed, nor have their configurations, I use no firewall or DNS server. It’s a vanilla setup - so to speak, so there should be no network limitation.
I believe the default timeout is set to Indefinite and I for sure have not messed with it. It’s all a fresh install.
Also, if there was such a timeout, as I said earlier, if this was so, logic would dictate that I could not have installed virtualmin or the other scripts. It’s only the Wordpress scripts that are showing issues.
Virtualmin isn’t even on the same server. That isn’t a useful data point.
And, curl has a default timeout, you don’t have to specify or configure it, it’s built-in (most network clients have some sort of timeout logic, so a connection won’t hang forever with no data coming in). Does curl have a timeout? - Unix & Linux Stack Exchange
And, “intermittent” means it doesn’t always happen. Since your downloads sometimes succeed and sometimes fail, I believe it has nothing to do with wget or curl and everything to do with that intermittent connectivity problem; it may be that one client will exhibit the problem more often because it is less forgiving of long delays, if it has a longer default timeout.
Noted about the server not being the same, but comparing apples with apples, I was going just on the timeout issue alone.
Yes, I already researched the default timeout and I agree there is and has to be a limit, but nothing has changed from one day to the next and even on a fresh server. The virtualmin script as far as I can determine does not set a timeout. From what I can see, CURL is working fine with other scripts and sites. So I’m snookered.
I don’t even know how I can test for an intermittent connection, if as you suggest that is what it is. This is affecting now all of my Virtualmin instances on 3 different servers.
Here are the results for running curl in the terminal - on the new server
root@vmin:~# curl -f https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar -o wpphar
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 6831k 100 6831k 0 0 1158k 0 0:00:05 0:00:05 --:--:-- 1276k
root@vmin:~# curl -f https://wordpress.org/wordpress-6.5.2.tar.gz -o wp.tar.gz
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 23.5M 100 23.5M 0 0 1135k 0 0:00:21 0:00:21 --:--:-- 1104k
root@vmin:~#
both the files download in terminal every time, but not through the install script.
I’ve done ping tests, speed tests and nothing is being dropped.
I had a weird problem transferring files between two machines because of some weird DNS/Hostfile thing. Try an entry in your host file for the site and see if that helps.
Network problems are out of our control. I don’t know what to suggest, but, it’s clearly a network issue.
If the container is running on a system you control, I recommend you test the exact same download on the host system (the physical server hosting the container) to rule out problems with that layer of the network. If that also fails, take it up with your network provider.
If it’s a container provided by a hosting provider and you don’t have access to the host server, you’d need to take it up with the provider.
Yes, I tried the commands on the host just now, both the terminal for the host AND the virtual machine download fine. Again, just not through the script installer.
Further, one server is running an old version (20.04) of ubuntu server in Virtualbox and nothing to do with proxmox and I find the exact same thing happens there - I cannot install Wordpress through the script. but I can download through the terminal.
So, the only common thing is the internet connection. Works in terminal but not with the script
There is no proxy as far as I know. I’m not using cloudflare or anything else.
No special DNS settings, no firewall.
Just a plain vanilla install with computer connected directly to the router and apart from a few DHCP settings on the router - all default settings as they have been for the last 4 years.
