- Zope - Zope lists

RE: [Zope] - Rewrite rules somewhere besides httpd.conf?
by Jeff Bauer 08 Dec '98

08 Dec '98

> Can the Apache rewrite rules be put in a file other > than httpd.conf? For example, could they be put in > a file local to the Zope directories such as a .htaccess > file? It can, but it's more difficult to set up properly than including rewrite rules in httpd.conf, which is no cakewalk. Are you using .htaccess because you don't have access to httpd.conf or for some other reason? Here are some things to consider: - Verify RewriteBase is set correctly for the location you're using. - Try using RewriteLog with loglevel 9 and see what it says. Note that if your webmaster has disabled this, you're out of luck. - Remember to check the apache access and error logs. Lest anyone confuse me for someone who knows what they're doing, I've note used .htaccess with Zope/Apache yet. I hate to weasel out of a legitimate question, but this really is an Apache issue. If you have problems getting .htaccess to work, you may find further answers available from the comp.infosystems.www.servers.unix newsgroup. Good luck, Jeff Bauer Rubicon, Inc.

1 0

RE: [Zope] - newbie PCGI problems (fwd)
by Peter J Ulintz 08 Dec '98

08 Dec '98

On Mon, 7 Dec 1998, Jeff Bauer wrote: > > > NEWBIE QUESTION I: > > Exactly where do you put the mod_rewrite config info? I > > tried putting it in the normal three .conf files and got > > errors. I DID compile the server with the mod_rewrite > > included. > > The Rewrite directives for Apache normally go in > httpd.conf. Actually the Rewrite directives should only > affect authorization, so if you are denied access *after* > the user name and password dialog appears, everything > else with PCGI is probably working. Cool. I added em, but it didn't seem to help much. > > Ah, this points out a potential problem. If you start using > Zope with ZopeHTTPServer under your account, then it's possible > that the database is no longer accessible through your web > server. This is something we should document better, because > it represents a natural progression of tasks. > Yea, I probably shoulda mentioned that... I did run the wo_pcgi.py script first with the ZopeHTTPServer, and it installed flawlessly, and I played around in there a bit... > > File > > "/export/home/pulintz/Zope-1.9b1-src/lib/python/ > > Products/sample/Product.py", > > line 24, in ? > > import OFS.SimpleItem, Persistence, Acquisition, AccessControl.Role > > ImportError: (<class exceptions.ImportError at ab540>, > > 'No module named Persistence') > > > Went into the Product.py file and changed "Persistence" to > > "BoboPOS.Persistence", and tried to bring up zope in the > > browser again. I got the authentication window! But I > > couldn't authenticate, getting the error message concerning > > the authentication headers. > > Changing the code in Product.py is a no-no at this stage > unless you're doing something benign (e.g. log file or > MrCreosote) because you're simply hiding a problem that > will be more difficult to track later. See below. > Okay, changed that back... actually, to be totally safe, I scrubbed everything and reinstalled Zope, making the appropriate permissions changes, and adding the PYTHONPATH to the pcgi info file... I also rechecked the apache configuration files to make sure the mod_rewrite was included in the build, and to make sure that I could follow symbolic links,etc. Tried to fire up Zope and got the "Serious Application Error" screen. Checked the pcgi.log, and had the same permission trouble with the Data.bbb file, so I reset these permissions to be globally writable and tried again-- got the authentication screen. Still can't authenticate. Gives the "You are not authorized to access this resource. No Authorization header found" error. Reading your "Sacrificial Virgin" email: so on Solaris is it necessary to have the UNION_SEMUN macro in pcgi.h? (I'll try and avoid editing the Publish.unauthorized() method) Anything else need to be done, or should I just wait for the next release? > > > > PCGI info file: /export/home/pulintz/Zope-1.9b1-src/Zope.cgi > > PCGI wrapper: /export/home/pulintz/Zope-1.9b1-src/pcgi/pcgi-wrapper > > error attempting: 'from cgi_module_publisher import publish_module' > > status: FAILURE > > This provides us an important clue, although it's slightly > misreported and you actually had it available in your earlier > traceback. (Zope was released before pcgifile.py could be > updated; to be remedied shortly.) > > The pcgi_publisher.py module is actually trying to import > publish_module from ZPublisher. > Yea-- Can't seem to get around this... <cringe> Potential stupid question: Shouldn't there be a ZPublisher module somewhere? </cringe> Anyway, trying your advice below... > Since your problem (authentication aside) is essentially > one of not being able to import the correct module, for > the time being let's put PYTHONPATH in your Zope.cgi > info file: > > PYTHONPATH=/usr/local/bin/python:. > > If the solution still isn't obvious, you can try > to expedite things by creating a test cgi file, > TestZope.cgi: > > #!/usr/local/bin/python > > print "Content-type: text/html" > print > print "Looks OK" > > Get TestZope.cgi working and then add some import statements, > placed just before print "Looks OK", e.g.: > > from ZPublisher import publish_module > > As it breaks, you can add to your import path by iteratively > doing the following, placing the sys.path.append just ahead > of importing publish_module. > > import sys > sys.path.append('/export/home/...') > > The step above shouldn't be necessary, but it helps to > define a small test case so that you can narrow down the > real problem. And it's better than sitting there staring > at your screen <wink>. > The simple script with just "Looks okay" works fine of coarse, but I can't seem to find a path to ZPublisher anywhere, no matter how many locations I add to sys.path. Trying to test pcgi more, I did the Example /pcgitest/getTime and I got the "Temporarily Unavailable" screen, with no additional error message. (And I did make sure the directives were set correctly) NOW, the ../cgi-bin/pcgifile.py?filename=.../Zope.cgi thing gives me PCGI info file: /export/home/pulintz/Zope-1.9b1-src/Zope.cgi PCGI wrapper: /export/home/pulintz/Zope-1.9b1-src/pcgi/pcgi-wrapper PCGI_SOCKET_FILE write permission error: /export/home/pulintz/Zope-1.9b1-src/var/pcgi.soc status: FAILURE but I've checked the permissions on everything, and /var is globally writable. I'll keep at it... I installed Bobo, and that works, which makes me feel a bit better. Maybe I'll content myself to play around with that until the dust settles a bit. Thanks for the help so far! -P

3 2

- Q: Any experience with PIL and charting?
by Paul Everitt 08 Dec '98

08 Dec '98

Does anybody have any experience with PIL and drawing charts, such as pie charts? --Paul Paul Everitt Digital Creations paul(a)digicool.com 540.371.6909

2 1

Re: [Zope] - database transfer
by Jim Fulton 08 Dec '98

08 Dec '98

"Christopher G. Petrilli" wrote: > > On Mon, Dec 07, 1998 at 09:43:26AM -0800, David Ascher wrote: > > > > [ The idea of exporting databases, etc ] > > > > Right -- the other reason is that I do my editing on a server to which I > > have very good connectivity, but which isn't available to the world. > > It's my own staging area. The manage_export hack (or a non-hack > > replacement) should do the job in the future. Thanks > > > > I'm going to prove I really have no life to Paul, but... I was just > thinking of this same problem last night in the shower... > > Let's work with this: > > zope_a - Internal development/testbed > zope_b - Production/consumer side > > What I'm imagining is that on zope_a you create an object > (RemotePublisherDestination) that represents zope_b, and on zope_b you > create a object (RemotaePublisherSource) that represents zope_a. Each > of these would have a shared secret associated with them for > authentication (this could be extended to more trusted forms later). > > Now, Jane works on her website ideas on zope_a, trying ideas, blowing it > up, using Versioning to try things, commit and revoke them, and when > she's done with the whole package, she tags the tree to publish, clicks > a button, and automagically, the whole thing is encapsulated in a > package (marshalled, etc) that is then shipped over to > RemoatePublisherDestination via a secure channel. > > Once the package is there, the zope_b site would examine it, and then > commit it into the POS as a version. This allows to examination to make > sure that all the Acquisition tricks are working correctly, and not > broken, and can be commited as a whole thing. > > Why is this useful? Overtime, I'd like to be able to run a Zope server > at my house that I work on things with, and then move that up to the T1 > attached one when I'm done. It's just too slow otherwise. Also, it > would be helpful in the case of ISPs, etc., who could let their > customers break things on their own sites before working interactively > with teh real thing---performance and all. I agree that this could be useful and is probably doable, but I suspect that the details could mount pretty quickly. It would be alot easier if the objects modified on the development site were *never* modified on the production site. > What's wrong? > - Acquisition problems could get weird Maybe, but not so bad if the two sites are sufficiently in sync. > - Security is a BIG concern Yes, this has to be done carefully. > - Does this defeat the point of versioning (*) I don't think so. > - Lots of other things I'm sure others will point out > > * - I see versioning as a way to play with ideas in a framework that can > be undone trivially, show them to others,etc, without breaking the > starting point. What do you mean by "versioning"? Do you mean undo? Undo is primarily there to make it easy to recover from mistakes. Sessions (soon to be renamed "versions", aka long-running-transactions) provide an even better way to do this. > It's not quite a VC system, which is a totally > different question, no? Right. It's *not* a VC system, although there are some similarities. > One of the neat things that Illustra had (a > OO-Relational database) is the concept of time-travel. You could see > the database through a time-point. BoboPOS/SimpleDB was designed to support this sort of thing, although we've never really used it. There are API's there, although there since they haven't been used, I don't know if they still work. I could imagine having Zope 2 feature that allowed you to have a read-only view of some past version of a web site. Jim -- Jim Fulton mailto:jim@digicool.com Technical Director (540) 371-6909 Python Powered! Digital Creations http://www.digicool.com http://www.python.org Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email address may not be added to any commercial mail list with out my permission. Violation of my privacy with advertising or SPAM will result in a suit for a MINIMUM of $500 damages/incident, $1500 for repeats.

2 2

RE: [Zope] - zope jitterbug
by Alan Wostenberg 08 Dec '98

08 Dec '98

Thanks, all, Paul, for http://www.digicool.com/site/Collector/ . This site solicits a password - how do I obtain one? Also, is this bug collector under OpenSource? Finally, turns out we have a calltracck system (Scopus) with a poor user interface. It's hosted in Sybase. I note Zope has various SQL interfaces. Do you think it's an adequate tool to put a nice web front end on a legacy tracking system via SQL? -Alan Wostenberg, Baan Front Office, Colorado

1 0

Re: [Zope] - Call me stupid, but... trouble with adding images
by Jim Fulton 08 Dec '98

08 Dec '98

"Christopher G. Petrilli" wrote: > > For those curious, I never could figure out the problem, but it seems > tto be related to my installation of Python not Zope. I had all of the > previous Boboish things installed, and a kinda out-of-date 1.5.2 beta, > and when I updated that and killed all the old stuff, it now seems to > work fine. Python 1.5.2a1 and 1.5.2a2 had a bug in the cgi module that broke file-upload when used with a non-cgi publisher. The fix was later provided to PSA-members and checked in. By updating your 1.5.2, you got the fix. So, in summary, Zope does *not* work with 1.5.2a1 or 1.5.2a2 but may work in 1.5.2 as it exists in the current python.org CVS tree. Whew. Jim -- Jim Fulton mailto:jim@digicool.com Technical Director (540) 371-6909 Python Powered! Digital Creations http://www.digicool.com http://www.python.org Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email address may not be added to any commercial mail list with out my permission. Violation of my privacy with advertising or SPAM will result in a suit for a MINIMUM of $500 damages/incident, $1500 for repeats.

1 0

Re: [Zope] - database transfer
by Jim Fulton 08 Dec '98

08 Dec '98

"Christopher G. Petrilli" wrote: > > On Mon, Dec 07, 1998 at 11:46:31AM -0800, David Ascher wrote: > > On Mon, 7 Dec 1998, Christopher G. Petrilli wrote: > > > > > I'm going to prove I really have no life to Paul, but... I was just > > > thinking of this same problem last night in the shower... > > > > > > Let's work with this: > > > > > > zope_a - Internal development/testbed > > > zope_b - Production/consumer side > > > [...] > > > > Etc. Yes, this is exactly what I want. As long as it's free your check > > is in the mail as soon as it's ready. =) > > I wait with baited breath... and here you didn't know I was into Bass > fishing :-) > > Seriously, I wanna think a bit more about this, because it fits into > some ideas that Jim/Paul/Amos have promulgated vis a vis Zope2, and how > it will be able to be distributed... so we really need to think about > how 2 Zope systems will communicate in general (Fnorb?) rather than this > one speicific instance. I think that this is a different beast. We have plans for essentially "client-server" support for the Z Object Datrabase, initially by hosting the object database in an RDBMS. This would not really solve the problem that started this thread. David wanted to be able to do development on a machine that has a very slow (or, reading between the lines, intermittent) connection to the production server. In a client-server model, the development server would be hampered by a slow connection to the database server. Jim -- Jim Fulton mailto:jim@digicool.com Technical Director (540) 371-6909 Python Powered! Digital Creations http://www.digicool.com http://www.python.org Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email address may not be added to any commercial mail list with out my permission. Violation of my privacy with advertising or SPAM will result in a suit for a MINIMUM of $500 damages/incident, $1500 for repeats.

