Plone buildout error - /Python-2.7/bin/python: bad interpreter: No such file or directory

Hello,

Thank you in advance for any help on this.

This is a Plone site 4.3.3 being moved from a developer from Solaris zone to a CentOS 7 with Selinux now off. CentOS sees it's Python version correct (2.7.5 if I recall off top of head). However, the site will not start or build on commands.

./bin/plonectl start
./bin/buildout -No -c custom_buildout_file

with only error being bad interpreter (/Python-2.7/bin/python: bad interpreter: No such file or directory).

I did a download of Unified installer to another directory and successfully performed a target install of plone zeo install that starts fine, that was with Selinux enabled. So have the correct CentOS packages in place and in theory Selinux is not a factor. Set to permissive as well for now.

So, not sure where the Plone install calls or paths it's Python interpreter and/or if any corruption of the interpreter. The entire parent directory holding the site was rsynced over to CentOS with sym links being followed from a Solaris zone.

Any help please is appreciated :slight_smile:

Try bootstrapping the buildout with python2.7 bootstrap.py in your buildouts directory and then run buildout as you already tried. Does it work? If not, what is the error message?

Thank you. Not very familiar with such process.

Set permissions & altered all content to a plone user before your post:
chmod 774 bootstrap.py
-rwxrwxr--. 1 plone plone 5.6K Aug 5 2014 /opt/Plone-4.3.3/dir_name/bootstrap.py

./bootstrap.py

