Amos, I spent a good bit of this morning playing with ZServer on my RedHat 5.2 machine. The good news is it's working and it's fast, but there are some trickies that should be noted. I edited the start.py file to use the python that came with RH. That didn't work because the default Python for RH stupidly doesn't have threads enabled. So... I edited the start.py again to use the Python that comes with the linux binary distribution of Zope, and that bombs because we don't ship the FCNTL module with our Python, which medusa uses (in medusa/asyncore.py). So... I d/led, compiled and installed my own Python (1.5.1 and overwriting the RH one). For those of you out there who want to do this but aren't down on compiling things, I used this sequence: ./configure --prefix=/usr --with-threads make make install (<- probably have to be root) ...and then re-edited the start.py file to go back to the (new) system python. Everything started up fine, but when I tried to hit the HTTP server I got an 'unhandled exception in thread' error, cPickle choked on reading the Zope database file. Brian said this is because I installed ZServer *over* an existing Zope, and that the python that comes with Zope uses a different cPickle format. The solution is either to recompile my new Python (again) with the different cPickle format enabled, or to delete my database files and let Zope make new ones, using the new format. I chose the latter. Moving 'var/Data.bbb*' into an old directory, firing up ZServer/start, and it worked! Now I'm going to play with FTP. :) Michel
At 12:38 PM 1/26/99 -0500, Michel Pelletier wrote:
I spent a good bit of this morning playing with ZServer on my RedHat 5.2 machine. The good news is it's working and it's fast, but there are some trickies that should be noted.
Well that's what alpha testing if for ;-)
I edited the start.py file to use the python that came with RH. That didn't work because the default Python for RH stupidly doesn't have threads enabled.
Yes, this is annoying.
So... I edited the start.py again to use the Python that comes with the linux binary distribution of Zope, and that bombs because we don't ship the FCNTL module with our Python, which medusa uses (in medusa/asyncore.py).
Actually I don't think that this is true. There should be a FCNTL.py in 'lib/python1.5/plat-linux2'. You may not be seeing it because either your PYTHONHOME and/or your Python path may not be set correctly. See the 'start' shell script that comes with Zope for an example of how to set the PYTHONHOME before firing up Python. We should probably include a similar shell script with ZServer.
..and then re-edited the start.py file to go back to the (new) system python. Everything started up fine, but when I tried to hit the HTTP server I got an 'unhandled exception in thread' error, cPickle choked on reading the Zope database file. Brian said this is because I installed ZServer *over* an existing Zope, and that the python that comes with Zope uses a different cPickle format. The solution is either to recompile my new Python (again) with the different cPickle format enabled, or to delete my database files and let Zope make new ones, using the new format. I chose the latter. Moving 'var/Data.bbb*' into an old directory, firing up ZServer/start, and it worked!
Yes, this is an another annoying problem that has bitten me once before. It should probably be in the FAQ. As I recall the problem is this (please correct me if I'm wrong): cPickle can be compiled to use binary pickles. The standard Python cPickle is not configured to use them. The cPickle that ships with Zope is. Unfortunately cPickle won't even *read* binary pickles unless it is compiled with the binary pickle option. Thus if you create a bobobase using the Python that ships with Zope and then switch to using another copy of Python with the same bobobase, there is a good chance that the cPickle in the new Python installation will refuse to read the binary pickles in the old bobobase. I believe that newer versions of cPickle should be able to read binary pickles even if they won't write them, which will solve the problem. In the mean time, you should probably stick with the same copy of Python. If you need to switch from Zope's Python to another Python, you may need to recompile cPickle. There may be other solutions to this problem. For example, there may be a way to convert a bobobase from binary to non-binary pickles, though I've never done this... Thanks for kicking the tires on ZServer! -Amos
On Tue, Jan 26, 1999 at 12:38:20PM -0500, Michel Pelletier wrote:
The solution is either to recompile my new Python (again) with the different cPickle format enabled, or to delete my database files and let Zope make new ones, using the new format. I chose the latter. Moving 'var/Data.bbb*' into an old directory, firing up ZServer/start, and it worked!
Is that all there is to it? I did everything you detailed (since I'm running a fairly vanilla redhat 5.2 install), and then mv'd Data.bbb* to another directory. Now I can't seem to load ANY pages (404's all around). Hmmm... dave
At 10:37 AM 1/26/99 -0800, David Brown wrote:
On Tue, Jan 26, 1999 at 12:38:20PM -0500, Michel Pelletier wrote:
The solution is either to recompile my new Python (again) with the different cPickle format enabled, or to delete my database files and let Zope make new ones, using the new format. I chose the latter. Moving 'var/Data.bbb*' into an old directory, firing up ZServer/start, and it worked!
Is that all there is to it? I did everything you detailed (since I'm running a fairly vanilla redhat 5.2 install), and then mv'd Data.bbb* to another directory. Now I can't seem to load ANY pages (404's all around).
Wait a minute. Michel was describing how to switch from Zope's Python to Redhat's Python. Part of his solution was to abandon his old object database. 'Data.bbb' is the object database file. Moving it out of the var directory means Zope can't see it, and will create a new empty object database. If you remove your object database, you remove all your Zope objects. Hence the 404's you are seeing. If you, like Michel, are trying to run ZServer, but are having trouble with start.py and Zope's Python, I would suggest wrapping start.py in a shell script that sets the PYTHONHOME to your Zope directory, and then runs ZServer/start.py. #! /bin/sh PYTHONHOME=/home/amos/Zope export PYTHONHOME cd /home/amos/Zope bin/python ZServer/start.py (This is untested, but it should give you the idea.) Or are you after something else? -Amos
On Tue, Jan 26, 1999 at 11:06:02AM -0800, Amos Latteier wrote:
Wait a minute. Michel was describing how to switch from Zope's Python to Redhat's Python. Part of his solution was to abandon his old object database. 'Data.bbb' is the object database file. Moving it out of the var directory means Zope can't see it, and will create a new empty object database.
That's what I wanted to do. I want to use my installed Python. And, to avoid the binary pickle problem, I moved my Data.bbb*'s somewhere where Zope cannot see them, just as you said. And now, when I run ZServer, everything starts up fine. When I ftp to ZServer, I can see all the normal files (standard_html_header, standard_html_footer, yadayada), with the exception of index_html. But even when I put an index_html in there with FTP, it still doesn't want to serve it.
If you remove your object database, you remove all your Zope objects. Hence the 404's you are seeing.
I understand. I was just hoping that ZServer would rebuild the database with more useful defaults (like an index_html that says something like "the reason there is nothing here is because I had to rebuild the database").
If you, like Michel, are trying to run ZServer, but are having trouble with start.py and Zope's Python, I would suggest wrapping start.py in a shell script that sets the PYTHONHOME to your Zope directory, and then runs ZServer/start.py.
#! /bin/sh PYTHONHOME=/home/amos/Zope export PYTHONHOME cd /home/amos/Zope bin/python ZServer/start.py
(This is untested, but it should give you the idea.)
I'll give this a try.
Or are you after something else?
I'm always after something else. dave
At 11:11 AM 1/26/99 -0800, David Brown wrote:
On Tue, Jan 26, 1999 at 11:06:02AM -0800, Amos Latteier wrote:
Wait a minute. Michel was describing how to switch from Zope's Python to Redhat's Python. Part of his solution was to abandon his old object database. 'Data.bbb' is the object database file. Moving it out of the var directory means Zope can't see it, and will create a new empty object database.
That's what I wanted to do. I want to use my installed Python.
And, to avoid the binary pickle problem, I moved my Data.bbb*'s somewhere where Zope cannot see them, just as you said.
And now, when I run ZServer, everything starts up fine.
When I ftp to ZServer, I can see all the normal files (standard_html_header, standard_html_footer, yadayada), with the exception of index_html.
Hmmm, all files should show up, even if you don't have permissions to change them. Perhaps we should take this discussion off the Zope list, so I can better analyze what's going on without boring everyone.
But even when I put an index_html in there with FTP, it still doesn't want to serve it.
What URL are you using to access Zope through the web? The alpha version of zope_handler set's your URL prefix to '/Main', so you would need to go to: localhost:9673/Main/manage To manage Zope through the web. Note: this default URL prefix may change in the future. My guess is that you are not seeing things though HTTP because you are going to the wrong URL. Another good thing to do when you are not seeing things you want to see is to set BOBO_DEBUG_MODE=1 and check the source of the not found page. (OK, I admit, ZServer doesn't yet let you set arbitrary environment variables ;-) Don't forget that you can access Zope via FTP and HTTP at the same time. It's particularly helpful to have the management screen open while you are FTPing. Then you can do stuff like check out your changes to Documents. It's particularly fun to make permission changes in the management screen and see the file permissions change in FTP! easily-amused-ly yrs, -Amos
On Tue, Jan 26, 1999 at 11:06:02AM -0800, Amos Latteier wrote:
#! /bin/sh PYTHONHOME=/home/amos/Zope export PYTHONHOME cd /home/amos/Zope bin/python ZServer/start.py
(This is untested, but it should give you the idea.)
Well, this worked as well, meaning it started up the ZServer successfully, but I can't read the original Data.bbb*, and it looks to be for the same reason that Michael couldn't. So -- the question becomes either: How do I cause Zope to create a reasonable default database, or How do I get my local Python installation to use binary pickling? Yeah, I know I could just use the Python in the binary distribution of Zope, but I really want to use the Python I've already got on my machine, mainly because I want to figure out what makes your Python different from mine. Hack hack hack. dave p.s. Thanks for all the help. I really appreciate it.
On Tue, 26 Jan 1999, Michel Pelletier wrote:
So... I d/led, compiled and installed my own Python (1.5.1 and overwriting the RH one). For those of you out there who want to do this but aren't down on compiling things, I used this sequence: You can also download the .src.rpm, to keep the rpm database clean. rpm -i python-1.5.1-*.src.rpm
Afterwards, you get probably in /usr/src/redhat/SPECS (If you've changed the location, than you do not need somebody to tell you how to patch a spec file.) a python*.spec file. In this file, search for the configure line, and add --with-threads. Then do a rpm -ba /usr/src/redhat/SPECS/python*.spec Afterwards, you'll find the new threaded rpms in /usr/src/redhat/RPMS/<arch>, and can install them with rpm -U --force (as the do have the same release number as the RH orginals). Andreas
./configure --prefix=/usr --with-threads make make install (<- probably have to be root)
Andreas -- Win95: n., A huge annoying boot virus that causes random spontaneous system crashes, usually just before saving a massive project. Easily cured by UNIX. See also MS-DOS, IBM-DOS, DR-DOS, Win 3.x, Win98.
participants (4)
-
Amos Latteier -
Andreas Kostyrka -
David Brown -
Michel Pelletier