Buildout fails with "download error ... hostname doesn't match"

Plone Support
1

I am trying to recover an old Plone 4 site after a disk crash, rebuilding Plone from scratch. I'm able to build the basic Plone 4.3.6 via the unified installer and get the site running using a backup of my old Data.fs and blobstorage. But the site used (and needs) the Products.PloneLDAP egg and when I try to add that, updating building.cfg and running buildout, it always fails like this:

$ sudo -u plone_buildout ./bin/buildout
Installing instance.
Download error on http://download.zope.org/ppix/: hostname 'download.zope.org' doesn't match 'vm06.plyp.com' -- Some packages may not be found!
Download error on http://download.zope.org/distribution/: hostname 'download.zope.org' doesn't match 'vm06.plyp.com' -- Some packages may not be found!
Download error on http://effbot.org/downloads: hostname 'effbot.org' doesn't match either of 'www.github.com', '*.github.com', 'github.com', '*.github.io', 'github.io', '*.githubusercontent.com', 'githubusercontent.com' -- Some packages may not be found!
Couldn't find index page for 'Products.PloneLDAP' (maybe misspelled?)
Getting distribution for 'Products.PloneLDAP'.
Couldn't find index page for 'Products.PloneLDAP' (maybe misspelled?)
While:
  Installing instance.
  Getting distribution for 'Products.PloneLDAP'.
Error: Couldn't find a distribution for 'Products.PloneLDAP'.

This is on a server running Red Hat Enterprise Linux Server release 7.9 (Maipo).

I have spent many hours trying to find a workaround, with no joy.

This topic, Pypi Deprecation of support for non-SNI clients breaks buildout for older Plone versions, seems to be relevant but I've been unable to work out a solution from it.

I've also tried Plone 5 and hit the same kind of fatal error, but with fewer "download error" messages for some reason.

What can I do to get this to work? Should I give up on the unified installer and try building plone at a lower level?

2

Products.PloneLDAP is on PyPI.

There have been important changes for PyPI access. Check that all current requirements are fullfilled.

In necessary, download the distribution from PyPI manually and put it into the buildout "donwload cache".

3

What is in your index= and find-links= values for [buildout]?

Are you using:

find-links = https://dist.plone.org/release/4.3.6
index = https://pypi.org/simple

Also, make sure to pin Products.PloneLDAP — it appears to exist on PyPI.

4

I have no idea how to do that. That's pretty much what my original question is about.

I will try downloading installing the Products.PloneLDAP egg into the cache as suggested.

But this feels like a pervasive problem that begs for a more general solution. Seems like anyone adding additional eggs to the default config would face this same problem. Is there something special about my situation?

5

I modified my buildout.cfg slightly per your comment, and running buildout results in the same errors as before.

diff -r 956990a5dcac buildout.cfg
--- a/buildout.cfg	Fri Nov 05 13:52:38 2021 -0500
+++ b/buildout.cfg	Sun Nov 07 09:53:03 2021 -0600
@@ -37,13 +37,15 @@
 #
 extends =
     base.cfg
-    versions.cfg
-#    http://dist.plone.org/release/4.3.6/versions.cfg
+#    versions.cfg
+    https://dist.plone.org/release/4.3.6/versions.cfg

 # If you change your Plone version, you'll also need to update
 # the repository link below.
 find-links +=
-    http://dist.plone.org/release/4.3.6
+    https://dist.plone.org/release/4.3.6
+
+index = https://pypi.org/simple

 # If you try to start Zope as root, it will change user id to run as
 # the effective user specified here. This user id must own the var directory
@@ -71,6 +73,7 @@
 eggs =
     Plone
     Pillow
+    Products.PloneLDAP

 ############################################
 # ZCML Slugs

Also, where would I pin Products.PloneLDAP?

6

You can pin it for example, at the end of the buildout.cfg in the [versions] part :

[versions]
Cheetah = 2.2.1
plone.recipe.command = 1.1
plone.recipe.precompiler = 0.6
plone.recipe.unifiedinstaller = 4.3.1
...
Products.PloneLDAP = x.x.x
7

I downloaded the source distribution for Products.PloneLDAP into buildout-cache/downloads/dist and that allows buildout to get further, but it then fails for implicit dependencies of that package. Chasing those down I also installed source for Products.LDAPUserFolder, Products.LDAPMultiPlugins, and python-ldap. But then it fails with

Error: Couldn't find a distribution for 'Zope>=4.0b5'

So now I'm stuck again. What can I try now?

