[Zope-dev] Renaming a product
Hi Morten, Hi all, does anyone know how to rename a product, so that instances of the product stored in ZODB will work (with the new name) after the rename? I assume the problem is that the product is named A should be renamed into B in such a way that all instances of class Product.A.Foo are of type Product.B.Foo afterwards. The only way I could think of is to write a migration function for each class in Product A, which gets an instance e.g. of class Products.A.Foo and returns an instance of class Products.B.Foo which is suitable to replace the other instance. If all Your classes are stored via some standard implementations of OFS.ObjectManager, it should be easy to recurse from the Zope Application root and descent into all folders, converting all object of the old product into those of the new product via the migrtation function. The actual work is the transformation of instances of class A.Foo to class B.Foo; to be on the safe side one would have to copy over all attributes manually. If You want to try a fast and dirty solution, You could try to write the new class into the '__class__' attribute of the instance of the old class, making it an instance of the new class, but I do not know it this really works. Cheers, Clemens ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] storing passwords
On Mon, 16 Jun 2003, Chris Withers wrote:
[EMAIL PROTECTED] wrote:
Or SimpleUserFolder: create a user folder class in a Zope product that
subclasses both SimpleUserFolder and OFS.Folder. Then put ZSQL methods and
a few TTW python scripts in the folder contents of an instance of this class
to make it work. I've done something similar to this with relative success.
Hmmm... I prefer to just put the SQL method in the folder containing the SUF, no
need for subclassing and knowing how to write Zope Products then...
I installed SimpleUserFolder and implemented the required methods. I can
now add and modify users but there is one thing missing. Where do I tell
Zope how to check the password when users try to authenticate? It should
be done with:
select * from intrauser
where username = 'submitted_username'
and pwdigest = crypt('submitted_password', pwdigest)
The crypt-function is stored in PostgreSQL (a contrib package). In this
way I can have many programs share the same password database.
pgUserFolder has user_login() so this would probably be a possible
solution. Is there an easy solution with SimpleUserFolder?
Markus
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] 2.7 installation
My company has a business need for better Debian packages of Zope (and particularly, packages of ZEO). I have outlined a proposal for an installation regime that will greatly simplify installation in a UNIX environment, with a configuration that Debian would use for installation. I bring it up here because my proposal probably requires some changes to the source tree which may suit being accepted upstream, and because we have a (sponsored) opportunity to hone Zope for a Debian environment (a not uncommon and very high-quality distrubution). I am, however, not yet familiar enough with the distutils to know if this regime is possible, nor am I familiar with the Windows installation. Also, it pushes my relentless agenda to get the standalone packages of Zope packaged as separate dependencies which may, I sense, not suit everyone! ;-) It is at http://homepages.flow.com.au/~avdd/zope-newinstall.html and included here. Comments? Cc'ed current Debian maintainers for completeness. === Zope installation overhaul proposal === The Problem +++ I have some concerns about the new installation mechanism, particularly how it will work for a UNIX (specifically Debian) install. Currently, a configure script (written in Python) writes a makefile, which installs software into the --prefix, as per custom:: $ ./configure --prefix=$PREFIX $ make $ sudo make install This installs the software under ``$PREFIX``, producing this layout:: $PREFIX/ bin/ doc/ import/ lib/ skel/ utilities/ You then make an instance:: $ /usr/lib/zope/bin/mkzopeinstance $INSTANCE This creates a Zope instance in $INSTANCE, like so:: $INSTANCE/ Extensions/ Products/ bin/ etc/ import/ log/ var/ The problems with this procedure are: 1. one --prefix is too limiting with this tree. You can't install into an existing hierarchy like /usr, because of the zope-specific directories import, skel and utilities. 2. $INSTANCE/bin/* are just shell wrappers for their respective scripts in $PREFIX/bin, serving only to point to the correct configuration and software paths, also requiring you to supply a full path to the script. This should instead be a global control script that takes an instance name as an argument: # zopectl -i default start 3. This installs all of Zope, ZODB, ZEO and zdaemon. I am uncomfortable with this blurring of function between applications (runzeo.py) and libraries (ZODB) ... probably more ... skip to solution: The Solution For Zope The make install step:: EXECPREFIX=$PREFIX LIBPREFIX=$PREFIX SKELPREFIX=$PREFIX DOCPREFIX=$PREFIX BIN=$EXECPREFIX/bin LIB=$LIBPREFIX/lib # python, etc. DOC=$DOCPREFIX/doc SKEL=$SKELPREFIX/skel With ``PREFIX=/zope``, you get:: /zope/bin/ zopectl.py runzope.py utils.py etc. /zope/doc/ import/ Examples.zexp README.txt etc. /zope/lib/ python, etc /zope/skel/ Extensions/ Products/ etc/ import/ log/ var/ Then the administrator (or initial installation) runs:: # mkzopeinstance /var/lib/zope/default/var -l /var/log/zope/default which copies ``$SKEL/*`` to ``/var/lib/zope/default``. To start, stop, restart zope:: # zopectl default (start|stop|status|restart|etc) Other Z* packages = Note that the above procedure installs only Zope. It requires ZODB (a standalone package) to be installed. ZEO is a separate package. It installs similarly to Zope, with instances similarly created with ``$PREFIX/bin/mkzeoinstance``. This may require some changes to the source tree. The Debian package == Debian's package would use:: PREFIX=/usr SKEL=$PREFIX/share/zope/skel DOC=$PREFIX/share/doc/zope Producing this layout:: /usr/bin/ zopectl.py runzope.py utils.py etc. /usr/share/doc/zope/ import/ Examples.zexp README.txt etc. /usr/lib/ python, etc /usr/share/zope/skel/ Extensions/ Products/ etc/ import/ log/ var/ The Debian installation would create a default instance, possibly prompting for the name (otherwise default). It would also create: - ``/etc/init.d/zope`` (starts the first instance, or all instances) - ``/etc/default/zope`` (lists instances) Debian's ``mkzopeinstance`` would symlink ``/etc/zope/$INSTANCE`` to ``/var/lib/zope/$INSTANCE/etc`` (like postgresql), and it may
Re: [Zope-dev] 2.7 installation
On Wed, 2003-06-18 at 06:18, Adrian van den Dries wrote: 1. one --prefix is too limiting with this tree. You can't install into an existing hierarchy like /usr, because of the zope-specific directories import, skel and utilities. Yes. Good point. I'd like to see us change the directory structure around so that installation into an existing prefix would be possible. This would imply getting rid of import, skel, and utilities and might mean (as per your suggestion) allowing more specific prefix targets for docs, lib, exec, etc. This is a bit of work, but would be possible. The setup.py script would need to be pretty smart. However, if we end up keeping it the way it currently is, the --prefix option should really be named --home so as to prevent any misunderstanding. 2. $INSTANCE/bin/* are just shell wrappers for their respective scripts in $PREFIX/bin, serving only to point to the correct configuration and software paths, also requiring you to supply a full path to the script. This should instead be a global control script that takes an instance name as an argument: # zopectl -i default start Actually the scripts in $INSTANCE/bin aren't shell wrappers for things in $PREFIX/bin, they're shell wrappers for thing in $PREFIX/lib/python/Zope/Startup. But yes, they are shell wrappers. If you made a global control script that worked as per your example, how would you identify where the 'default' instance is? FWIW, I'd be very opposed to any sort of limitations on where instance homes could be placed to service this global control script's need to find instances. If you have only one Zope instance on your machine, you can link the zopectl script to /usr/bin/zopectl and get the convenience of typing 'zopectl' to do what you mention instead of '/path/to/zopectl'. If you have more than one Zope instance on your machine, I think they should be controlled by separate scripts instead of requring a framework to manage multiple instances on the same machine through some sort of path identification or config file listing all instances on the machine. See my comment in http://dev.zope.org/Wikis/DevSite/Proposals/InstallationAndConfiguration dated Aug 22, 2002 8:09 pm for more background. 3. This installs all of Zope, ZODB, ZEO and zdaemon. I am uncomfortable with this blurring of function between applications (runzeo.py) and libraries (ZODB) OK. For Zope The make install step:: EXECPREFIX=$PREFIX LIBPREFIX=$PREFIX SKELPREFIX=$PREFIX DOCPREFIX=$PREFIX BIN=$EXECPREFIX/bin LIB=$LIBPREFIX/lib # python, etc. DOC=$DOCPREFIX/doc SKEL=$SKELPREFIX/skel With ``PREFIX=/zope``, you get:: /zope/bin/ zopectl.py runzope.py utils.py etc. /zope/doc/ import/ Examples.zexp README.txt etc. /zope/lib/ python, etc /zope/skel/ Extensions/ Products/ etc/ import/ log/ var/ This sounds good. I'm not so sure about $SKELPREFIX. Maybe we could just move the skel directory into the lib directory and consider it part of Zope's libraries. Also, currently the scripts in $PREFIX/bin rely on being in a directory which peers with the lib directory. This would need to change were we to be able to specify an execprefix. Additionally, a particular execprefix would need to depend on the existence of a particular libprefix (the scripts in bin rely on being able to import stuff from libraries in the lib directory). This is why they're currently not broken apart. Then the administrator (or initial installation) runs:: # mkzopeinstance /var/lib/zope/default/var -l /var/log/zope/default which copies ``$SKEL/*`` to ``/var/lib/zope/default``. What does -l do? To start, stop, restart zope:: # zopectl default (start|stop|status|restart|etc) Other Z* packages = Note that the above procedure installs only Zope. It requires ZODB (a standalone package) to be installed. It is not desirable to make people configure and install ZODB separately if they install from a tarball source distro. With package-managed distributions (especially apt which has very nice automated dependency management), this isn't such a big deal, but we want to make it easy to install a running Zope from source using with maximum complexity of './configure; make; make install'. That said, I agree in sentiment. If you want to change the setup.py script for Zope to do the right thing so it invokes ZODB's setup.py and the outcome is the same, I'd have no problem with that. Ditto for ZEO. Debian packages ZEO and the ZODB similarly, and ZEO and Zope depend on the ZODB. In the past, my offers to provide upstream support for Debian packaging hasn't been met with much enthusiasm. If I can make it easier for people to package
[Zope-dev] BTree fixes in a release?
There lave been various BTree fixes lounging in the HEAD since Jan 2003 which I'd like to get into a release, basically because we have seen one of the bugs causing segfaults in production - this is the culprit: http://cvs.zope.org/Zope/lib/python/BTrees/BTreeItemsTemplate.c.diff?r1=1.17r2=1.18 a) Any reason why I shouldn't merge it into the 2.6 branch? b) Any chance of a 2.6.2b3? Seb ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Memory Error
Thanks for the responses everyone. This message occured more frequently when I was showing the getNewOrRandom slot which does a few catalog searches and mucks them around. I've turned off that slot and setup a nightly restart cron. I'm waiting for it to happen again (it hasn't yet), but it looks like the BTrees and Catalog results could be a place to start. Its got a gig of ram and about 500 mb is free most of the time apparently, but next time it happens I'll see if I can get more info. Just have to hurry up and wait now ;) Or wait for runyaga to visit it, he seems to have this curse with it. -- Andy McKay http://www.agmweb.ca ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
FHS, zopectl, #925, Re: [Zope-dev] 2.7 installation
On Wed, Jun 18, 2003 at 11:23:15AM -0400, Chris McDonough wrote: Actually the scripts in $INSTANCE/bin aren't shell wrappers for things in $PREFIX/bin, they're shell wrappers for thing in $PREFIX/lib/python/Zope/Startup. But yes, they are shell wrappers. And so they would be copied for all instance installed: they would not probably be that large, but what about symbolik links? If you made a global control script that worked as per your example, how would you identify where the 'default' instance is? I was not aware of a zopectl in the repository so i builded one in python for Debian. As i can see it's quite more powerful than the one you are going to include: http://packages.debian.org/unstable/admin/zopectl.html I would care about any comment. FWIW, I'd be very opposed to any sort of limitations on where instance homes could be placed to service this global control script's need to find instances. [...] http://dev.zope.org/Wikis/DevSite/Proposals/InstallationAndConfiguration dated Aug 22, 2002 8:09 pm for more background. It's my opinion that a zope instance can be described trough a configuration file, thus not requiring multiple commands or links but rather a single command capable of using multiple configuration files. If you combine my zopectl script with the patch is proposed for z2.py (http://collector.zope.org/Zope/925), you'll have a good FHS[1] compliant framework for multiple INSTANCE_HOMEs (being still able to place any file where you like). This sounds good. I'm not so sure about $SKELPREFIX. Maybe we could [...] libraries in the lib directory). This is why they're currently not broken apart. To say it all there is only one thing i really need: a way to install _all_ documentation files under a separate directory in a way thay cannot overlap. For what concern Debian, the intallation home will still be /usr/lib/zope untill python fully comply FHS[1] (http://python.org/sf/588756). I'll probably move it to /usr/lib/python2.1/site-packages in future, but i'm still not sure. In the past, my offers to provide upstream support for Debian packaging hasn't been met with much enthusiasm. If I can make it easier for people to package Zope for Debian, I'd love to, but I'd need to have some buyin and support from the current Debian packagers. Otherwise, it ends up being a waste of time on both of our parts as it won't be what's best for either of us. It's not that easy to co-maintain the Debian package for Zope: we actually lacks the structures to set up work with non Debian Developers. I suppose this problem will be solved soon, but if you like i can start collecting patches for the CVS repository i've already set up for that purpose. Take a look at https://alioth.debian.org/projects/pkg-zope and its CVS repository. Debian's packaging and installation strategy for Zope has always been very customized and divergent from the Zope source distribution's packaging and installation strategy. At very worst, it could stay this way. Debian has choosed to be be strictly compliant to FHS[1], including it in the Debian Packaing Policy. Not complying to Debian Policy is considered a grave bug for any package in the distribution. Current Zope upstream package is not that compliant, so we always have to modify the package. I hope this will change in future. ciao, [1] http://www.pathname.com/fhs/ -- Luca - De Whiskey's - De Vitis | Elegant or ugly code as well aliases: Luca ^De [A-Z][A-Za-z\-]*[iy]'\?s$ | as fine or rude sentences have Luca, a wannabe ``Good guy''. | something in common: they local LANG=[EMAIL PROTECTED] | don't depend on the language. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Renaming a product
Clemens Robbenhaar wrote: The actual work is the transformation of instances of class A.Foo to class B.Foo; to be on the safe side one would have to copy over all attributes manually. If You want to try a fast and dirty solution, You could try to write the new class into the '__class__' attribute of the instance of the old class, making it an instance of the new class, but I do not know it this really works. Somebody correct me please, if I'm wrong, but 1. tinkering with __class__ is the only way to do this. 2. you can not tinker with __class__ of an ExtensionClass, i.e. all Persistent objects. So, it is not doable, IIRC. Phil ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Renaming a product
Somebody correct me please, if I'm wrong, but 1. tinkering with __class__ is the only way to do this. 2. you can not tinker with __class__ of an ExtensionClass, i.e. all Persistent objects. It's not easily doable, no. I settled on converting each instance (copying properties) from the old product name to the new, and it worked. Thanks for your help everybody. :) Regards, Morten W. Petersen -- Technologies: Zope, Linux, Python, HTML, CSS, PHP Homepage: http://www.nidelven-it.no Phone number: (+47) 45 44 00 69 ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: FHS, zopectl, #925, Re: [Zope-dev] 2.7 installation
On Wed, 2003-06-18 at 13:18, Luca - De Whiskey's - De Vitis wrote: On Wed, Jun 18, 2003 at 11:23:15AM -0400, Chris McDonough wrote: Actually the scripts in $INSTANCE/bin aren't shell wrappers for things in $PREFIX/bin, they're shell wrappers for thing in $PREFIX/lib/python/Zope/Startup. But yes, they are shell wrappers. And so they would be copied for all instance installed: they would not probably be that large, but what about symbolik links? These files needn't be here really. There are two scripts: zopectl and runzope. They are convenience shell scripts that run zopectl.py or runzope.py scripts that live in a software home after setting certain envvars. Each of these shell scripts identifies a unique combination of software home, instance home, config file path, and pythonpath. These can be unique per instance, so using a symlink to a common set of files will not work. A typical zopectl script could be replaced with the following command line: ZOPE_HOME=/opt/Zope27 \ INSTANCE_HOME=/usr/local/zope/instance1 \ PYTHONPATH=/opt/Zope27/lib/python \ /usr/bin/python2.2 \ /opt/Zope27/lib/python/Zope/startup/zopectl.py \ -C /usr/local/zope/instance1/etc/zope.conf The -C tells where the Zope config file is. The config file represents settings for a single Zope instance. One of these config files is created for each Zope instance via 'mkzopeinstance'. If you made a global control script that worked as per your example, how would you identify where the 'default' instance is? I was not aware of a zopectl in the repository so i builded one in python for Debian. As i can see it's quite more powerful than the one you are going to include: http://packages.debian.org/unstable/admin/zopectl.html I would care about any comment. I think this is great. The zopectl that ships with Zope now is capable of controlling a single Zope instance. Your system takes on the larger burden of simultaneous multi-instance Zope configuration and control on a single machine. Your code looks quite nice as well. Your system is a perfect example of a value-added frontend for zope. I can see that many people would want to use this kind of framework. I'd love to see people come up with their own Zope mgmt frameworks and use them as a frontend for Zope instance management with minimal involvement from the Zope source tarball installer. Different frameworks will be more or less valuable on different platforms; for example a Windows multi-instance controller might be a GUI app. As far as the current installation regime goes, I'm aiming to keep common-case (single-instance) installation and operation very simple, much like Apache's. If you want to change your Zope controller to work with 2.7, I think you'll either be very happy (or very disappointed, seeing how much work you put in to creating your own config files) to know that Zope 2.7+ instances have their own configuration file which has a syntax patterned after an Apache configuration file; the parsing system uses the ZConfig package (http://www.zope.org/Members/fdrake/zconfig/). I have attached the zope.conf.in file that represents a valid Zope instance configuration file. As an upshot, z2.py no longer exists and the zopectl that runs Zope now on the HEAD knows how to read and interpret the config file. All of the settings you've made configurable within, e.g. your 'default.conf' are configurable via this config file. Additionally, ZConfig lets you perform a textual include of external files into a config file; if you've got common settings in one config file, you can customize the settings for an instance in a small instance config file and %include the common config file into it (even via an HTTP GET if necessary). See the zconfig docs for more information. I'd love to see your zopectl system work with Zope 2.7, and though I likely wouldn't want to package it with Zope, I'd love to see it be able to operate as a front end controller for multiple Zope 2.7 instances. It will not work against the current Zope HEAD because the HEAD no longer has z2.py (everything about Zope startup has changed post-2.6). If you want it to support Zope 2.7, I'd be happy to answer any questions about the new installation/startup process. In particular, I think you'd need to change your zopectl conf file. Instead of keeping all configuration options in the zopectl.conf file, each instance section could keep a smaller set of keys. For example: [Zope] Config-File: /path/to/instance/etc/zope.conf [Instance2] Config-File: /path/to/instance2/etc/zope.conf .. etc... The instance config files could %include a common /etc/zope.conf config file with most of the default settings (instead of using a [DEFAULT] section). You could then throw away most of your parsing code in ZopeCTL.py, and instead of running z2.py in your __start method, run the zopectl associated with the software home, pointing it at the proper config file. FWIW, I'd be very opposed to any sort
Re: [Zope-dev] storing passwords
Sorry to keep spamming this list. I just want to present a solution if
someone browses the archives.
I installed exUserFolder. And in pgAuthSource.py defined
def remoteAuthMethod(self, username, password):
to use a Z SQL Method
instead of
remoteAuthMethod=None
It works.
//Markus
On Wed, 18 Jun 2003, Markus Bengts wrote:
On Mon, 16 Jun 2003, Chris Withers wrote:
[EMAIL PROTECTED] wrote:
Or SimpleUserFolder: create a user folder class in a Zope product that
subclasses both SimpleUserFolder and OFS.Folder. Then put ZSQL methods and
a few TTW python scripts in the folder contents of an instance of this class
to make it work. I've done something similar to this with relative success.
Hmmm... I prefer to just put the SQL method in the folder containing the SUF, no
need for subclassing and knowing how to write Zope Products then...
I installed SimpleUserFolder and implemented the required methods. I can
now add and modify users but there is one thing missing. Where do I tell
Zope how to check the password when users try to authenticate? It should
be done with:
select * from intrauser
where username = 'submitted_username'
and pwdigest = crypt('submitted_password', pwdigest)
The crypt-function is stored in PostgreSQL (a contrib package). In this
way I can have many programs share the same password database.
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Domain Login Slowness at certain location
Hello All, I set up an Intranet that is based on visitors IP Address. I made a tutorial at Plone.org (http://plone.org/documentation/howto/HowToDomainIntranet). Now my problem is that I am experiencing a lot of slowness for someone that is within the domain, but it is only within this one location. So, if I set the site to check my address and log me in, there is not slowness. But if I change the site to log people in automatically if they have the ip address for the gateway at the location, it is very very slow loading for all of them. Does anyone know the processes that the domain attribute goes through to log people in? Or maybe have an idea what could cause it? I am trying to diagnose and I am not sure what could cause it. It is the mixture of the automatic login and firewall or something else at the location. Any ideas? Thanks Andrew R. Halko ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Domain Login Slowness at certain location
On Wed, 2003-06-18 at 16:07, Andrew R. Halko wrote: Hello All, I set up an Intranet that is based on visitors IP Address. I made a tutorial at Plone.org (http://plone.org/documentation/howto/HowToDomainIntranet). Now my problem is that I am experiencing a lot of slowness for someone that is within the domain, but it is only within this one location. So, if I set the site to check my address and log me in, there is not slowness. But if I change the site to log people in automatically if they have the ip address for the gateway at the location, it is very very slow loading for all of them. Does anyone know the processes that the domain attribute goes through to log people in? Or maybe have an idea what could cause it? I am trying to diagnose and I am not sure what could cause it. It is the mixture of the automatic login and firewall or something else at the location. Any ideas? Thanks The code to support this domain auth feature is perhaps the stupidest part of Zope.access control. I am disappointed that it is still supported. Here is the code to support this mode of authentication, ripped directly from the AccessControl.User module: # we need to continue to support this silly mode # where if there is no auth info, but if a user in our # database has no password and he has domain restrictions, # return him as the authorized user. if not auth: if self._domain_auth_mode: for user in self.getUsers(): if user.getDomains(): if self.authenticate(user.getUserName(), '', request): if self.authorize(user, a, c, n, v, roles): return user.__of__(self) So this means, in essence, on each request, *for each user in the system*, check if he he has domain restrictions, if so is able to get in to the site with a blank password. For a site with many users, iterating over each user, checking for his domain restrictions, and so on can take a long time. And note that this doesn't just happen on one request, it happens on *every* request. Worse, it doesn't just happen for requests that happen to come from the domain upon which you've placed domain restrictions, it happens for *all* requests except the ones that pass in auth credentials via HTTP (from people who have already presented a valid username/password). This is almost certainly the cause of the slowness you see. I have been trying to remove this feature for quite some time. I can see its utility but the implementation is just way too stupid to be used for anything but tiny user databases. One possible hack that might make things much faster *for the people in the domain you're trying to allow access from* is to make sure that the *first* user returned by getUsers is the user that has the domain restrictions and blank password. A simple way to do this is to name that user User (because the default user folder's getUsers sorts the users by the lexical order of their names). This way the loop above will at most be gone through once for browsers in the domains you mention in that user's domain spec. This will not be the case for anonymous users. They will go through the whole user database for every request and only fall off the end of the userlist once they've tested every user. It will thus be just as slow for them. HTH, - C ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
RE: [Zope-dev] Domain Login Slowness at certain location
Any other suggestions on how to implement domain based access? Or is the only solution to make users create accounts and login. For a large organization, this is tough. Andrew R. Halko -Original Message- From: Chris McDonough [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 18, 2003 5:03 PM To: Andrew R. Halko Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: [Zope-dev] Domain Login Slowness at certain location On Wed, 2003-06-18 at 16:07, Andrew R. Halko wrote: Hello All, I set up an Intranet that is based on visitors IP Address. I made a tutorial at Plone.org (http://plone.org/documentation/howto/HowToDomainIntranet). Now my problem is that I am experiencing a lot of slowness for someone that is within the domain, but it is only within this one location. So, if I set the site to check my address and log me in, there is not slowness. But if I change the site to log people in automatically if they have the ip address for the gateway at the location, it is very very slow loading for all of them. Does anyone know the processes that the domain attribute goes through to log people in? Or maybe have an idea what could cause it? I am trying to diagnose and I am not sure what could cause it. It is the mixture of the automatic login and firewall or something else at the location. Any ideas? Thanks The code to support this domain auth feature is perhaps the stupidest part of Zope.access control. I am disappointed that it is still supported. Here is the code to support this mode of authentication, ripped directly from the AccessControl.User module: # we need to continue to support this silly mode # where if there is no auth info, but if a user in our # database has no password and he has domain restrictions, # return him as the authorized user. if not auth: if self._domain_auth_mode: for user in self.getUsers(): if user.getDomains(): if self.authenticate(user.getUserName(), '', request): if self.authorize(user, a, c, n, v, roles): return user.__of__(self) So this means, in essence, on each request, *for each user in the system*, check if he he has domain restrictions, if so is able to get in to the site with a blank password. For a site with many users, iterating over each user, checking for his domain restrictions, and so on can take a long time. And note that this doesn't just happen on one request, it happens on *every* request. Worse, it doesn't just happen for requests that happen to come from the domain upon which you've placed domain restrictions, it happens for *all* requests except the ones that pass in auth credentials via HTTP (from people who have already presented a valid username/password). This is almost certainly the cause of the slowness you see. I have been trying to remove this feature for quite some time. I can see its utility but the implementation is just way too stupid to be used for anything but tiny user databases. One possible hack that might make things much faster *for the people in the domain you're trying to allow access from* is to make sure that the *first* user returned by getUsers is the user that has the domain restrictions and blank password. A simple way to do this is to name that user User (because the default user folder's getUsers sorts the users by the lexical order of their names). This way the loop above will at most be gone through once for browsers in the domains you mention in that user's domain spec. This will not be the case for anonymous users. They will go through the whole user database for every request and only fall off the end of the userlist once they've tested every user. It will thus be just as slow for them. HTH, - C ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
RE: [Zope-dev] Domain Login Slowness at certain location
The only real solution is to create a different user folder implementation that doesn't handle domain auth so stupidly. For instance, designate a user as a domain user and keep users like this around in a different data structure so you don't need to iterate over all users to find one that matches the domain spec. On Wed, 2003-06-18 at 17:07, Andrew R. Halko wrote: Any other suggestions on how to implement domain based access? Or is the only solution to make users create accounts and login. For a large organization, this is tough. Andrew R. Halko -Original Message- From: Chris McDonough [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 18, 2003 5:03 PM To: Andrew R. Halko Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: [Zope-dev] Domain Login Slowness at certain location On Wed, 2003-06-18 at 16:07, Andrew R. Halko wrote: Hello All, I set up an Intranet that is based on visitors IP Address. I made a tutorial at Plone.org (http://plone.org/documentation/howto/HowToDomainIntranet). Now my problem is that I am experiencing a lot of slowness for someone that is within the domain, but it is only within this one location. So, if I set the site to check my address and log me in, there is not slowness. But if I change the site to log people in automatically if they have the ip address for the gateway at the location, it is very very slow loading for all of them. Does anyone know the processes that the domain attribute goes through to log people in? Or maybe have an idea what could cause it? I am trying to diagnose and I am not sure what could cause it. It is the mixture of the automatic login and firewall or something else at the location. Any ideas? Thanks The code to support this domain auth feature is perhaps the stupidest part of Zope.access control. I am disappointed that it is still supported. Here is the code to support this mode of authentication, ripped directly from the AccessControl.User module: # we need to continue to support this silly mode # where if there is no auth info, but if a user in our # database has no password and he has domain restrictions, # return him as the authorized user. if not auth: if self._domain_auth_mode: for user in self.getUsers(): if user.getDomains(): if self.authenticate(user.getUserName(), '', request): if self.authorize(user, a, c, n, v, roles): return user.__of__(self) So this means, in essence, on each request, *for each user in the system*, check if he he has domain restrictions, if so is able to get in to the site with a blank password. For a site with many users, iterating over each user, checking for his domain restrictions, and so on can take a long time. And note that this doesn't just happen on one request, it happens on *every* request. Worse, it doesn't just happen for requests that happen to come from the domain upon which you've placed domain restrictions, it happens for *all* requests except the ones that pass in auth credentials via HTTP (from people who have already presented a valid username/password). This is almost certainly the cause of the slowness you see. I have been trying to remove this feature for quite some time. I can see its utility but the implementation is just way too stupid to be used for anything but tiny user databases. One possible hack that might make things much faster *for the people in the domain you're trying to allow access from* is to make sure that the *first* user returned by getUsers is the user that has the domain restrictions and blank password. A simple way to do this is to name that user User (because the default user folder's getUsers sorts the users by the lexical order of their names). This way the loop above will at most be gone through once for browsers in the domains you mention in that user's domain spec. This will not be the case for anonymous users. They will go through the whole user database for every request and only fall off the end of the userlist once they've tested every user. It will thus be just as slow for them. HTH, - C ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope ) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] zpt z-sql?
What would be the syntax to call a z-sql (passing one or more parameters) from a zpt? The z-sql would retrieve a single row. Fields from this row to be shown in the zpt. thx gerry rodman
RE: [Zope-dev] Domain Login Slowness at certain location
Sorry for not understanding and thank you for all the help... How do you create another user folder? What do you mean by keep users like this around in a different data structure? I currently am only using one user that is called Intranet User, is there an easy way to setup so that it just looks at that Users domain and not any other. I am not good enough with Zope to understand a lot of these concepts. Andrew R. Halko -Original Message- From: Chris McDonough [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 18, 2003 5:28 PM To: Andrew R. Halko Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: [Zope-dev] Domain Login Slowness at certain location The only real solution is to create a different user folder implementation that doesn't handle domain auth so stupidly. For instance, designate a user as a domain user and keep users like this around in a different data structure so you don't need to iterate over all users to find one that matches the domain spec. On Wed, 2003-06-18 at 17:07, Andrew R. Halko wrote: Any other suggestions on how to implement domain based access? Or is the only solution to make users create accounts and login. For a large organization, this is tough. Andrew R. Halko -Original Message- From: Chris McDonough [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 18, 2003 5:03 PM To: Andrew R. Halko Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: [Zope-dev] Domain Login Slowness at certain location On Wed, 2003-06-18 at 16:07, Andrew R. Halko wrote: Hello All, I set up an Intranet that is based on visitors IP Address. I made a tutorial at Plone.org (http://plone.org/documentation/howto/HowToDomainIntranet). Now my problem is that I am experiencing a lot of slowness for someone that is within the domain, but it is only within this one location. So, if I set the site to check my address and log me in, there is not slowness. But if I change the site to log people in automatically if they have the ip address for the gateway at the location, it is very very slow loading for all of them. Does anyone know the processes that the domain attribute goes through to log people in? Or maybe have an idea what could cause it? I am trying to diagnose and I am not sure what could cause it. It is the mixture of the automatic login and firewall or something else at the location. Any ideas? Thanks The code to support this domain auth feature is perhaps the stupidest part of Zope.access control. I am disappointed that it is still supported. Here is the code to support this mode of authentication, ripped directly from the AccessControl.User module: # we need to continue to support this silly mode # where if there is no auth info, but if a user in our # database has no password and he has domain restrictions, # return him as the authorized user. if not auth: if self._domain_auth_mode: for user in self.getUsers(): if user.getDomains(): if self.authenticate(user.getUserName(), '', request): if self.authorize(user, a, c, n, v, roles): return user.__of__(self) So this means, in essence, on each request, *for each user in the system*, check if he he has domain restrictions, if so is able to get in to the site with a blank password. For a site with many users, iterating over each user, checking for his domain restrictions, and so on can take a long time. And note that this doesn't just happen on one request, it happens on *every* request. Worse, it doesn't just happen for requests that happen to come from the domain upon which you've placed domain restrictions, it happens for *all* requests except the ones that pass in auth credentials via HTTP (from people who have already presented a valid username/password). This is almost certainly the cause of the slowness you see. I have been trying to remove this feature for quite some time. I can see its utility but the implementation is just way too stupid to be used for anything but tiny user databases. One possible hack that might make things much faster *for the people in the domain you're trying to allow access from* is to make sure that the *first* user returned by getUsers is the user that has the domain restrictions and blank password. A simple way to do this is to name that user User (because the default user folder's getUsers sorts the users by the lexical order of their names). This way the loop above will at most be gone through once for browsers in the domains you mention in that user's domain spec. This will not be the case for anonymous users. They will go through the whole user database for every request and only fall off the end of the userlist once they've tested every user. It will thus be just as slow for them.
RE: [Zope-dev] Domain Login Slowness at certain location
On Wed, 2003-06-18 at 17:38, Andrew R. Halko wrote: Sorry for not understanding and thank you for all the help... Not a problem, although I suspect you're going to be disappointed with the answer. ;-) The domain auth feature was turned off by default because it's fairly severely broken, as you've found out. Unfortunately, you found it and turned it back on, despite our best efforts to prevent you from doing so by not providing a knob for this feature within the Zope ZMI. ;-) How do you create another user folder? You write a Zope Product that allows you to install an alternate acl_users object (e.g. write something like ExUserFolder, UserDB, or LDAPUserFolder that improves the domain auth mode feature). What do you mean by keep users like this around in a different data structure? This would only matter if you were going to write a Zope product. The basic user folder implementation of this feature is too slow. You'd need to create another implementation that is faster by operating against a different arrangement of data in your code. I currently am only using one user that is called Intranet User, is there an easy way to setup so that it just looks at that Users domain and not any other. I am not good enough with Zope to understand a lot of these concepts. No, unfortunately. The only way to do this is to write another user folder or improve the current user folder domain auth implementation in a backwards-compatible way. Sorry, - C ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] 2.7 installation
Two points I neglected to mention earlier: 1. Many thanks to Chris McDonough (and his predecessors) for his work so far, without which, this wouldn't have come up. ;-) 2. I see no reason for Zope to eschew the .py extension for callable scripts, eg. configure.py, zopectl.py, etc. Distributions may choose to wrap these in shell scripts, or strip the extension, but that is a distribution's decision. $(insert impertinent aside about Zope's support for Python Labs and branding.) a. -- Adrian van den Dries [EMAIL PROTECTED] Development team www.dev.flow.com.au FLOW Communications Pty. Ltd. www.flow.com.au ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: FHS, zopectl, #925, Re: [Zope-dev] 2.7 installation
On June 18, Luca - De Whiskey's - De Vitis wrote: For what concern Debian, the intallation home will still be /usr/lib/zope untill python fully comply FHS[1] (http://python.org/sf/588756). I'll probably move it to /usr/lib/python2.1/site-packages in future, but i'm still not sure. Well, if you're going to have a policy shoot-out: http://www.debian.org/doc/packaging-manuals/fhs/fhs-4.4.html /usr/lib includes object files, libraries, and internal binaries that are not intended to be executed directly by users or shell scripts. Applications may use a single subdirectory under /usr/lib. If an application uses a subdirectory, all architecture-dependent data exclusively used by the application should be placed within that subdirectory. For example, the perl5 subdirectory for Perl 5 modules and libraries. Miscellaneous architecture-independent application-specific static files and subdirectories should be placed in /usr/share. http://www.debian.org/doc/packaging-manuals/fhs/fhs-4.7.html The /usr/share hierarchy is for all read-only architecture independent data files. I think most of us would agree that .py(c) files are *libraries* and not *data files*. Data files would be the skeleton instance directory. Perhaps it is a little premature preaching about conformance to the FHS when Zope's package doesn't conform to the Python policy (to which I cannot link because I cannot find a static URL - see /usr/share/doc/python/python-policy.txt.gz). Debian has choosed to be be strictly compliant to FHS[1], including it in the Debian Packaing Policy. As demonstrated, Python complies with the FHS. I see no active or archived serious policy violation bugs relating to Python's FHS compliance. What is the status of the Python Policy? a. -- Adrian van den Dries [EMAIL PROTECTED] Development team www.dev.flow.com.au FLOW Communications Pty. Ltd. www.flow.com.au ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] 2.7 installation
2. I see no reason for Zope to eschew the .py extension for callable scripts, eg. configure.py, zopectl.py, etc. Distributions may choose to wrap these in shell scripts, or strip the extension, but that is a distribution's decision. $(insert impertinent aside about Zope's support for Python Labs and branding.) I'm not sure what you mean by that final remark, but I also like to install scripts with their .py extension. Some at PL disagree though. --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: FHS, zopectl, #925, Re: [Zope-dev] 2.7 installation
On June 18, Chris McDonough wrote: These files needn't be here really. There are two scripts: zopectl and runzope. They are convenience shell scripts that run zopectl.py or runzope.py scripts that live in a software home after setting certain envvars. Whether you run /path/to/zope/instance/zopectl.py start or zopectl.py start /path/to/zope/instance is a 6/half-dozen affair really. Agreed. But see below. Your system is a perfect example of a value-added frontend for zope. ... I'd love to see your zopectl system work with Zope 2.7, and though I likely wouldn't want to package it with Zope, I'd love to see it be able to operate as a front end controller for multiple Zope 2.7 instances. Agreed; we can have a separate zopectl package that is dedicated to managing instances. [Zope] Config-File: /path/to/instance/etc/zope.conf [Instance2] Config-File: /path/to/instance2/etc/zope.conf Thank you, Chris, you answered your own question! This is a nice simple front-end to a multi-instance zope setup. I'd advise against installing Zope library files into site-packages unless you put them in a site-packages subdirectory (like site-packages/zope270 or site-packages/zope271). Otherwise there will be no way to run multiple Zope versions on the same machine sanely because different Zope versions have different libraries. May I respectfully ask why there is so much concern with such complicated setups? Surely a production environment (which is what any Zope distribution should aim for) will standardise on a software version? If the concern is because *developers* want to run multiple Zope instances on multiple Zope versions with multiple Python versions, then I would suggest writing an *alternative* mechanism for developers to mangle their PYTHONPATHs and whatever. That said, if you always manage upgrades via your package distribution mechanism, and you only allowed one version of Zope to be package-installed on the machine at once, perhaps putting the files in site-packages wouldn't be such a big deal. This is doubtless the most common scenario (or it should be). I'm afraid you're going to need to change a lot of things to support Zope 2.7. Please let me know if I can help. Should we move this to debian-python? Servicing the many goals of installation and configuration is very difficult, but I'm pretty confident we can make your life a little easier in the long term given that I understand your requirements. It will also make Zope that much more debian-friendly in the long run. As long as we can distinguish those parts of this exercise that will apply to the Zope distribution from those that should be specific to Debian's package, this shouldn't be too hard. a. -- Adrian van den Dries [EMAIL PROTECTED] Development team www.dev.flow.com.au FLOW Communications Pty. Ltd. www.flow.com.au ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Domain Auth
Does any one know about or have an alternate user folder implementation that has a faster domain auth mode? Andrew ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: FHS, zopectl, #925, Re: [Zope-dev] 2.7 installation
On Wed, 2003-06-18 at 20:07, Adrian van den Dries wrote: Agreed; we can have a separate zopectl package that is dedicated to managing instances. I'm hopeful that Luca agrees. I'd advise against installing Zope library files into site-packages unless you put them in a site-packages subdirectory (like site-packages/zope270 or site-packages/zope271). Otherwise there will be no way to run multiple Zope versions on the same machine sanely because different Zope versions have different libraries. May I respectfully ask why there is so much concern with such complicated setups? Surely a production environment (which is what any Zope distribution should aim for) will standardise on a software version? It's often the case that you want to upgrade to a new Zope (or Python) version on a machine and it's desirable that you be able to run both the older version and the newer version on the same machine during the cutover. For this reason (and others), during production rollouts Zope Corporation actually never uses the system-installed Python on a machine nor does it use binary-packaged Zope distributions. Instead, we install a whole separate tree (typically inside of /home/zope) using CVS and various source buildouts that looks like this: bin/ (control scripts) opt/ (software like Zope, Python, Apache, Zope products, etc.) var/ | |--zope/ (zope instance and data files) | |--apache/ (apache instance and data files) We have make-driven software that creates us a tree via a single command by checking out various version of Python, Zope, etc. from CVS and compiling and installing them. Different versions of Zope and Python, etc. can be installed in opt and we use symlinks to manage versioning. We never install any Zope-related files to a particular Python's site-package directory (even the Pythons we install ourselves) because we like the flexibility of being able to use any Python version we like without needing to copy Zope library files over between Python site-package directories. We just use the stock Zope software home blob and munge the PYTHONPATH as necessary. This works out pretty well in practice because we never have any dependency on any system installed software besides C libraries, CVS, make, and the shell. This makes it easy to deploy Zope to many (possibly divergent) systems without thinking too hard about system incompatibilities and what's installed in a particular Python's site-packages directory. If the concern is because *developers* want to run multiple Zope instances on multiple Zope versions with multiple Python versions, then I would suggest writing an *alternative* mechanism for developers to mangle their PYTHONPATHs and whatever. It does benefit developers, but I don't think it's solely for the benefit of developers. It seems that most large systems install themselves this way; for instance you can install multiple Apache versions on a single system without regard for them stomping on one another. Same for MySQL, Postgres, etc. It seems to be a fairly common pattern. The fact that we depend on Python doesn't seem to make much of a difference from the perspective of someone installing Zope. If Apache depended on Perl, wouldn't necessarily expect my Apache to stop working because I deleted some files from my Perl library directory. That said, if you always manage upgrades via your package distribution mechanism, and you only allowed one version of Zope to be package-installed on the machine at once, perhaps putting the files in site-packages wouldn't be such a big deal. This is doubtless the most common scenario (or it should be). It is when things go right, but when they go wrong, it's fairly limiting to only be able to have a single version of Zope installed on your system. That said, it's really a packaging decision. I'm currently most concerned about making Zope to be easy to install from source. If I can add features to the source install to make it easy for binary packagers to package Zope, I'll do so, but I won't limit the source installer to installing to a single predeclared place. The current Zope source tarball install will continue to allow you to install multiple Zope software homes on your system without regard to the Python you use to invoke them. The binary packaging scheme for a particular distribution is up to the packager. We can probably provide support in the setup.py file for installing libraries to site-packages to help binary distributions do so if they choose. I don't think it's a particularly good idea, but I'm not in charge of those distributions either, so my opinion shouldn't count for much. ;-) I'm afraid you're going to need to change a lot of things to support Zope 2.7. Please let me know if I can help. Should we move this to debian-python? Just tell me where to go and I'll go there. ;-) Servicing the many goals of installation and configuration is very difficult, but I'm
Re: [Zope-dev] 2.7 installation
On Wed, 2003-06-18 at 18:48, Adrian van den Dries wrote: Two points I neglected to mention earlier: 1. Many thanks to Chris McDonough (and his predecessors) for his work so far, without which, this wouldn't have come up. ;-) Thanks! But I can't take too much credit. You should probably thank Fred Drake too; he implemented ZConfig. And Matt Behrens, he wrote most of the setup.py and took the initial cut at overhauling startup. And Shane, he helped Matt a lot, I think. And Evan Simpson, for his work on the original zctl. And Guido, for zdctl. And Richard Jones, for making mkzeoinstance. And Zope Corporation, for paying the ZCers for much of the time required to do this. And so on. ;-) 2. I see no reason for Zope to eschew the .py extension for callable scripts, eg. configure.py, zopectl.py, etc. Distributions may choose to wrap these in shell scripts, or strip the extension, but that is a distribution's decision. $(insert impertinent aside about Zope's support for Python Labs and branding.) I think the only Python scripts that don't have a .py extension exist in the software home. They are the 'mkzopeinstance', 'mkzeoinstance', and 'zconfig' scripts. I think these should have the extension. This would also make it possible to run them on Windows without specifying an interpreter (Windows shells don't support hash-bangs). There are no Python scripts in the instance home that don't possess the extension. - C ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: FHS, zopectl, #925, Re: [Zope-dev] 2.7 installation
On June 18, Chris McDonough wrote: (snip interesting insight into ZC's deployments) This is doubtless the most common scenario (or it should be). It is when things go right, but when they go wrong, it's fairly limiting to only be able to have a single version of Zope installed on your system. OK, consider these scenarios. Source install - simplest:: ./configure.py # PREFIX defaults to /usr/local/zope on UNIX # probably C:\\Progra~1\\Zope on Windows make; sudo make install /usr/local/zope/bin/mkzopeinstance.py /var/zope/inst1 /var/zope/inst1/bin/zopectl.py start Looks just like before! Distribution install - most common:: ./configure.py --prefix=/usr \ --skel=/usr/share/zope/skel \ --doc=/usr/share/zope/doc mkzopeinstance.py /var/lib/zope/default ln -s /var/lib/zope/default/etc /etc/zope/default echo -e '[default]\n/var/lib/zope/default' /etc/zopectl.conf zopectl.py start default All the above is invoked by ``apt-get install zope``, and the package can use a /etc/init.d/zope to loop through all instances. Multiple pythons, zopes, instances - most complex:: cd Zope-2.7.1 python2.1 configure.py --prefix=/opt/zope271-python21 # ... python2.1 configure.py clean python2.2 configure.py --prefix=/opt/zope271-python22 # ... cd ../Zope-2.7.2 python2.1 configure.py --prefix=/opt/zope272-python21 # ... python2.2 configure.py clean python2.2 configure.py --prefix=/opt/zope272-python22 Then you permute these with: python2.1 /opt/zope271-python21/bin/mkzopeinstance.py \ /var/zope/zope271-python21-instance1 python2.2 /opt/zope271-python22/bin/mkzopeinstance.py \ /var/zope/zope271-python22-instance1 # etc. And you have an installation with all permutations of multiple Pythons, multiple Zopes and multiple instances. Does this alleviate your concerns? ;-) a. -- Adrian van den Dries [EMAIL PROTECTED] Development team www.dev.flow.com.au FLOW Communications Pty. Ltd. www.flow.com.au ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: FHS, zopectl, #925, Re: [Zope-dev] 2.7 installation
On June 19, Adrian van den Dries wrote: Distribution install - most common:: ... Multiple pythons, zopes, instances - most complex:: Note that these aren't mutually exclusive: the porpoise of /usr/local is to allow a site-local hierarchy. That is, the *system* only has one version of the software (and the *system* should only *ever* have one version of the software) and locally-installed packages go in /usr/local, per FHS. The decision to install multiple versions of a package is always a site-local decision, and therefore correctly belongs in /usr/local. I suppose there may be a religious debate a-brewing about whether Zope should install as a Python package into /usr/lib/pythonX.Y/site-packages, or its own package with its own PYTHONPATH. My argument in this debate goes a little like this: A *library* should be installed as a library. Most of Zope's source code is libraries. Zope should install these libraries (packages) according to the regime dictated by the installation of Python that will be used to run Zope. That is, if you are using a distribution-supplied Python to run Zope, you should install into that Python's --prefix. If you are using a custom Python, use whatever regime matches that Python. But remember these are all *customisations*; the defaults all point to the simplest scenario presented earlier. a. -- Adrian van den Dries [EMAIL PROTECTED] Development team www.dev.flow.com.au FLOW Communications Pty. Ltd. www.flow.com.au ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