2 1

Re: [Zope] - BoboPOS locking
by Jim Fulton 08 Dec '98

08 Dec '98

Grisha Trubetskoy wrote: > > Pardon me if this is a naive question - I'm just trying to learn all > this. > > I understand Zope stores everything in a BoboPOS database. > > What happens when more than one process attempts to open and modify the > same database? On Unix, the second process dies with an IOError because it can't get a file lock. > Is there any locking mechanism? On Unix, Unix file locking is used. Does anyone have any routines for locking windows files? Jim -- Jim Fulton mailto:jim@digicool.com Technical Director (540) 371-6909 Python Powered! Digital Creations http://www.digicool.com http://www.python.org Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email address may not be added to any commercial mail list with out my permission. Violation of my privacy with advertising or SPAM will result in a suit for a MINIMUM of $500 damages/incident, $1500 for repeats.

1 0

Re: [Zope] - A TINY observation
by Jim Fulton 08 Dec '98

08 Dec '98

"Christopher G. Petrilli" wrote: > > On the "Control Panel" page, above the shutdown button it says this: > > Click "Shutdown" to shutdown the Principia process. It will be > restarted on the next web request. > > This is somewhat misleading for those using ZopeHTTPServer, because it > dies too... so if you're remotely maintaining it, you might want to be > aware of that. Perhaps the ZopeHTTPServer should include a message to this effect in the response to the shutdown. Jim -- Jim Fulton mailto:jim@digicool.com Technical Director (540) 371-6909 Python Powered! Digital Creations http://www.digicool.com http://www.python.org Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email address may not be added to any commercial mail list with out my permission. Violation of my privacy with advertising or SPAM will result in a suit for a MINIMUM of $500 damages/incident, $1500 for repeats.

1 0

Re: [Zope] - Win32 package install
by Mark Millikan 08 Dec '98

08 Dec '98

Subsequently, I followed the instructions for building the pyds using visual c++ and that worked flawlessly (I used vc6). The server launches and the manage screens are findable from the IE4 browser. Everything seems copacetic. zope is dope? Mark M At 05:48 PM 12/8/98 +0000, Jim Fulton wrote: >Mark Millikan wrote: >> >> Tried to install/run Zope 1.9b1: >> >> Following the instructions in 'win32_zope_19b1_tar.gz' works, except: >> >> The win32 binaries download contained a 'zlib.pyd' library and did not >> contain a 'cPickleCache.pyd' library. >> >> Using the the following version of python: >> >> Python 1.5.1 (#0, Apr 13 1998, 20:22:04) [MSC 32 bit (Intel)] on win32 >> Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >> >> Executing 'python serve.py' brings up an error message 'The procedure entry >> point PySequence_Contains could not be located in the dynamic link library >> python15.dll' - does this indicate a need for 1.5.2? >> >> Mark Millikan > >Note that we plan to make a fully self-contained wise-automated >win32 binary release on Friday. > >Jim > >-- >Jim Fulton mailto:jim@digicool.com >Technical Director (540) 371-6909 Python Powered! >Digital Creations http://www.digicool.com http://www.python.org > >Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email >address may not be added to any commercial mail list with out my >permission. Violation of my privacy with advertising or SPAM will >result in a suit for a MINIMUM of $500 damages/incident, $1500 for >repeats. > >

1 0