(Also, I am building Plone version 4.3.19 now, rather than 4.3.6 as in my original message. Near as I can tell, 4.3.19 is the newest available distribution of the Plone 4 series. 4.3.19 has the same "download errors" through, sadly. I've wasted so many hours on this...)

8

One of the distributions you have added is for a newer Zope/Plone. You must find versions compatible with your old Plone version.
You might find hints towards those versions from the change logs.

In the future, ensure to always have sufficiently recent backups. They can save you a lot of time and effort.

9

I've got backups of the plone data -- Data.fs and blobstorage. I think I have all the plone/zope/python stuff too, but that was on an older server (RHEL 5 or 6, I believe) that I don't want to try to clone. I never thought that reinstalling Plone would break so badly. The business with "download error" looks like a fundamental problem in the Plone buildout machinery.

I think I'm going to stand up a read-only version of our site (without LDAP, just basic auth) and suggest that we port the content to a different CMS.

10

Any system composed from many components is threatened by aging: the various components are likely to evolve and it gets more and more difficult to keep an old version running.

A client (initially using Plone 3, then Plone 4.2) had a similar problem. He first was forced to upgrade the Python infrastructure -- because modern web servers required stricter protocols (related to HTTPS) and therefore a newer openssl library was necessary which in turn implied a newer Python (2.7.13 instead of 2.7.3). The next step was an upgrade of zc.buildout and setuptools to accommodate the new "wheel" distribution format. Including newer components led to more and more problems with older ones; this finally convinced the client to upgrade to Plone 5.2. The next step will be a migration to Python 3.

Your problems might be related to outdated versions of Python, setuptools and zc.buildout. This forum contains various threads on how to upgrade those components.

You wrote that "I have all the plone/zope/python stuff". This should tell you the component versions your old system has run with. It can be a starting point for your new setup.

11

I totally agree. But if you've the backup, it should be enough to copy it over the new server and start it. Maybe you will miss some libraries, but it works.

I've an old Plone 3.1 installation from 2010, started with a 32 bit debian. Now it is running on a Debian Buster 64 bit. I would never run buildout again.

12

Your problems might be related to outdated versions of Python, setuptools and zc.buildout . This forum contains various threads on how to upgrade those components.

That is what I want to do too...

Do you remember a link to a thread ?
I will make a search too.

Thanks.

13

I was just able to get our plone site working by installing a copy of practically all of the /usr/local from the old site (locally built python 2.7.5 and all of the plone installation). I had to set LD_LIBRARY_PATH=/usr/local/lib to pick up the (restored) locally built libpython2.7.so.1.0 instead of the system one. Now LDAP authentication runs.

Since I can't even build (only restore) a plone that works for me, and the upgrade path ("outdated versions of Python, setuptools and zc.buildout ...", newer components, etc) looks like a ton of work that requires combing through various forum threads to find steps that actually work (and many that do not, based on my last week) I can't in good conscience recommend to my group that we continue using Plone. This is much my fault in not keeping our plone instance more up to date; we had a working system that did all we needed (on an intranet) and I let it ride. Still, it's a shame that there is not a straightforward upgrade path.

14

If you mean Plone 4, understandably so. Keep in mind that its successor Plone 5 was released five years ago and that, as others have already pointed out, an upgrade path is (still) available. Please don't blame Plone for not making regular backups, keeping up with somewhat recent releases, and generally not having a redundant infrastructure.

1 Like
15

I dont think you are talking about the upgrade path. The reason these are outdated is because 'you setup is outdated'.

The exact same could happen if you had other systems (for example a wordpress site that is more than 6 years old).

If you dont have too many add-ons, it could even be possible to

  1. Install a new, fresh Plone 5 ( or 6 )
  2. Copy the 'var' folder to the new site
  3. update buildout.cfg
  4. start you Plone and run upgrade path.

Another option is to export you content from you site and import it in newer Plone (especially if you dont need to keep 'user permissions').

1 Like
16

I did try installing a fresh Plone instance from scratch, both Plone 4 and Plone 5. In neither case was I able to get the Products.PloneLDAP egg to install. Both did allow me to view the content from the site (by copying in the old Data.fs and blobstorage). But I need access control via LDAP. The problems with downloading from PiPY -- what some here said come from outdated setuptools and such -- appear in a from-scratch installation of Plone, so I don't see how my "setup could be dated".

I did try upgrading that content as well and ran into various hard failures that crash with deep python stack traces. After spending days on this trying every workaround that I could think of or find by grubbing around the forum and what's available via google, I gave up for now in frustration.

I haven't looked into exporting content and importing it into newer Plone. I may give that a try.

17

There are many possible reasons why the installation of a package fails. Carefully reading the failure messages is usually a good starting point. Usually, reading a package's metadata on PyPI (which Python, Zope versions are supported) is also helpful/necessary.