[Zope-dev] Security problems importing from python package.
At Thu, 21 Nov 2002 12:16:09 +, Chris Withers wrote:
I'm trying to get stripogram working from Script(Pythons). I thought I had it,
but it appears I don't.
I added the following in the __init__.py of the stripogram package:
try:
from AccessControl import ModuleSecurityInfo,allow_module
except ImportError:
# no Zope around
raise
else:
allow_module('stripogram')
ModuleSecurityInfo('stripogram').declareObjectPublic()
ModuleSecurityInfo('stripogram').declarePublic('html2text', 'html2safehtml')
This issue is most probably resolved somewhere in between, but I can
not find any trace of this at [EMAIL PROTECTED] nor [EMAIL PROTECTED], thus I
drop in my 2 cents here.
I did just now run into a similar problem, and may offer the following
explanation after some debugging:
It seems the 'allow_module', etc, gets not executed by Zope in advance,
except if this is the __init__.py of a 'Product', or this module is
imported by some core module or product. This is quite standard python
behaviour; the module is not initialized before import, and Zope does
some extra work to initialize all products on startup.
If one tries to import the code from a python script, the security
machinery first check, if the module has some security info, and imports
it afterwards, if the info is found. But as the module is not imported
anyway, it is not initialized, and has not such info and thus will not
be allowed for import.
It seems there is some chicken and egg problem here, or I have missed
something completely.
The workaround is to insert a dummy 'import stripogram' in some
product, which triggers the security info creation -- or make the little
helper scripts a product of its own.
I don't think either the allow_module or the declareObjectPublic() should be
necessary. However, the declareObjectPublic at least made this test pass:
from Products.PythonScripts.PythonScript import PythonScript
theScript = PythonScript('test')
theScript.ZBindings_edit({})
theScript.write(from stripogram import html2text\nreturn
html2text('ihello/i'))
theScript._makeFunction()
self.assertEqual(theScript(),'hello')
This works, as Your test code imports something via file system (no
access restriction) from module stripogram first and then creates the
test script, which finds the module info on import as the module is
intialized yet.
But even adding the 'allow_module' won't let the following Script (Python)
created through the ZMI work:
from stripogram import html2text
The error I get is:
Error Type: ImportError
Error Value: import of stripogram is unauthorized
In this case the module has not been initialized yet, and the TTW
access is the first import, which failes due to the security
restrictions problem mentioned above.
Hope this helps; and hope someone can point me out I am wrong on the
chicken and egg problem of 'non-Product' module import.
Cheers,
Clemens
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] consistent naming in ZEO releases
On Mon, 25 Nov 2002 13:56:34 + Chris Withers [EMAIL PROTECTED] wrote: Andrew Sydelko wrote: Ok, whoever is in charge of zope.com releases of things like DCOracle2, Zope and ZEO need to decide if the release file names are going to end in .tar.gz or .tgz. Why does it matter? I have a script that builds zope. And part of that script is going to get the tarballs. When they change the name I have to go and change the URL (normally I just set the version number). Here's an example: version['ZEO']='1.0' [snipped lots of other installs] package = 'ZEO' if version.has_key(package): ver = version[package] install(package=package, dir='src', url='http://www.zope.org/Products/ZEO/ZEO-%s.tgz' % (ver), checkfile='src/ZEO-%s' % (ver)) install is a function that uses the parameters in it to decide what to do. You'll see that when I switched to ZEO 2.0 I had to change the URL. And I shouldn't have to go look up the URL every time to make sure it's the same... That's the whole point of my script. --andy. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] consistent naming in ZEO releases
how about you change your code so it attempts to download both .tgz and .tar.gz? jens On Monday, Nov 25, 2002, at 09:03 US/Eastern, Andrew Sydelko wrote: On Mon, 25 Nov 2002 13:56:34 + Chris Withers [EMAIL PROTECTED] wrote: Andrew Sydelko wrote: Ok, whoever is in charge of zope.com releases of things like DCOracle2, Zope and ZEO need to decide if the release file names are going to end in .tar.gz or .tgz. Why does it matter? I have a script that builds zope. And part of that script is going to get the tarballs. When they change the name I have to go and change the URL (normally I just set the version number). Here's an example: version['ZEO']='1.0' [snipped lots of other installs] package = 'ZEO' if version.has_key(package): ver = version[package] install(package=package, dir='src', url='http://www.zope.org/Products/ZEO/ZEO-%s.tgz' % (ver), checkfile='src/ZEO-%s' % (ver)) install is a function that uses the parameters in it to decide what to do. You'll see that when I switched to ZEO 2.0 I had to change the URL. And I shouldn't have to go look up the URL every time to make sure it's the same... That's the whole point of my script. --andy. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope ) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] Writing the second Zope Community Handbook
Hello everyone, first of all, sorry for the cross-post, but I need to reach about everyone possibile in the Zope Community. While talking with Maik Roeder this weekend, we noticed that there might be a huge urge to write another community-authored Zope Handbook. So I called Nadja Rosmann, chief editor of Linux Enterprise magazine, today and talked to her. She was very excited about it and showed great interest. The first book we (the Zope community) wrote with them was a great success and started at Linux Enterprise an entire series of pocket books. The first book, which is also known as the Yellow Book, was a set of articles by various community members about Zope. The book was published in German and an English version was available online. The book covered a wide variety of subjects and offered a great alternative for people that were not willing to spend the money for a complete book, since the price was only 12.50 Euros. The book was therefore perfect for giving it to clients and other interested people without making a big investment. So, we plan to write a book like that again! This time however, we will publish the book on paper in at least German and English. I also talked to Nadja about a French version, since France seems to have some really cool Zope development going on. I truely believe that this book will help Paul's goal of having Zope grow 10x. BTW, since we will have many authors, I propose to donate the payments to a common Zope-oriented project, such as the creation of a Zope-booth or something else (the last donations went to the EuroZope e.V. for organizing conferences). Of course every author will receive a free copy in a preferred language. The next thing I need to discuss would be the topic of the book. Nadja and I agreed that it might be a better marketing argument, if we try to concentrate on Zope's Content Management capabilities. This way, many companies should be interested in writing about their products and case studies. What do you think? Now to the organization of the project. We need about 20-24 articles most having a length around 12k-20k characters (4-6 A4 pages) and some central articles having 20k-30k characters (about 10 A4 pages). This would produce a book with around 300 pages, which would be sold for 20.00 Euros. Since this is a community effort, people need to volunteer writing articles/chapters. Therefore, please E-mail me privately (so we do not cause huge cross-post threads), if you would like to write an article and what you would like to write the article about. Once I have enough responses, I will publish the list. Here are some points that might help thinking about a subject: - Do you or your company have developed your own Content Management System in Zope? Then tell us about it. Examples: CMF, Plone, Silva, Kontentor ... - Do you or your company have a client that you want the world to tell about? Why are you not writing a Case Study? Examples: Universities, Government agancies, other companies... - Do you have a product you developed (or extensively used) for Zope that you think should receive more attention or could be useful to many people? Right, write about it! Examples: Wikis, RDB Adapters, ZEO, I18n tools, Discussion Boards... - Do you know a particular thing about Zope that you particularly liked about Zope and that caused you using it? Please, tell us about it. Examples: RDB/LDAP Integration, User management, speed of development (RAD) ... - Are you developing some cool stuff for the Zope core? Write about it... - There is also some interest in having a couple reports on the progress of Zope 3, so if you are a Zope 3 developer, you might write an article comparing the differences between the Zope 2 and Zope 3 way of doing things. Examples: RDB Integration, Caching, I18n, Components versus Multi-talented objects... - If you do not know a topic, but still would like to write an article, contact me anyway and we will find a subject together. Also, we do not need only writers, but also translators. So, if people do not feel comfortable writing an entire article, they could also volunteer as translator. Now to the time frame. I think that it will be best to write the articles during Christmas, since it is a slow time and people have some more time on their hands. My ambitious goal is to send the complete set of scripts to Nadja by January 25th (Why that day? Because it is her and my birthday. ;-). This project cannot happen without the community! Please help us making this project a success! Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists -
Re: [Zope-dev] consistent naming in ZEO releases
On Monday 25 November 2002 2:03 pm, Andrew Sydelko wrote: You'll see that when I switched to ZEO 2.0 I had to change the URL. No doubt you had to change alot more too. This was a major release. Lots of things changed between ZEO 1 and ZEO 2. I think you picked a bad example; I agree it should be consistent between minor releases of the same product. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] consistent naming in ZEO releases
On Mon, 25 Nov 2002 16:29:45 + Toby Dickenson [EMAIL PROTECTED] wrote: On Monday 25 November 2002 2:03 pm, Andrew Sydelko wrote: You'll see that when I switched to ZEO 2.0 I had to change the URL. No doubt you had to change alot more too. This was a major release. Lots of things changed between ZEO 1 and ZEO 2. I think you picked a bad example; I agree it should be consistent between minor releases of the same product. I suppose. But why the change at all? --andy. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] KeywordIndex and PersistentList (Bug?)
JPS == Jeffrey P Shell Jeffrey writes: JPS What about ``if callable(aq_base(newKeywords)):`` to remove JPS potential acquisition wrappers? callable() returns True for any instance. Since PersistentList is an instance, you can't use callable() to determine whether it is callable. Jeremy ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] consistent naming in ZEO releases
I used distutils sdist to build the releases for ZEO and ZODB. I let distutils pick the file extension. Jeremy ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] KeywordIndex and PersistentList (Bug?)
Jeremy Hylton wrote: JPS == Jeffrey P Shell writes: JPS What about ``if callable(aq_base(newKeywords)):`` to remove JPS potential acquisition wrappers? callable() returns True for any instance. Any instance of what? [steve@localhost]$ python2.2 Python 2.2.2 (#1, Oct 31 2002, 10:45:23) [GCC 2.96 2731 (Red Hat Linux 7.2 2.96-108.7.2)] on linux2 Type help, copyright, credits or license for more information. callable(object()) 0 class Foo: ... pass ... callable(Foo()) 0 -- Steve Alexander ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] KeywordIndex and PersistentList (Bug?)
It must be any instance of an ExtensionClass. I think Python instances used to be true-for-callable as well, but that must have been fixed. Python 2.1.3 (#5, Aug 15 2002, 10:41:31) [GCC 2.95.3 19991030 (prerelease)] on linux2 Type copyright, credits or license for more information. from ZODB.PersistentList import * callable(PersistentList()) 1 Jeremy ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] KeywordIndex and PersistentList (Bug?)
There is a workaround for this in the DocumentTemplate package. It implements a safe_callable function that seems to do the right thing with ext class instances: def safe_callable(ob): # Works with ExtensionClasses and Acquisition. if hasattr(ob, '__class__'): if hasattr(ob, '__call__'): return 1 else: return type(ob) in ClassTypes else: return callable(ob) On Mon, 2002-11-25 at 13:01, Jeremy Hylton wrote: It must be any instance of an ExtensionClass. I think Python instances used to be true-for-callable as well, but that must have been fixed. Python 2.1.3 (#5, Aug 15 2002, 10:41:31) [GCC 2.95.3 19991030 (prerelease)] on linux2 Type copyright, credits or license for more information. from ZODB.PersistentList import * callable(PersistentList()) 1 Jeremy ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope ) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] vote
Title: Meddelande for my fantastic doughter Emma Rådahl to be Lucia(old tradition in Sweden on the 13th of december)of the town Uppsala in Sweden. You can vote for her if you go to www.unt.se/lucia and click on rösta (wich means vote) under the name Emma Rådahl (the last day to vote is 27 nov.) You can also lissen to her describing herself, but it is in Swedish. You can se 2 larger oicture of her if you go to http://erlboden.cjb.net and a popup come up. Ther will also be lin to the site were you can vote. Thank you /Emmas mother.
[Zope-dev] Moving forward with Zope 2.7
Is there already a schedule for Zope 2.7? (of course there is not :-) ) Now there is :) http://dev.zope.org/Wikis/DevSite/Projects/Zope2.7/FrontPage I've updated this project and tried to dispel any lingering confusion over the earlier effort labelled Zope 2.7. I proposed to include reStructuredText into Zope 2.7. This stuff is ready to be merged. If there are no objections I will merge it soon since there were only positive votes for the inclusion. Please don't merge anything until people have had a chance to see what's going on and gotten the plan finalized. Per the plan above, I'd like for there to be a (relatively short) period for people to volunteer and add proposals to the plan, followed by a process of prioritizing and coming to closure on what will / won't be included. I propose in the wiki that we should probably schedule an IRC day to do that. Brian Lloyd[EMAIL PROTECTED] V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Moving forward with Zope 2.7
Thanks for the clarifications! Andreas --On Montag, 25. November 2002 15:12 -0500 Brian Lloyd [EMAIL PROTECTED] wrote: Is there already a schedule for Zope 2.7? (of course there is not :-) ) Now there is :) http://dev.zope.org/Wikis/DevSite/Projects/Zope2.7/FrontPage I've updated this project and tried to dispel any lingering confusion over the earlier effort labelled Zope 2.7. I proposed to include reStructuredText into Zope 2.7. This stuff is ready to be merged. If there are no objections I will merge it soon since there were only positive votes for the inclusion. Please don't merge anything until people have had a chance to see what's going on and gotten the plan finalized. Per the plan above, I'd like for there to be a (relatively short) period for people to volunteer and add proposals to the plan, followed by a process of prioritizing and coming to closure on what will / won't be included. I propose in the wiki that we should probably schedule an IRC day to do that. Brian Lloyd[EMAIL PROTECTED] V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope ) - -Andreas Jung http://www.andreas-jung.com - - EMail: andreas at andreas-jung.com - -Life is too short to (re)write parsers - - ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Moving forward with Zope 2.7
Hi Could we get the Install and Configuration proposal cleaned up, with so many comments it's not clear what the actual proposal proposes to deliver now. Also parts of it's problem statement are just plain wrong. I currently have many (read every version of Zope including Alpha's and Betas since 2.4.1b1) installed on the same box, and I have 18 instances of which at least 8 are running concurrently on our dev box, currently using at least 2 different versions of Zope (2.5.1 and 2.6.0). (Some of the non running instances if I started them up would be on 2.4.3 etc.. Currently we can do everything listed as a problem in the proposal, it is clean, neat and everything is in it's place. (except maybe item 5 in the problem statement) Regards Tim On Tue, 2002-11-26 at 04:12, Brian Lloyd wrote: Is there already a schedule for Zope 2.7? (of course there is not :-) ) Now there is :) http://dev.zope.org/Wikis/DevSite/Projects/Zope2.7/FrontPage I've updated this project and tried to dispel any lingering confusion over the earlier effort labelled Zope 2.7. I proposed to include reStructuredText into Zope 2.7. This stuff is ready to be merged. If there are no objections I will merge it soon since there were only positive votes for the inclusion. Please don't merge anything until people have had a chance to see what's going on and gotten the plan finalized. Per the plan above, I'd like for there to be a (relatively short) period for people to volunteer and add proposals to the plan, followed by a process of prioritizing and coming to closure on what will / won't be included. I propose in the wiki that we should probably schedule an IRC day to do that. Brian Lloyd[EMAIL PROTECTED] V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope ) DISCLAIMER: This email, including any attachments, is intended only for use by the addressee(s) and may contain confidential and/or personal information and may also be the subject of legal privilege. Any personal information contained in this email is not to be used or disclosed for any purpose other than the purpose for which you have received it. If you are not the intended recipient, you must not disclose or use the information contained in it. In this case, please let me know by return email, delete the message permanently from your system and destroy any copies. Emails and their attachments may be interfered with, may contain computer viruses or other defects and may not be successfully replicated on other systems. All attachments are opened at the recipient's risk. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Moving forward with Zope 2.7
On Mon, 2002-11-25 at 20:42, [EMAIL PROTECTED] wrote: Could we get the Install and Configuration proposal cleaned up, with so many comments it's not clear what the actual proposal proposes to deliver now. Yes when possible. I agree that it is a bit of a mess. In the meantime, I think this list summarizes the adjusted goals well: * configure; make; make install installation * control script for starting/stopping/debugging zope * config file for all options including logging, servers, and databases. * real effective user support (logfiles, database files, etc. dont get written as root if you start as root). * better support for instance home/software home split * better support for Windows services * RPM-building support. * where possible, the banishment of environment variables as configuration. All of these things save for the last are more or less complete on the chrism-install-branch of the Zope trunk. The major missing piece is the fleshing out of the interaction between the configuration system (ZConfig) and Zope itself. It works currently but it needs to be improved and canonized to everyone's liking. Since ZConfig will also used by other ZC software (ZEO, ZRS), there's a bit of back and forth that needs to be done to get everybody to agree on a way to do it. Once that is worked out, and the proposal is cleaned up, I think we can just merge. Also parts of it's problem statement are just plain wrong. I currently have many (read every version of Zope including Alpha's and Betas since 2.4.1b1) installed on the same box, and I have 18 instances of which at least 8 are running concurrently on our dev box, currently using at least 2 different versions of Zope (2.5.1 and 2.6.0). (Some of the non running instances if I started them up would be on 2.4.3 etc.. I think this part of the problem statement (#4) is not within the scope of the deliverables required by the proposal anymore (which of course lines up with your first comment ;-) - C ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Moving forward with Zope 2.7
* where possible, the banishment of environment variables as configuration. I have to say, I think this is a bad idea. What is it about environment variables do you find worthy of banishment? I can tell you a few of the reason I really like them: a) Code spent garnering values is minimal, I don't have to worry about acres of code spent parsing yet another config file format or the inevitable quirks and bugs in that code. It doesn't get much simpler than os.environ.get() b) I have tools to examine runtime environments which are external to the zope application and any of its limitations. If I wanna know what a particular value is, I can just find out using ps. I don't have to dig around in the zmi, or rely on any custom clients to query that data from a running instance. c) Environment variables lend themselves to nicely to modification by third party tools; I can set environment variables in shell scripts, python scripts, whatever--the paradigm is language agnostic. In particular I'm rather fond of using daemontools and its envdir program in conjunction with a custom z2.py replacement that lets me take advtanage of the excelent supervision and logging infrastucture provided by daemontools. Force me to use an external config file and its going to make this kind of thing more difficult to do. That said I know they aren't an end-all solution for all configuration needs, but just because they don't fit every need I don't see why they should be completely discounted. -- Jamie Heilman http://audible.transient.net/~jamie/ You came all this way, without saying squat, and now you're trying to tell me a '56 Chevy can beat a '47 Buick in a dead quarter mile? I liked you better when you weren't saying squat kid. -Buddy ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-Coders] Re: [Zope-dev] Moving forward with Zope 2.7
In the meantime, I think this list summarizes the adjusted goals well:
* configure; make; make install installation
* control script for starting/stopping/debugging zope
I'd like to compare notes on this. Where's the control script that
you are using? I'm hoping that we can use (some future evolution of)
zdaemon/{zdaemon,zdctl}.py in the Zope 2.7 trunk. This separates the
concerns of
- the actual server process (Zope/ZEO/ZRS; for ZEO, this is
runsvr.py)
- a daemon subprocess manager, which restarts the subprocess when it
dies, etc. (zdaemon.py)
- a tool to control the subprocess manager, telling it to
start/restart/stop the server subprocess, etc. (zdctl.py)
* config file for all options including logging,
servers, and databases.
* real effective user support (logfiles, database files, etc.
dont get written as root if you start as root).
* better support for instance home/software home split
* better support for Windows services
I'd like to hear more about this; my zdaemon.py currently doesn't do
Windows at all. Where can I peek at your code?
* RPM-building support.
* where possible, the banishment of environment variables
as configuration.
All of these things save for the last are more or less complete on
the chrism-install-branch of the Zope trunk. The major missing
piece is the fleshing out of the interaction between the
configuration system (ZConfig) and Zope itself. It works currently
but it needs to be improved and canonized to everyone's liking.
Can you point to where Zope's use of ZConfig is?
Since ZConfig will also used by other ZC software (ZEO, ZRS),
there's a bit of back and forth that needs to be done to get
everybody to agree on a way to do it. Once that is worked out, and
the proposal is cleaned up, I think we can just merge.
Apologies in advance: my refrain seems to be where's your code for
X? -- there's so much good stuff in your branch that I don't know
where to begin, especially not with the Zope part (in ZODB, I know my
way around better).
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Moving forward with Zope 2.7
On Tue, 2002-11-26 at 01:29, Jamie Heilman wrote: * where possible, the banishment of environment variables as configuration. I have to say, I think this is a bad idea. What is it about environment variables do you find worthy of banishment? I can tell Banishment was a bad word. It's not really so much that I think that environment variables are evil or anything, it's just that I think there should be one and only place to find and set most configuration data for Zope. Currently you configure Zope via a combination of z2.py switches and envvars. There are currently 40 Zope environment variables and 22 z2.py switches. There is no definitive reason for any one of these settings becoming a switch over an envvar or vice-vera (it was at the whim of the particular developer who decided to add the config requirement), so it appears (and is) rather haphazard. Some things like 'Z_DEBUG_MODE and the -D switch actually even do the same thing, and it's hard to tell which you're supposed to use and which is supposed to win in these cases. Additionally, some things aren't really configurable at all (you're stuck with file or syslog logging, no way to send to an NT event service, etc). We'd like to fix this kind of thing and provide a more consistent front-end to configuring Zope settings. Additionally, since lots of Zope configuration data wants to be hierarchical (loggers, zodb databases, severs), and since environment variables and switches don't lend themselves particularly well to being hierarchical, a hierarchical config file format is nice. I hope this makes sense as a defense of using a config file. I don't particularly like config files either, but I think once a piece of software reaches a critical mass, they become a necessary evil. In my opinion, Zope reached that mass about three years ago. ;-) a) Code spent garnering values is minimal, I don't have to worry about acres of code spent parsing yet another config file format or the inevitable quirks and bugs in that code. It doesn't get much simpler than os.environ.get() Yup. We've got a seriously complicated piece of software to deal with config files now, and it's only getting more complicated. So I can sympathize with this entirely. b) I have tools to examine runtime environments which are external to the zope application and any of its limitations. If I wanna know what a particular value is, I can just find out using ps. I don't have to dig around in the zmi, or rely on any custom clients to query that data from a running instance. I feel that it's just as simple (or maybe simpler) to look in a config file. The Zope config file will be stored on the filesystem (not in the ZODB), and it's in a format much like an Apache config file, so no ZMI or custom client stuff will be necessary. There will be tools provided to parse the config file if necessary. c) Environment variables lend themselves to nicely to modification by third party tools; I can set environment variables in shell scripts, python scripts, whatever--the paradigm is language agnostic. In particular I'm rather fond of using daemontools and its envdir program in conjunction with a custom z2.py replacement that lets me take advtanage of the excelent supervision and logging infrastucture provided by daemontools. Force me to use an external config file and its going to make this kind of thing more difficult to do. That said I know they aren't an end-all solution for all configuration needs, but just because they don't fit every need I don't see why they should be completely discounted. They shouldn't be. Lots of applications use environment variables as superglobals (e.g. $HOME, $PYTHONPATH, etc.), and this should be the kind of thing that Zope should use them for as well. I can see, for example, setting the SOFTWARE_HOME using an environment variable or throwing some debug switch using an envvar. But stuff like ZSESSION_TIMEOUT_LIMIT and ZOPE_DTML_REQUEST_AUTOQUOTE and the mishmash of logging parameters (STUPID_LOG_FILE, ZSYSLOG, ZSYSLOG_ACCESS, etc) are just begging to be put into some sort of configuration file. So far, we've done a bunch of work to come up with a config file format, some parsing software, and some configuration schema software. We're hoping that with a little work, we can make the configuration of Zope through a config file not suck *too* badly. If you have ideas about what should (and should not) be done wrt canonizing a config file for Zope, please detail specifics here as nothing is set in stone. Cheers, - C ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