./bootstrap.py: line 19: $'Bootstrap a buildout-based project\n\nSimply run this script in a directory containing a buildout.cfg.\nThe script accepts buildout command-line options, so you can\nuse the -c option to specify an alternate configuration file.\n': command not found
./bootstrap.py: line 21: import: command not found
./bootstrap.py: line 22: import: command not found
./bootstrap.py: line 23: import: command not found
./bootstrap.py: line 24: import: command not found
./bootstrap.py: line 26: from: command not found
./bootstrap.py: line 28: syntax error near unexpected token (' ./bootstrap.py: line 28:tmpeggs = tempfile.mkdtemp()'

21 import os
22 import shutil
23 import sys
24 import tempfile
25
26 from optparse import OptionParser
27
28 tmpeggs = tempfile.mkdtemp()
29
30 usage = '''
31 [DESIRED PYTHON FOR BUILDOUT] bootstrap.py [options]

I really meant python2.7 bootstrap.py (./bootstrap.py itself is not standalone executable and the interpreter used in front of will be the same Plone later on is using)

Thank you Jens! I think I follow but in a sense... is it that rsync brought over the Solaris Python version (32 bit - apparent upgrades) so will not run on Linux. Essentially bootstrap call old python so buildout cannot build the new version as it is python script? Or am I totally missing what you're saying?

Any suggestions for next steps? Like can I use the CentOS Python bootstrap to try and replace or build the python version and mv over top Solaris version?

I think its more that the Python interpreter used is referenced in the first line of every script in the buildouts bin-folder. The Python interpreter should be outside of the buildout folder, so, not be part of that. I would first create a virtualenv in the buildout folder with executing virtualenv --clear . in the buildout folder. Now, it creates an isolated Python-interpreter binary in ./bin/python. This is handy, because you know no longer conflict with possible system-site-packages (and its versions). After that you can now safely bootstrap with ./bin/python bootstrap.py. I have to admit, that even here are minor version conflict are possible. It works in most cases, otherwise come back and tell us your output.

Another problem after moving from another system-architecture are the C-Extensions of Python modules. Those are handy, because it speeds up some parts, but they are compiled while buildout-time. The ones compiled on Solaris are not compatible with Linux and need to be recompiled, what happens in the buildout process.

Thank you that is good to know as I was not aware of such not being a dev. Suspect it is a little trivia that would come in handy for ongoing use of Plone.

Is that a literal folder on file system or a generic reference to /plone_path/bin, /plone_path/var, /plonepath/parts or __? Sorry haven't looked at Plone in a while and do not recall the parts directories with confidence in memory accuracy.

One last question. If I ensure protection of the data.fs, blobstorage, filestorage, and the devs. src files, should I be able to reproduce the site on Linux?

or possibly: Does running the Plone backups extract the actual OS where one can restore to Linux version and functioning site? Not sure if those backups are for same platform or can migrate.

Thank you!

Tried to copy of files and cfg. Can get partial buildout to work but not the custom.

Got this error:
Error while compiling /opt/ploneinstalls/Plone-4.3.3/idcrp/buildout-cache/eggs/python_gettext-1.2-py2.7.egg/pythongettext/tests/test_escape.po
Error while compiling /opt/ploneinstalls/Plone-4.3.3/idcrp/buildout-cache/eggs/python_gettext-1.2-py2.7.egg/pythongettext/tests/test5.po

Curious if this is possibly related to this post as get an PloneFormGen error for custom compile.

Jens,
Does builtout create a virtualenv when it is run - in that the unified installer would have built a virtualenv when it is executed?

"The Python interpreter should be outside of the buildout folder, "
I always thought, right or wrong, that the Python interpreter was the folder labeled Python-2.x which is parallel to buildout-cache, Plone-docs, zeocluser. Is that incorrect?

"I would first create a virtualenv in the buildout folder with executing virtualenv --clear . in the buildout folder."
Isn't the "buildout" folder the parent of those folders when running ./install.sh target="path to folder" where the for mentioned folders are deposited?

these messages appear everytime you do a Plone build. They are absolutely meaningless and appear for totally successful installations. See for example among many:

@gp54321 - Thank you. The Plone site did start following those errors which has been run as: ./bin/buildout.

That said, the developer appears to have a custom file build_file.cfg which I believe also calls builtout.cfg, versions.cfg, etc., etc. That particular scenario fails to build ./bin/buildout -No -c build_file.cfg.

@jensens
Used python2-pip with pip upgrade and install of virtualenv.
virtualenv --clear .
Not deleting /opt/path/bin
New python executable in /opt/path/bin/python2
Also creating executable in /opt/path/bin/pyhon
Installing setuptools, pip, wheel...done.

Please note my lack of knowledge in that I do not think this is correct in executing and thus the ? previously on directory structure and where bootstrap.py should appear on file system.

./bin/python zeocluster/bootstrap.py
Traceback (most recent call last):
File "zeocluster/bootstrap.py", line 136, in
if _final_version(distv):
File "zeocluster/bootstrap.py", line 122, in _final_version
for part in parsed_version:
TypeError: 'Version' object is not iterable

The site does still start but have not tried to repeat buildout yet with either cfg files. some additional files and a full activate type option under /opt/path/bin

-rw-rw-r--. 1 plone plone 2.1K Mar 29 11:07 activate
-rw-rw-r--. 1 plone plone 1.1K Mar 29 11:07 activate.csh
-rw-rw-r--. 1 plone plone 2.2K Mar 29 11:07 activate.fish
-rw-rw-r--. 1 plone plone 1.2K Mar 29 11:07 activate_this.py
-rwxrwxr-x. 1 plone plone 266 Mar 29 11:07 easy_install
-rwxrwxr-x. 1 plone plone 266 Mar 29 11:07 easy_install-2.7
-rwxrwxr-x. 1 plone plone 238 Mar 29 11:07 pip
-rwxrwxr-x. 1 plone plone 238 Mar 29 11:07 pip2
-rwxrwxr-x. 1 plone plone 238 Mar 29 11:07 pip2.7
lrwxrwxrwx. 1 plone plone 7 Mar 29 11:07 python -> python2
-rwxrwxr-x. 1 plone plone 7.0K Mar 29 11:07 python2
lrwxrwxrwx. 1 plone plone 7 Mar 29 11:07 python2.7 -> python2
-rwxrwxr-x. 1 plone plone 2.3K Mar 29 11:07 python-config
-rwxrwxr-x. 1 plone plone 245 Mar 29 11:07 wheel

OK so running ./bin/buildout -No -c build_file.cfg get version conflicts

Installing client1.
While:
Installing client1.
Error: There is a version conflict.
We already have: Products.CMFPlone 4.3.3
but Products.PloneFormGen 1.8.5 requires 'Products.CMFPlone>=5.0b2.dev0'.

Found this for version conflicts: https://docs.plone.org/manage/troubleshooting/buildout.html
However, not really an option on production... Plus do not know current state of site should buildout be on the production site.

So tried to pin the version of Products.PloneFormGen referring from here:

However, that too fails including inserting several different versions with not found.
version - 1.7.20
tried 1.7.21, 22, etc.

Hi,
hav you tried to run a clean buildout - without addons?

Maybe this is for you:
https://zope.maurits.vanrees.org/weblog/archive/2008/01/easily-creating-repeatable-buildouts

Search for "Bad constraints":

grep -Ri --include="requires.txt" "CMFPlone" eggs/*

Sorry to ask for details at this state, but reading again the whole thread I am not clear about what you are trying to do exactly :slight_smile:
At the beginning there is a mention of rsyncing a Plone installation between a Solaris and a Centos computer and I was readying myself to say that it was probably a bad idea (tm), but @jensens seemed to think it could be done and he is certainly more experienced than me so I kept quiet.
Since he seems to be busy elsewhere, I have to say that if you are not trying do that already (it's not clear to me), the way to go IMO is to build a new fresh Plone installation and add step by step everything non standard (add-on, configuration, files in the src directory) testing at each step that your site starts and it looks hopefully more and more like the existing one. Then when everything is tested and works the same as the old site, with the exact same pinnings as observed under the buildout directory, do a backup of the old site and restore it. Should work unless your developer has hidden Easter eggs somewhere in the buildout directory.
I for one would not attempt to copy a Plone installation and hack at it in hope it will work, unless the 2 computers are exactly at the same OS version and same architecture.

Hello,
Thank you all for the input and help.

I entered the picture late into the game with a migration from Solaris 10 to CentOS7 as the goal but developer gone form company and no ability to contact.

That said, shall read @mgrf recommendations and then attempt gp54321 steps. To answer questions: they had rsynced entire directory in attempts when I entered picture. I since did a unified installer and then rsynced Data.fs, blobstorage, src and *.cfg. It does build using base buildout.cfg but not custom build. Appears to have altered some packages. Shall do those steps but will be traveling today and out most of week so shall go somewhat slow to respond.

The good news is that they may have Plone backup jobs so I think we're not at a loss for getting it to new OS.

Thanks for the help and have a great day!

@gp54321

Thank you for the suggestion. Basically did an install or 4.3.3 on Linux. Started the instance and confirmed access to the ZMI with a Gui add plone site testsite which all worked.

The original buildout.cfg has both two additional parts:
precompiler
setpermissions

I added those to the new buildout.cfg. Ran ./bin/buildout and get the following version alerts.
The following part definition lists the versions picked:
[versions]
plone.recipe.command = 1.1
plone.recipe.precompiler = 0.6

I had found a reference I think in Plone documentation on how to determine versions of all the various parts. However, it seem to require running some scripts form Github on the production site which I'm hesitant to do. Do not know the last known state of the production site for such a risk. Additionally, the Plone Gui products didn't reference precompiler or setpermissions. It did see Product.PloneFormGen 1.7.15 which does not match the reference previously.

Do I need to worry about the versions picked here and how can I check that they're the same on both Solaris system as the Linux system?

did the original build have a part called 'client_reserved' by any chance ?

yes that's normal, the gui is supposed to list all the eggs versions, what you see is only a small part of them, that is, the add-ons you are supposed to enable explicitly.

If you have rsynced the original directory, I think that just

ls -1 | cut -d - -f 1-2 --output-delimiter=";"

in the eggs directory should get you something you can import in any good spreadsheet software and compare it with your new buildout eggs directory.

and the message about versions automatically picked can be trivial or bad, depends. I think it means buildout picked the last available version, usually a good choice but not always when incompatibilities have creeped in recent software and you use an old software (that's very much your case with Plone 4)

Hello,
Thank you.
Ref. 'client_reserved' -- Not that I'm aware or able to locate but not sure if this is in parts or part of the .cfg you're referencing. Do not see any directory or file called client_reserved.

Some of the confusion is knowing where eggs are located, etc. as he has .egg-links in one directory back to source and appears to have a sym link for the zeoserver build.

Everything seems to build with the errors noted above. After copying over some src and *.egg-link files I also brought us the custom.cfg. Ran ./bin/buildout -No -c custom_build.cfg.

Get Error:
Installing client1.
Couldn't find index page for 'Products.PloneFormGen' (maybe misspelled?)
While:
Installing client1.
Getting distribution for 'Products.PloneFormGen'.
Error: We don't have a distribution for Products.PloneFormGen
and can't install one in offline (no-install) mode.

no matter, could have been fun if it has been true.

I did not know this switch -o, and the --help for buildout is not that helpful.

Reading the buildout code:

"Nothing is installed, even from cache, in offline\n"
"mode, which might better be called 'no-install mode'

in this case adding an ref to a product in the buildout config file and running with -o should not really succeed :slight_smile: