Svn was not found in your PATH, skipping source download

Using Trellis v1.14.0, I’m getting following error (suddenly, perhaps after adding some site, wpackagist plugins) on deploy to staging but not to production server.

Now trying to download from source", "    Failed to download wpackagist-plugin/ultimate-addons-for-gutenberg from dist: \
curl error 28 while downloading https://downloads.wordpress.org/plugin/ultimate-addons-for-gutenberg.1.25.4.zip: \
Connection timed out after 10004 milliseconds", "    \
Now trying to download from source", "", \
"In SvnDownloader.php line 39:", "", \
"svn was not found in your PATH, skipping source download  ", "                                                            

I checked and svn isn’t available (to admin or web user) on production either, via command line.

Seems similar to this thread and I ran trellis provision --tags php staging again, but same result.

The exception comes from:

    protected function doDownload(PackageInterface $package, $path, $url, PackageInterface $prevPackage = null)
    {
        SvnUtil::cleanEnv();
        $util = new SvnUtil($url, $this->io, $this->config, $this->process);
        if (null === $util->binaryVersion()) {
            throw new \RuntimeException('svn was not found in your PATH, skipping source download');
        }

        return \React\Promise\resolve();
    }

I’m pretty sure that apt install subversion isn’t the Trellis solution, even if it would work.

Any suggestions?

Incidentally, I’m not sure where exactly the file that this code resides in is.

Running which composer leads me, locally, to /usr/local/Cellar/composer.

While grep -ri "doDownload(PackageInterface" /usr/local/Cellar returns:

Binary file /usr/local/Cellar/wp-cli/2.6.0/bin/wp matches
Binary file /usr/local/Cellar/composer/2.3.4/bin/composer matches

(Note trellis provision --tags wp-cli staging also not a solution.)

The SVN part isn’t the actual issue; it’s just a fallback method to download from source because the normal “dist” method timed out:

Failed to download wpackagist-plugin/ultimate-addons-for-gutenberg from dist: \
curl error 28 while downloading https://downloads.wordpress.org/plugin/ultimate-addons-for-gutenberg.1.25.4.zip: \

So there’s some connectivity/networking issue on your server where that URL times out. Hard to say what the problem could be, but I’d suggest debugging that using curl’s verbose mode to see what’s going on.

Thanks, Scott.

curl https://downloads.wordpress.org/plugin/ultimate-addons-for-gutenberg.1.25.4.zip -vvv
*   Trying 198.143.164.250:443...
* TCP_NODELAY set
* connect to 198.143.164.250 port 443 failed: Connection timed out
* Failed to connect to downloads.wordpress.org port 443: Connection timed out
* Closing connection 0
curl: (28) Failed to connect to downloads.wordpress.org port 443: Connection timed out

Same with --no-tcp-nodelay flag (minus that step).

Tried wget which also fails on wordpress.org but not on other sites (google,com).

I’m thinking maybe one of the steps from this SO post:

  1. Verify name servers are correct within /etc/resolv.conf
nameserver 127.0.0.53
options edns0 trust-ad

Matches production, so assuming correct.

  1. If #1 resolv settings are are correct for primary and secondary nameservers, verify that 192.168.10.10 has the ability to resolve hosts. (simple nslookup to google.com is a good test for this, if timeout occurs then then this could be part of the issue)
Server:		127.0.0.53
Address:	127.0.0.53#53

Non-authoritative answer:
Name:	google.com
Address: 142.250.188.14
Name:	google.com
Address: 2607:f8b0:4005:806::200e

And

nslookup wordpress.org
Server:		127.0.0.53
Address:	127.0.0.53#53

Non-authoritative answer:
Name:	wordpress.org
Address: 198.143.164.252
  1. Ensure that your nginx server has the ability to query name servers externally or internally via firewall (port 53 tcp/udp)

Not sure how to do that. It’s a brand new DO droplet.

  1. Look for potential resolver settings within nginx configuration options and or set resolution timeout setting where applicable and restart nginx.

Again, at a loss. Re-ran the nginx provisioning tag.

  1. If its still an issue attempt to add the host of the incoming request connection within /etc/hosts on 192.168.10.10.

Do they mean this:

198.143.164.250   downloads.wordpress.org

And if so, would I do that within Trellis?

Probably, but /etc/hosts just fixes DNS resolution issues. From your curl example, the host is already resolving to that IP:

curl https://downloads.wordpress.org/plugin/ultimate-addons-for-gutenberg.1.25.4.zip -vvv
*   Trying 198.143.164.250:443...

So adding 198.143.164.250 downloads.wordpress.org to your hosts file just seems redundant, but I suppose it’s worth a try :man_shrugging:

I’d ignore doing things the “trellis way” for now and just manually modify /etc/hosts to see if it helps.

I’m not sure how much more help I can offer beyond this, but if possible I’d just re-create a new staging server and see if that fixes it.

1 Like