Re: [Zope-dev] Two small ZPT suggestions
On July 17, Toby Sargeant wrote: table tal:repeat=row rows tal:block tal:define=casevar row/rowtype tr tal:condition=python:casevar='group'.../tr tr tal:condition=python:casevar='user'.../tr tr tal:condition=python:casevar='files'.../tr /tal:block /table Why bother with the tal:define? Just: table tal:repeat=row rows tr tal:condition=python:row.rowtype=='group'.../tr tr tal:condition=python:row.rowtype=='user.../tr tr tal:condition=python:row.rowtype=='files.../tr /table which is just a direct translation of the corresponding Python: for row in rows: if row.rowtype=='group': # etc 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] ZEO.auth missing from setup.py
ClientStorage imports auth, which is not installed. Index: setup.py === RCS file: /cvs-repository/Zope/setup.py,v retrieving revision 1.30 diff -u -r1.30 setup.py --- setup.py13 Jun 2003 06:27:18 - 1.30 +++ setup.py23 Jun 2003 05:15:24 - @@ -655,7 +655,7 @@ name='ZEO', author=AUTHOR, -packages=['ZEO', 'ZEO.tests', 'ZEO.zrpc'], +packages=['ZEO', 'ZEO.auth', 'ZEO.tests', 'ZEO.zrpc'], data_files=[['ZEO', ['ZEO/*.txt', 'ZEO/*.xml']]], ) 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
On June 18, Chris McDonough wrote: And Guido, for zdctl. Will Zope use zdctl? It would be cool to have the same framework used to control individual instances (Zope or ZEO), and zopectl can become an external zdaemon instance manager (I'll call it z*ctl). Zope and ZEO simply provide start hooks for zdaemon. So, you configure a ZEO instance and a Zope instance, add those instances to a global configuration file, and ask z*ctl to start the instances (if you have z*ctl) or you start them individually with zdctl.py. Hrm, applications that are really plugins to a generalised daemon application. That sounds familiar. ;-) 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] Zope 2, Zope 3, now, (was funky side-effects, possible bug in HTTPRequest.py)
On June 20, Jamie Heilman wrote: and I don't like surprises Zope 2 is probably not the most suitable choice, then. ;-) More seriously, though, my colleagues and I will often find a few of these sorts of *surprising* things in Zope 2 every week. It's really quite demoralising building for Zope 2 when it feels like such a dead effort, with many (seemingly rather deep) problems in Zope 2 that nobody has either the time or motivation to fix, because all the interesting work is happening on Zope 3. Are there, or will there be, any guidelines for developing for Zope 2 with the view to migrating to Zope 3? And given the logevity of Zope 2 suggested by the roadmap, will there be any effort to clean up the Zope 2 code in the medium/long term? FWIW I use Zope for its webblication features over its CMF features, which is why Zope 3 is far more interesting than most of the work happening around Zope 2. I understand that things are moving quite well with Zope 3 but the current state of affairs does put places like ours, with a commitment to producing a large, complicated Zope 2 extranet/portal in a number of months, in a confusing headspace. 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, PieterB wrote: Could that make-driven software be made public? I'm currently trying to create similar Makefiles (for a new FreeBSD zope port) and would be interested in using ZC files. This sort of stuff is almost definitely deployment-specific (and quite likely ZC proprietary property - that is much of their revenue!) How do those files compare to the buildscript: http://cvs.zope.org/NZO_SiteLayout/buildout_zope_sandbox?cvsroot=Zope.org Jeebers, someone sure has an aversion to shell functions! ;-) 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, Chris McDonough wrote: On Wed, 2003-06-18 at 23:13, Adrian van den Dries wrote: python2.1 configure.py --prefix=/opt/zope271-python21 (FWIW, configure is a shell script.) Yes, I knew that. I used the .py extension for all the scripts to be consistent, according to my earlier point to this end. It too is just a shell wrapper to find the correct python and palm off the remaining options to inst/configure.py. Why not avoid that altogether and let the user supply the correct python? Ie, instead of:: ./configure --with-python=/usr/bin/python3.2 --other --options you call:: /usr/bin/python3.2 configure.py --other --options Which it pretty much does, anyway. I also see things like this: # Up to six acceptable python versions are allowed. Why six? Where is it enforced? Are you implying that the stuff that currently goes into software_home/lib/python would be installed to the site-package directory of the Python that was used to invoke the installer? If so, the subsequent invocations above of: No, I'm saying that the systems should be allowed (or even encouraged) to do this. We already have sys.path and namespaces. In a 1:1 python:zope environment, this should be enough to identify the Zope packages. Hence installing into python's module path. For multiple-version environments, you need --home (see below). cd Zope-2.7.1 python2.1 configure.py --prefix=/opt/zope271-python21 make; make install cd ../Zope-2.7.2 python2.1 configure.py --prefix=/opt/zope272-python21 make; make install ... would cause the Zope 2.7.1 libraries to be stomped by the Zope 2.7.2 libraries. No, because --prefix just told configure.py to install *everything* in that location. If you want to alias this option to --home, that would probably make this clearer, but I don't think it's different in function. If you mean that the libraries are installed into /opt/zope27X-python21/lib/python, there's no problem and nothing about the installer needs to be changed. Aye. So, in any case, given that the ZC source tarball installer will not attempt to manage multiple instances (we'll leave that to Luca) Aye. here are the requirements I've gathered so far: - Add a --doc flag to configure - Add a --skel flag to configure (is this a common pattern?) I think so. But consider using the Make variables suggested earlier, so that distributions may customise the make step: ./configure --options --supplied --by --zope make SITE=local SPECIFIC=options - Make it possible to install Zope libraries into the site-packages directory of the Python that invokes Zope's setup.py instead of into software_home/lib/python. As long as each of the top-level Zope directories in the --home (bin, doc, lib, skel) can be individually tweaked, either in the configure.py or the makefile, I think we win both ways. Am I missing anything? Apart from my personal desire to see the shell scripts deprecated, nope. ;-) I think that's covered everything that concerns Zope itself, and the rest gets palmed off to zopectl and packagers. 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, Chris McDonough wrote:
On Thu, 2003-06-19 at 20:24, Adrian van den Dries wrote:
Why not avoid that altogether and let the user supply the
correct python?
This is somewhat of a style choice
OK, ZC's call. ;-)
Well, as we all know, shell scripting kinda blows. There is no way that
I know of to portably use an array in shell, and I wanted to eventually
make it possible to use something other than bash to run the configure
script (bash has arrays, but I'm not sure if bourne shell does).
You may be interested in Kenneth Almquist's ash (aka dash in Debian):
Description: The Debian Almquist Shell
dash is a POSIX compliant shell that is much smaller than bash.
We take advantage of that by making it the shell on the installation
root floppy, where space is at a premium.
.
It can be usefully installed as /bin/sh (because it executes scripts
somewhat faster than bash), or as the default shell either of root
or of a second user with a userid of 0 (because it depends on fewer
libraries, and is therefore less likely to be affected by an upgrade
problem or a disk failure). It is also useful for checking that a
script uses only POSIX syntax.
You're suggesting that --prefix be changed to --home.
...
You're suggesting that specifying a --home implies that libraries will
be installed to $home/lib/python.
This is where I get a little confused. How does a user signify that
Zope libraries should get installed into the Python site-package
directory? What happens if --home is left unspecified? Is the
--prefix option still around? If so, what does it do? Can you give
an example of a configure command that would imply that Zope libraries
get installed to site-packages?
Erm, yes. I originally wanted --home and --prefix aliased, but I've
changed my mind. It should mirror the behaviour of the same options
to the distutils' install target.
With the distutils, ``--home`` is version-agnostic (installs package
``foo`` into ``$HOME/lib/python/foo/``) and ``--prefix`` is
version-aware (installs into ``$PREFIX/lib/pythonX.Y/site-packages``).
``inst/Makefile.in`` could probably be updated to do a --prefix install
if $(PREFIX) is defined, else it defaults to a --home install.
(Mockups)
# the next commands are all equivalent
# and produce the install target
# ``python setup.py --home=/usr/local/zope``
python inst/configure.py --home=/usr/local/zope
./configure --home=/usr/local/zope
./configure
# the next command produces the install target
# ``python setup.py --prefix=/usr/local``
# which installs packages to /usr/local/lib/python2.2/site-packages
python inst/configure.py --prefix=/usr/local
I think it is possible to tweak many things now via make -e after
examination of the makefile.
OK, that is what the Deb should do.
Well, if you ignore the shell scripts, I think we're ok, then!
Peaches!
...
(Couple of hours later).
OK, attached is a patch to inst/Makefile.in and inst/configure.py that
distinguishes --home and --prefix parameters and passes them onto the
distutils. But for some reason, there is still no difference between
--prefix and --home, even though it's passing those options to the
distutils. I suspect it might have something to do with this exerpt
from setup.py::
# We create a custom install scheme that works the same way on all
# platforms. We do this in order to prevent distutils from trying to
# guess where to put our files on a per-platform basis.
ZOPE_INSTALL_SCHEME = {
'purelib': '$base/lib/python',
'platlib': '$base/lib/python',
'headers': '$base/lib/python',
'scripts': '$base/bin',
'data' : '$base/lib/python',
}
That looks a little evil to me.
a.
--
Adrian van den Dries [EMAIL PROTECTED]
Development team www.dev.flow.com.au
FLOW Communications Pty. Ltd. www.flow.com.au
Index: doc/INSTALL.txt
===
RCS file: /var/lib/cvs/flowcom/Zope/dist/doc/INSTALL.txt,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 INSTALL.txt
--- doc/INSTALL.txt 18 Jun 2003 02:27:46 - 1.1.1.1
+++ doc/INSTALL.txt 20 Jun 2003 05:03:29 -
@@ -13,7 +13,7 @@
Recommendations
- - You are recommended to build and install Zope as a non-root user.
+ - We recommend you build and install Zope as a non-root user.
Building Zope
@@ -23,8 +23,25 @@
./configure --prefix=/where/to/install/zope
make
- If you do not specify a '--prefix' option, during a later step, Zope
- will be installed into a default location.
+ or
+
+./configure --home=/where/to/install/zope
+make
+
+ If you do not specify the '--home' or '--prefix' options, during a
+ later step, Zope will be installed into a default location.
+
+ --prefix differs from --home by installing Python packages into
+ $PREFIX/lib/pythonX.Y/site-packages, where --home installs the
+ packages
[Zope-dev] 2.7 installation
provide the ``-l`` option to override the log location Debian packages ZEO and the ZODB similarly, and ZEO and Zope depend on the ZODB. 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
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: 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 )
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 )
Re: [Zope-dev] oh boy [id,getId() madness]
On June 11, Stefan H. Holek wrote: This is definitely possible. You probably have a faulty factory method. In Zope, construction is a two step process that looks something like def addSomething(self, id, title=''): ob = Something(id, title) self._setObject(id, ob) That's why this should be: def addSomething(self, id): ob = Something(id) self._setObject(ob.getId(), ob) But I notice nobody seems to do this. 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] ZPublisher.Client and encrypted passwords
On March 26, Danny W. Adair wrote: - use a different approach to call the other server (like passing a copy of the current Auth header or something...) BaseRequest._auth holds the original auth header, so you can just forward it along. 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] ZPublisher.Client and encrypted passwords
On March 26, Danny W. Adair wrote:
Thanks. How would I do that?
ZPublisher.Client.call() is very convenient but only takes
url,username,pwd...
import base64
user, pass = base64.decodestring(req._auth.split(' ')[1]).split(':')
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] Proposed installation changes for review
On March 20, Chris McDonough wrote: 'make install' should not create files in the source tree as long as you've run 'make' beforehand. Which files does it create? These directories and everything below them: ./build ./lib/python/build/lib ./lib/python/build/lib.linux-i686-2.2 ./lib/python/build/scripts-2.2 Perhaps the build target should do a 'setup.py build' rather than 'setup.py build_ext'? 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] Proposed installation changes for review
Small problem. The 'make install' step creates files in the source tree. It probably shouldn't do this, because if you want to do this as root (sudo make install to install under /usr/local, say), these file are created as root. This is impolite more than anything else. The build and install targets just call setup.py, so is this a bug in the distutils? 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] Proposed installation changes for review
On March 19, Fred L. Drake, Jr. wrote: How important is it to support out-of-place builds? http://dev.zope.org/Wikis/DevSite/Proposals/InstallationAndConfiguration configure; make; make install source package installation process and some form of INSTANCE_HOME installation thereafter. INSTANCE_HOME setup becomes the default kind of installation. Is this still current? 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] Proposed installation changes for review
On March 19, Fred L. Drake, Jr. wrote: (The Quick Start section uses an abbreviated procedure that creates an instance home in the source directory.) It calls configure with --prefix=/where/to/install/zope which is then unused. 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] Modification Help
On March 17, [EMAIL PROTECTED] wrote: I am trying to develop a program that generates a top-level folder within zope and then has one of its functions called to give permission to access the folder, as opposed to using the standard Zope permission system. As I understand it the only way to do this is to modify the core zope software. Like everything else in Zope, assigning permissions and roles can be done programmatically. So, if you want to dynamically grant a role a particular permission (or conversely, grant a user a role), you could do it with a Python script that calls container.manage_permission or container.manage_role as appropriate, and give that script the Manager proxy role, ensuring it is only callable by appropriate users. But I strongly suspect there is a better way to solve your problem, probably with local roles. If you describe what you're really trying to achieve, perhaps we can help you achieve it in a more Zopish way. When you say top-level folder, do you mean the root folder (which is not really a folder), or one level down? 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] Proposed installation changes for review
On March 10, Fred L. Drake, Jr. wrote: I'm not sure what you mean; it sounds like you're looking for either DBTab-style mounts or something different. Please describe the configuration so we can be sure that there's some way to support it. Yes, DBTab-style mounts are what I'm looking for. Shane says, Hopefully, Zope 2.7 will integrate DBTab's functionality. I took that at face value and assumed the rest of the crowd knew about it. DBTab's only limitation is that it has hard-coded storage types (most notably lacking is DirectoryStorage). The way I see this resolved is that DBTab knows nothing about storage types, but instead provides a mechanism for each storage to declare its configuration to ZConfig. I'm guessing the way to do that is to provide a ZConfig schema for each storage that declares what it needs configured, and a mount-point just needs a valid storage directive. Is this possible? I would also like to see the mounting mechanism work outside of Zope, so that you can partition a standalone ZODB application. That is outside the immediate scope of this thread, but something perhaps to keep in mind. 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] How (in)secure is Zope?
On March 13, Lennart Regebro wrote: 2. Protecting yourself from packet snooping: Zope doesn't have any encryption built-in, SSL needs external software to implement fro example. In this sense Zope can be MADE secure with some work, but is not secure at all out of the box. Speaking of which, does anyone have any strategies for doing a combination HTTP/HTTP-S setup, ie, where anonymous requests are HTTP, and all authenticated requests are encrypted? Specifically, Zope has no way of knowing beforehand that access to a resource will throw an Unauthorized error, and when it does, it just sends a WWW-Authenticate header, and the browser retries the request with the supplied header. We want to enforce that passwords are never solicited without SSL. One way is probably to use CookieCrumbler and hack it to rewrite came_from so s/^http/https/. Is there a way that doesn't require hacking? 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] How (in)secure is Zope?
On March 13, Christian Tismer wrote: please excuse my ignorance, but I am asked from time to time how secure or insecure Zope actually is, and I always have to say that I actually don't know. How secure is your wallet? You will never answer this until you define what you mean by security, and what you are securing *against*. Zope is perfectly secure or some uses, and perfectly insecure for others. For example, for safe delegation of responsibility within a web application, in a trusted environment, Zope is secure. However, as a mission-critical service exposed to the internet, it is wide-open. 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] Zope Template Newbie question
On March 11, David Cain wrote: And it does pull the file in, but it quotes the entire HTML in that file so that my browser doesn't interpret it: http://www.zope.org/Documentation/Books/ZopeBook/2_6Edition/AdvZPT.stx Normally, the tal:replace and tal:content statements quote HTML tags and entities in the text that they insert. For instance, the the character is quoted to amp;lt;. If you actually want to insert unquoted text, you need to precede the expression with the structure keyword. 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: Security internals, was Re: [Zope-dev] LOTS of roles?
On March 5, Paul Winkler wrote: * more coupling Yes. * performance hit Yes. * one more detail to pay attention to Yes. OTOH, doing the magic in user.allowed() would mean I'd only need one special UserFolder instance at the top of the hierarchy, and then everything else Just Works regardless of what folderish thing it is and all my LDAP-related code would be in this UserFolder class. am i overlooking something? No, I think you've distilled the issue quite concisely. (/me revisits LDAPUserFolder) Looks like the work is already done for you anyway: allowed() and friends check if the context has an attribute acl_satellite, and queries it for any additional roles, and it even keeps a cache. You could probably just customise the Folder to automagically place a satellite object in it. Or otherwise borrow the logic to do what you need. Huzzah open-source software! 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: Security internals, was Re: [Zope-dev] LOTS of roles?
On March 5, Paul Winkler wrote:
I've been trying to understand how to implement dynamic local roles,
Customise the Folder class and override __ac_local_roles__ with a
method that returns a dictionary mapping users to roles for that object:
{user: [local,roles],
...}
* User.BasicUser.allowed() is the only method that
has a short-circuited version of getRolesInContext in it
This is correct. But if you implement dynamic local roles per above,
you don't need to do this. You were right in an earlier post when you
said that when people said validate() they meant allowed(). (This is
what happens when you don't have well-defined naming standards!)
which calls ZopeSecurityPolicy.validate()
This does the work of validating access to object *after* the object
has been allowed(). ie, to figure out permissions on callables to
avoid a trojan attack. This is not the validate() you are looking
for.
One more thing: AFAICT, ZopeSecurityPolicy.checkPermission()
and User.has_permission() are purely for informational purposes -
e.g. you can call them in your app to find out something,
but they are not used by the internals to grant or deny access.
True?
True.
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] How to trigger Zope externally (mail)
On February 26, Ross Boylan wrote: 1. Incoming mail goes to a pipe, which is a program that processes the message. Use curl or another HTTP client to POST the message to a Zope script. This seems to be the idiomatic way, because authentication occurs at the request level in the publisher. zope is tickled via http: with the name of the file/pipe, and processes it from there. Don't bother with named pipes; just pass the data with a POST. HTH, 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] Multiple author and reviewer roles in Zope CMF
On February 12, Paul Winkler wrote: While we're on the subject - are local roles acquired in subfolders? Yes, to the point that globals roles are actually redundant, but serve as an optimisation of a local role at the same level as your userfolder. 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] [PATCH] Forking daemon in debug mode, and new start scripts
On January 21, Chris McDonough wrote: It unfortunately means lots of things, all of which are implicitly twisted together in a huge mess I wasn't going to say it. ;-) It's that... and, unfortunately, god knows what else. To find out for sure, we'd need to audit the codebase (looking mostly for Z_DEBUG_MODE and __debug__). I'd like to address these problems for Zope 2.7, but I doubt it's going to be possible in the short term. Hrm, a refactor, eh? adriand@pita:~/Zope-2.6.0b1-src$ egrep -Iir 'principia|bobo' * | wc -l 345 ;-) 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://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] [PATCH] Forking daemon in debug mode, and new start scripts
I understand zdaemon is going away soon, but here's a small patch to
Daemon.py to fork if it finds an EVENT_LOG_FILE.
Also included is my start/stop scripts (for Unix), and a
custom_zodb.py which uses an environment variable ZODB_STORAGE to
determine what storage to use. This allows me to use the same
codebase for my ZEO client Zopes and local FileStorage Zopes, simply
by changing a /etc/defaults style config file, also included.
The scripts in their current form may not be entirely suitable, but
they provide a point of departure for a slightly better startup
mechanism.
The non-detaching daemon, however, is just plain annoying. On Unix
you can always tail the logfile for the same effect.
a.
--
Adrian van den Dries [EMAIL PROTECTED]
Development team www.dev.flow.com.au
FLOW Communications Pty. Ltd. www.flow.com.au
--- Daemon.py.orig 2002-08-15 08:12:52.0 +1000
+++ Daemon.py 2003-01-20 15:59:45.0 +1100
@@ -29,7 +29,8 @@
os.environ['ZDAEMON_MANAGED']='TRUE'
-if not os.environ.has_key('Z_DEBUG_MODE'):
+if not (os.environ.has_key('Z_DEBUG_MODE') and
+not os.environ.has_key('EVENT_LOG_FILE')):
detach() # detach from the controlling terminal
while 1:
config.sh
Description: Bourne shell script
#!/bin/sh
. $(dirname $0)/config.sh
export ZOPE_HOME SOFTWARE_HOME INSTANCE_HOME CLIENT_HOME ZODB_STORAGE
export EVENT_LOG_FILE EVENT_LOG_SEVERITY Z_DEBUG_MODE
cd $ZOPE_HOME
umask 077
if [ $MONITOR_PORT ]; then
MONITOR=-m $MONITOR_PORT
fi
if [ $WEBDAV_PORT ]; then
WEBDAV=-W $WEBDAV_PORT
fi
if [ $HTTP_PORT ]; then
HTTP=-w $HTTP_PORT
fi
if [ $FTP_PORT ]; then
FTP=-f $FTP_PORT
fi
exec python2.1 $ZOPE_HOME/z2.py -X $HTTP $FTP $WEBDAV $MONITOR $@
#! /bin/sh
. $(dirname $0)/config.sh
kill $(cat $ZOPE_HOME/var/Z2.pid)
import os
ZODB_STORAGE = os.environ.get('ZODB_STORAGE', '')
if not ZODB_STORAGE:
raise NoStorageInEnvironmentError
try:
stg = eval(ZODB_STORAGE)
except:
stg = ZODB_STORAGE
if type(stg) is type(''):
from ZODB.FileStorage import FileStorage
Storage = FileStorage(stg)
else:
from ZEO.ClientStorage import ClientStorage
Storage = ClientStorage(stg, name='ZEO server on %s' % stg[0])
