Specify a domain and leave the password for a user blank
Hi, In Zope 2.4 or older versions when a user is created, if you specify a domain and leave the password for a user blank, then anyone from the permitted domains automatically gets the user's roles without having to log in. However, it is not possible in Zope 2.7. I have created a user specifying a domain and leave the password for this user blank, and although I am in the domain, I have to log in. Anybody help me about it ? How can I create a user, specifying a domain, and if the user is in the domain does not have to log in? Thanks.- ----- Original Message ----- From: <zope-dev-request@zope.org> To: <zope-dev@zope.org> Sent: Tuesday, March 09, 2004 12:36 PM Subject: Zope-Dev Digest, Vol 8, Issue 15
Send Zope-Dev mailing list submissions to zope-dev@zope.org
To subscribe or unsubscribe via the World Wide Web, visit http://mail.zope.org/mailman/listinfo/zope-dev or, via email, send a message with subject or body 'help' to zope-dev-request@zope.org
You can reach the person managing the list at zope-dev-owner@zope.org
When replying, please edit your Subject line so it is more specific than "Re: Contents of Zope-Dev digest..."
Today's Topics:
1. Re: Re: Unexpected Behaviour iterating over catalog search... (Dieter Maurer) 2. Zopeservice and sitecustomize (Sake) 3. Re: Zopeservice and sitecustomize (Chris McDonough) 4. RE: Zopeservice and sitecustomize (Tim Peters) 5. RE: Zopeservice and sitecustomize (Tim Peters) 6. Re: Re: Unexpected Behaviour iterating over catalog search... (Chris Withers) 7. Re: [ZODB-Dev] Re: BTrees strangeness (was [Zope-dev] Zope 2.X BIG Session problems - blocker - our site dies - need help of experience Zope developer, please) (Alex V. Koval)
----------------------------------------------------------------------
Message: 1 Date: Mon, 8 Mar 2004 20:05:04 +0100 From: Dieter Maurer <dieter@handshake.de> Subject: Re: [Zope-dev] Re: Unexpected Behaviour iterating over catalog search... To: Jean Jordaan <jean@upfrontsystems.co.za> Cc: zope-dev@zope.org Message-ID: <16460.50144.170406.811279@gargle.gargle.HOWL> Content-Type: text/plain; charset=us-ascii
Jean Jordaan wrote at 2004-3-8 16:33 +0200:
Surely the thing returned by a Catalog search should be immutable?
Nope, it is "lazy"; immutability would require "realizing" it first, which would be prohibitively expensive in many cases.
Yes .. thing is, wrapping with list() or tuple() will therefore also be prohibitive in those cases,
When you want to uncatalog everything, "tuple"ing the result should not be a problem.
Otherwise, a standard approach is to remember the objects you want to delete in a standard list and iterate over this list in a separate loop (outside the first one).
-- Dieter
------------------------------
Message: 2 Date: Tue, 09 Mar 2004 08:54:54 +0700 From: Sake <sakesun@boonthavorn.com> Subject: [Zope-dev] Zopeservice and sitecustomize To: zope-dev@zope.org Message-ID: <404D23EE.1080702@boonthavorn.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Hi,
I have Zope and Activestate Python installed together in the same win-xp machine. Everything works fine until I've learned that I can put "sys.setdefaultencoding('cp874')" into sitecustomize.py to accomodate my native language coding. Since I do that, my Zope 2.7.0 service can no longer start. I can start it manually from "runzope.bat", but it never start through the windows system service. A full day investigation reveal that the trouble cause by the missing of the '<SOFTWARE_HOME>\lib\python' in the system environment's "PYTHONPATH". The "runzope.bat" set that up before then execution of "Zope.Startup.run.py", hence it run fine. But "zopeservice.py" rely on the "<SOFTWARE_HOME>\bin\Lib\site-packages\sitecustomize.py" to set up the correct "PYTHONPATH". Here is the code inside Zope's sitecustomize.py
""" Add Zope packages in Windows binary distro to sys.path automagically """ import sys import os try: sp = __file__ except: sp = None if sp: dn = os.path.dirname swhome = os.path.join(dn(dn(dn(dn(sp)))), 'lib', 'python') if os.path.exists(swhome): sys.path.insert(0, swhome)
Unluckily, this sitecustomize.py is now masked with my sitecustomize.py inside Activestate's site-package directory, which actually get loaded by Zope via the Python registry load path (HKEY_LOCAL_MACHINE\SOFTWARE\Python\PythonCore\2.3\PythonPath) instead of the expected one.
I don't think setting up PYTHONPATH inside sitecustomize.py is a good idea. Better keep this mechanism for site specific problems. I'd rather insert a line into zopeservice.py like this.
import os.path from os.path import dirname as dn import sys
# these are replacements from mkzopeinstance PYTHONW = r'C:\Zope-2.7.0\bin\pythonw.exe' SOFTWARE_HOME=r'C:\Zope-2.7.0\lib\python' INSTANCE_HOME = r'C:\Zope-MIB' ZOPE_HOME = r'C:\Zope-2.7.0'
ZOPE_RUN = r'%s\Zope\Startup\run.py' % SOFTWARE_HOME CONFIG_FILE= os.path.join(INSTANCE_HOME, 'etc', 'zope.conf') PYTHONSERVICE_EXE=r'%s\bin\PythonService.exe' % ZOPE_HOME
sys.path.insert(0, SOFTWARE_HOME) os.environ['PYTHONPATH'] = SOFTWARE_HOME <---------------- inserted line
from nt_svcutils.service import Service
servicename = 'Zope_%s' % str(hash(INSTANCE_HOME))
class InstanceService(Service): start_cmd = '"%s" "%s" -C "%s"' % (PYTHONW, ZOPE_RUN, CONFIG_FILE) _svc_name_ = servicename _svc_display_name_ = 'Zope instance at %s' % INSTANCE_HOME _exe_name_ = PYTHONSERVICE_EXE
if __name__ == '__main__': import win32serviceutil win32serviceutil.HandleCommandLine(InstanceService)
This is much more palatable in my opinion.
------------------------------
Message: 3 Date: Mon, 08 Mar 2004 22:14:10 -0500 From: Chris McDonough <chrism@plope.com> Subject: Re: [Zope-dev] Zopeservice and sitecustomize To: Sake <sakesun@boonthavorn.com> Cc: zope-dev@zope.org Message-ID: <1078802050.12387.38.camel@athlon> Content-Type: text/plain
On Mon, 2004-03-08 at 20:54, Sake wrote:
Everything works fine until I've learned that I can put "sys.setdefaultencoding('cp874')" into sitecustomize.py
I assume you created a new sitecustomize.py to hold this in your activestate Python's library directory, then?
I can start it manually from "runzope.bat", but it never start through the windows system service. A full day investigation reveal that the trouble cause by the missing of the '<SOFTWARE_HOME>\lib\python' in the system environment's "PYTHONPATH". The "runzope.bat" set that up before then execution of "Zope.Startup.run.py", hence it run fine. But "zopeservice.py" rely on the "<SOFTWARE_HOME>\bin\Lib\site-packages\sitecustomize.py" to set up the correct "PYTHONPATH". Here is the code inside Zope's sitecustomize.py
This was put here because in my tests I could not make Python recognize the "right" set of paths by setting an environment variable in the zopeservice script.
As you probably noticed, Zope does not run in the same Python interpreter instance as the one that zopeservice.py runs under. zopeservice.py instead turns around and invokes another Python interpreter to actually do the running of Zope itself (that's what "start_cmd" is set for). Worse, the windows Service code actually doesn't invoke zopeservice.py directly; it is run as a side effect of the PythonService.exe executable being run. Setting a PYTHONPATH via os.environ in zopeservice was not doing the trick for me (at least on Win2K); why was unclear, although I think it was because the environment being modified by setting os.environ within zopeservice is not carried over to child processes. A batch file couldn't be used as the target for the service because the Windows shell doesn't keep track of child processes in the same way UNIX does: child processes aren't killed when their parents are and there is no way to 'exec' another command from a Windows batch file.
Unluckily, this sitecustomize.py is now masked with my sitecustomize.py inside Activestate's site-package directory, which actually get loaded by Zope via the Python registry load path (HKEY_LOCAL_MACHINE\SOFTWARE\Python\PythonCore\2.3\PythonPath) instead of the expected one.
I don't think I understand why this happens. That's not surprising. There is some complicated DWIM that Windows Python does when it starts up to try to guess what should go on sys.path and in what order. Tim Peters dug up a comment in Python's code and sent it to me a bit ago about why this happens. It can be found in Python's PC/getpathp.c file:
PATH RULES FOR WINDOWS: This describes how sys.path is formed on Windows. It describes the functionality, not the implementation (ie, the order in which these are actually fetched is different)
* Python always adds an empty entry at the start, which corresponds to the current directory.
* If the PYTHONPATH env. var. exists, it's entries are added next.
* We look in the registry for "application paths" - that is, sub-keys under the main PythonPath registry key. These are added next (the order of sub-key processing is undefined). HKEY_CURRENT_USER is searched and added first. HKEY_LOCAL_MACHINE is searched and added next. (Note that all known installers only use HKLM, so HKCU is typically empty)
* We attempt to locate the "Python Home" - if the PYTHONHOME env var is set, we believe it. Otherwise, we use the path of our host .EXE's to try and locate our "landmark" (lib\\os.py) and deduce our home. - If we DO have a Python Home: The relevant sub-directories (Lib, plat-win, lib-tk, etc) are based on the Python Home - If we DO NOT have a Python Home, the core Python Path is loaded from the registry. This is the main PythonPath key, and both HKLM and HKCU are combined to form the path)
* Iff - we can not locate the Python Home, have not had a PYTHONPATH specified, and can't locate any Registry entries (ie, we have _nothing_ we can assume is a good path), a default path with relative entries is used (eg. .\Lib;.\plat-win, etc)
The end result of all this is: * When running python.exe, or any other .exe in the main Python directory (either an installed version, or directly from the PCbuild directory), the core path is deduced, and the core paths in the registry are ignored. Other "application paths" in the registry are always read.
* When Python is hosted in another exe (different directory, embedded via COM, etc), the Python Home will not be deduced, so the core path from the registry is used. Other "application paths" in the registry are always read.
* If Python can't find its home and there is no registry (eg, frozen exe, some very strange installation setup) you get a path with some default, but relative, paths.
From this (and without a Windows machine in front of me), I can't really make any sense out of why your Activestate Python's sitecustomize.py is being found instead of Zope's Python sitecustomize.py if you're running Zope using the Zope Python install. I suspect it may be because of placement of your sitecustomize.py file and the rule named "We look in the registry for "application paths"", but that's a guess.
I don't think setting up PYTHONPATH inside sitecustomize.py is a good idea. Better keep this mechanism for site specific problems. I'd rather insert a line into zopeservice.py like this.
import os.path from os.path import dirname as dn import sys
# these are replacements from mkzopeinstance PYTHONW = r'C:\Zope-2.7.0\bin\pythonw.exe' SOFTWARE_HOME=r'C:\Zope-2.7.0\lib\python' INSTANCE_HOME = r'C:\Zope-MIB' ZOPE_HOME = r'C:\Zope-2.7.0'
ZOPE_RUN = r'%s\Zope\Startup\run.py' % SOFTWARE_HOME CONFIG_FILE= os.path.join(INSTANCE_HOME, 'etc', 'zope.conf') PYTHONSERVICE_EXE=r'%s\bin\PythonService.exe' % ZOPE_HOME
sys.path.insert(0, SOFTWARE_HOME) os.environ['PYTHONPATH'] = SOFTWARE_HOME <---------------- inserted line
from nt_svcutils.service import Service
servicename = 'Zope_%s' % str(hash(INSTANCE_HOME))
class InstanceService(Service): start_cmd = '"%s" "%s" -C "%s"' % (PYTHONW, ZOPE_RUN, CONFIG_FILE) _svc_name_ = servicename _svc_display_name_ = 'Zope instance at %s' % INSTANCE_HOME _exe_name_ = PYTHONSERVICE_EXE
if __name__ == '__main__': import win32serviceutil win32serviceutil.HandleCommandLine(InstanceService)
This is much more palatable in my opinion.
Does this work? On all of W2K, Win98, and WinXP? If so, I'd be glad to ditch the current munging of sitecustomize.py. As I said, it wasn't working for me, at least on Win2K.
- C
------------------------------
Message: 4 Date: Mon, 8 Mar 2004 22:27:27 -0500 From: "Tim Peters" <tim@zope.com> Subject: RE: [Zope-dev] Zopeservice and sitecustomize To: "Sake" <sakesun@boonthavorn.com> Cc: zope-dev@zope.org Message-ID: <LNBBLJKPBEHFEDALKOLCEEFJJGAB.tim@zope.com> Content-Type: text/plain; charset="iso-8859-1"
[Sake]
I have Zope and Activestate Python installed together in the same win-xp machine. Everything works fine until I've learned that I can put "sys.setdefaultencoding('cp874')" into sitecustomize.py to accomodate my native language coding. Since I do that, my Zope 2.7.0 service can no longer start. I can start it manually from "runzope.bat", but it never start through the windows system service. A full day investigation reveal that the trouble cause by the missing of the '<SOFTWARE_HOME>\lib\python' in the system environment's "PYTHONPATH". The "runzope.bat" set that up before then execution of "Zope.Startup.run.py", hence it run fine. But "zopeservice.py" rely on the "<SOFTWARE_HOME>\bin\Lib\site-packages\sitecustomize.py" to set up the correct "PYTHONPATH". Here is the code inside Zope's sitecustomize.py
""" Add Zope packages in Windows binary distro to sys.path automagically """ import sys import os try: sp = __file__ except: sp = None if sp: dn = os.path.dirname swhome = os.path.join(dn(dn(dn(dn(sp)))), 'lib', 'python') if os.path.exists(swhome): sys.path.insert(0, swhome)
Unluckily, this sitecustomize.py is now masked with my sitecustomize.py inside Activestate's site-package directory, which actually get loaded by Zope via the Python registry load path (HKEY_LOCAL_MACHINE\SOFTWARE\Python\PythonCore\2.3\PythonPath) instead of the expected one.
It's actually a different bug: Python normally never looks at the value of the PythonPath registry key, and that's not why your sitecustomize.py is found first. That's actually a side effect of ActiveState installing win32all: if you look *under* HKLM\Software\Python\PythonCore\2.3\PythonPath, you'll find subkeys Pythonwin, win32, and win32com. It's actually the win32com subkey that puts your ActiveState Python's lib\site-packages into sys.path. It's then a bug in Zope that it lets that dirty trick hide its own lib\site-packages: Zope ships with its own Python, and *intends* to insulate you completely (in both directions) from whatever other Python(s) you may happen to have installed on the machine. So when that bug gets fixed, your sitecustomize.py will never get executed.
BTW, sys.setdefaultencoding() is almost never a good solution; working with Unicode instead usually is.
------------------------------
Message: 5 Date: Mon, 8 Mar 2004 22:35:20 -0500 From: "Tim Peters" <tim@zope.com> Subject: RE: [Zope-dev] Zopeservice and sitecustomize To: "Chris McDonough" <chrism@plope.com>, "Sake" <sakesun@boonthavorn.com> Cc: zope-dev@zope.org Message-ID: <LNBBLJKPBEHFEDALKOLCOEFKJGAB.tim@zope.com> Content-Type: text/plain; charset="iso-8859-1"
[Chris McDonough]
... From this (and without a Windows machine in front of me), I can't really make any sense out of why your Activestate Python's sitecustomize.py is being found instead of Zope's Python sitecustomize.py if you're running Zope using the Zope Python install. I suspect it may be because of placement of your sitecustomize.py file and the rule named "We look in the registry for "application paths"", but that's a guess.
Yes, and the "application path" is specifically win32com, which ActiveState installed. That has the side effect of putting the ActiveState Python's Lib/site-packages into sys.path, and it so happens that it ends up before Zope's Lib/site-packages. That's why Sake's sitecustomize.py is found first. It also so happens that all of ActiveState's win32all appears before any of Zope's attempt to supply its own win32all, so there are multiple bugs here. AFIAK, these subtle sys.path glitches are in all of Zope Corp's Windows offerings, except for the very recent ZRS-for-Windows 1.4 release.
------------------------------
Message: 6 Date: Tue, 09 Mar 2004 10:21:31 +0000 From: Chris Withers <lists@simplistix.co.uk> Subject: Re: [Zope-dev] Re: Unexpected Behaviour iterating over catalog search... To: Jean Jordaan <jean@upfrontsystems.co.za> Cc: zope-dev@zope.org Message-ID: <404D9AAB.6020001@simplistix.co.uk> Content-Type: text/plain; charset=us-ascii; format=flowed
Jean Jordaan wrote:
for brain in Catalog(some_index=some_value): # delete the object, and then brain_to_delete = Catalog(unique_index=brain.unique_prop) Catalog.uncatalog_object(brain_to_delete.getPath())
.. can't really think why that would work if Chris's original doesn't, though.
...it won't, this is analagous to the code I have that fails.
cheers,
Chris
-- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
------------------------------
Message: 7 Date: Tue, 09 Mar 2004 13:36:33 +0200 From: "Alex V. Koval" <alex@halogen-dg.com> Subject: Re: [ZODB-Dev] Re: BTrees strangeness (was [Zope-dev] Zope 2.X BIG Session problems - blocker - our site dies - need help of experience Zope developer, please) To: "Chris McDonough" <chrism@plope.com> Cc: zope-dev@zope.org Message-ID: <opr4lei7llb959jf@alex.halogen.kharkov.ua> Content-Type: text/plain; charset="koi8-r"
Hi Chris,
On Fri, 05 Mar 2004 13:08:01 -0500, Chris McDonough <chrism@plope.com> wrote:
I am monitoring site now, and will tell you about the results. OK, many thanks!
Running For: 3 days 4 hours 28 min 29 sec.
I have enabled 400 error_log ex exceptions to keep, and during 3 days I got 2 errors on the site:
Time Username (User Id) Exception 16:35:01 Anonymous User (None) KeyError: 1078763620 21:59:05 Anonymous User (None) KeyError: 1078696720
But it seems I forget to install new Transience module to the new Zope instance. Should I?
-- Alex V. Koval http://www.halogen-dg.com http://www.zwarehouse.org
I think you are describing a flaw that had been removed in older versions. Does not sound like a feature but like a bug... -aj --On Dienstag, 9. März 2004 13:31 Uhr +0100 Juan Javier Carrera Obrero <jcarrera@uco.es> wrote:
Hi,
In Zope 2.4 or older versions when a user is created, if you specify a domain and leave the password for a user blank, then anyone from the permitted domains automatically gets the user's roles without having to log in.
However, it is not possible in Zope 2.7. I have created a user specifying a domain and leave the password for this user blank, and although I am in the domain, I have to log in.
Anybody help me about it ? How can I create a user, specifying a domain, and if the user is in the domain does not have to log in?
Thanks.-
----- Original Message ----- From: <zope-dev-request@zope.org> To: <zope-dev@zope.org> Sent: Tuesday, March 09, 2004 12:36 PM Subject: Zope-Dev Digest, Vol 8, Issue 15
Send Zope-Dev mailing list submissions to zope-dev@zope.org
To subscribe or unsubscribe via the World Wide Web, visit http://mail.zope.org/mailman/listinfo/zope-dev or, via email, send a message with subject or body 'help' to zope-dev-request@zope.org
You can reach the person managing the list at zope-dev-owner@zope.org
When replying, please edit your Subject line so it is more specific than "Re: Contents of Zope-Dev digest..."
Today's Topics:
1. Re: Re: Unexpected Behaviour iterating over catalog search... (Dieter Maurer) 2. Zopeservice and sitecustomize (Sake) 3. Re: Zopeservice and sitecustomize (Chris McDonough) 4. RE: Zopeservice and sitecustomize (Tim Peters) 5. RE: Zopeservice and sitecustomize (Tim Peters) 6. Re: Re: Unexpected Behaviour iterating over catalog search... (Chris Withers) 7. Re: [ZODB-Dev] Re: BTrees strangeness (was [Zope-dev] Zope 2.X BIG Session problems - blocker - our site dies - need help of experience Zope developer, please) (Alex V. Koval)
----------------------------------------------------------------------
Message: 1 Date: Mon, 8 Mar 2004 20:05:04 +0100 From: Dieter Maurer <dieter@handshake.de> Subject: Re: [Zope-dev] Re: Unexpected Behaviour iterating over catalog search... To: Jean Jordaan <jean@upfrontsystems.co.za> Cc: zope-dev@zope.org Message-ID: <16460.50144.170406.811279@gargle.gargle.HOWL> Content-Type: text/plain; charset=us-ascii
Jean Jordaan wrote at 2004-3-8 16:33 +0200:
Surely the thing returned by a Catalog search should be immutable?
Nope, it is "lazy"; immutability would require "realizing" it first, which would be prohibitively expensive in many cases.
Yes .. thing is, wrapping with list() or tuple() will therefore also be prohibitive in those cases,
When you want to uncatalog everything, "tuple"ing the result should not be a problem.
Otherwise, a standard approach is to remember the objects you want to delete in a standard list and iterate over this list in a separate loop (outside the first one).
-- Dieter
------------------------------
Message: 2 Date: Tue, 09 Mar 2004 08:54:54 +0700 From: Sake <sakesun@boonthavorn.com> Subject: [Zope-dev] Zopeservice and sitecustomize To: zope-dev@zope.org Message-ID: <404D23EE.1080702@boonthavorn.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Hi,
I have Zope and Activestate Python installed together in the same win-xp machine. Everything works fine until I've learned that I can put "sys.setdefaultencoding('cp874')" into sitecustomize.py to accomodate my native language coding. Since I do that, my Zope 2.7.0 service can no longer start. I can start it manually from "runzope.bat", but it never start through the windows system service. A full day investigation reveal that the trouble cause by the missing of the '<SOFTWARE_HOME>\lib\python' in the system environment's "PYTHONPATH". The "runzope.bat" set that up before then execution of "Zope.Startup.run.py", hence it run fine. But "zopeservice.py" rely on the "<SOFTWARE_HOME>\bin\Lib\site-packages\sitecustomize.py" to set up the correct "PYTHONPATH". Here is the code inside Zope's sitecustomize.py
""" Add Zope packages in Windows binary distro to sys.path automagically """ import sys import os try: sp = __file__ except: sp = None if sp: dn = os.path.dirname swhome = os.path.join(dn(dn(dn(dn(sp)))), 'lib', 'python') if os.path.exists(swhome): sys.path.insert(0, swhome)
Unluckily, this sitecustomize.py is now masked with my sitecustomize.py inside Activestate's site-package directory, which actually get loaded by Zope via the Python registry load path (HKEY_LOCAL_MACHINE\SOFTWARE\Python\PythonCore\2.3\PythonPath) instead of the expected one.
I don't think setting up PYTHONPATH inside sitecustomize.py is a good idea. Better keep this mechanism for site specific problems. I'd rather insert a line into zopeservice.py like this.
import os.path from os.path import dirname as dn import sys
# these are replacements from mkzopeinstance PYTHONW = r'C:\Zope-2.7.0\bin\pythonw.exe' SOFTWARE_HOME=r'C:\Zope-2.7.0\lib\python' INSTANCE_HOME = r'C:\Zope-MIB' ZOPE_HOME = r'C:\Zope-2.7.0'
ZOPE_RUN = r'%s\Zope\Startup\run.py' % SOFTWARE_HOME CONFIG_FILE= os.path.join(INSTANCE_HOME, 'etc', 'zope.conf') PYTHONSERVICE_EXE=r'%s\bin\PythonService.exe' % ZOPE_HOME
sys.path.insert(0, SOFTWARE_HOME) os.environ['PYTHONPATH'] = SOFTWARE_HOME <---------------- inserted line
from nt_svcutils.service import Service
servicename = 'Zope_%s' % str(hash(INSTANCE_HOME))
class InstanceService(Service): start_cmd = '"%s" "%s" -C "%s"' % (PYTHONW, ZOPE_RUN, CONFIG_FILE) _svc_name_ = servicename _svc_display_name_ = 'Zope instance at %s' % INSTANCE_HOME _exe_name_ = PYTHONSERVICE_EXE
if __name__ == '__main__': import win32serviceutil win32serviceutil.HandleCommandLine(InstanceService)
This is much more palatable in my opinion.
------------------------------
Message: 3 Date: Mon, 08 Mar 2004 22:14:10 -0500 From: Chris McDonough <chrism@plope.com> Subject: Re: [Zope-dev] Zopeservice and sitecustomize To: Sake <sakesun@boonthavorn.com> Cc: zope-dev@zope.org Message-ID: <1078802050.12387.38.camel@athlon> Content-Type: text/plain
On Mon, 2004-03-08 at 20:54, Sake wrote:
Everything works fine until I've learned that I can put "sys.setdefaultencoding('cp874')" into sitecustomize.py
I assume you created a new sitecustomize.py to hold this in your activestate Python's library directory, then?
I can start it manually from "runzope.bat", but it never start through the windows system service. A full day investigation reveal that the trouble cause by the missing of the '<SOFTWARE_HOME>\lib\python' in the system environment's "PYTHONPATH". The "runzope.bat" set that up before then execution of "Zope.Startup.run.py", hence it run fine. But "zopeservice.py" rely on the "<SOFTWARE_HOME>\bin\Lib\site-packages\sitecustomize.py" to set up the correct "PYTHONPATH". Here is the code inside Zope's sitecustomize.py
This was put here because in my tests I could not make Python recognize the "right" set of paths by setting an environment variable in the zopeservice script.
As you probably noticed, Zope does not run in the same Python interpreter instance as the one that zopeservice.py runs under. zopeservice.py instead turns around and invokes another Python interpreter to actually do the running of Zope itself (that's what "start_cmd" is set for). Worse, the windows Service code actually doesn't invoke zopeservice.py directly; it is run as a side effect of the PythonService.exe executable being run. Setting a PYTHONPATH via os.environ in zopeservice was not doing the trick for me (at least on Win2K); why was unclear, although I think it was because the environment being modified by setting os.environ within zopeservice is not carried over to child processes. A batch file couldn't be used as the target for the service because the Windows shell doesn't keep track of child processes in the same way UNIX does: child processes aren't killed when their parents are and there is no way to 'exec' another command from a Windows batch file.
Unluckily, this sitecustomize.py is now masked with my sitecustomize.py inside Activestate's site-package directory, which actually get loaded by Zope via the Python registry load path (HKEY_LOCAL_MACHINE\SOFTWARE\Python\PythonCore\2.3\PythonPath) instead of the expected one.
I don't think I understand why this happens. That's not surprising. There is some complicated DWIM that Windows Python does when it starts up to try to guess what should go on sys.path and in what order. Tim Peters dug up a comment in Python's code and sent it to me a bit ago about why this happens. It can be found in Python's PC/getpathp.c file:
PATH RULES FOR WINDOWS: This describes how sys.path is formed on Windows. It describes the functionality, not the implementation (ie, the order in which these are actually fetched is different)
* Python always adds an empty entry at the start, which corresponds to the current directory.
* If the PYTHONPATH env. var. exists, it's entries are added next.
* We look in the registry for "application paths" - that is, sub-keys under the main PythonPath registry key. These are added next (the order of sub-key processing is undefined). HKEY_CURRENT_USER is searched and added first. HKEY_LOCAL_MACHINE is searched and added next. (Note that all known installers only use HKLM, so HKCU is typically empty)
* We attempt to locate the "Python Home" - if the PYTHONHOME env var is set, we believe it. Otherwise, we use the path of our host .EXE's to try and locate our "landmark" (lib\\os.py) and deduce our home. - If we DO have a Python Home: The relevant sub-directories (Lib, plat-win, lib-tk, etc) are based on the Python Home - If we DO NOT have a Python Home, the core Python Path is loaded from the registry. This is the main PythonPath key, and both HKLM and HKCU are combined to form the path)
* Iff - we can not locate the Python Home, have not had a PYTHONPATH specified, and can't locate any Registry entries (ie, we have _nothing_ we can assume is a good path), a default path with relative entries is used (eg. .\Lib;.\plat-win, etc)
The end result of all this is: * When running python.exe, or any other .exe in the main Python directory (either an installed version, or directly from the PCbuild directory), the core path is deduced, and the core paths in the registry are ignored. Other "application paths" in the registry are always read.
* When Python is hosted in another exe (different directory, embedded via COM, etc), the Python Home will not be deduced, so the core path from the registry is used. Other "application paths" in the registry are always read.
* If Python can't find its home and there is no registry (eg, frozen exe, some very strange installation setup) you get a path with some default, but relative, paths.
From this (and without a Windows machine in front of me), I can't really make any sense out of why your Activestate Python's sitecustomize.py is being found instead of Zope's Python sitecustomize.py if you're running Zope using the Zope Python install. I suspect it may be because of placement of your sitecustomize.py file and the rule named "We look in the registry for "application paths"", but that's a guess.
I don't think setting up PYTHONPATH inside sitecustomize.py is a good idea. Better keep this mechanism for site specific problems. I'd rather insert a line into zopeservice.py like this.
import os.path from os.path import dirname as dn import sys
# these are replacements from mkzopeinstance PYTHONW = r'C:\Zope-2.7.0\bin\pythonw.exe' SOFTWARE_HOME=r'C:\Zope-2.7.0\lib\python' INSTANCE_HOME = r'C:\Zope-MIB' ZOPE_HOME = r'C:\Zope-2.7.0'
ZOPE_RUN = r'%s\Zope\Startup\run.py' % SOFTWARE_HOME CONFIG_FILE= os.path.join(INSTANCE_HOME, 'etc', 'zope.conf') PYTHONSERVICE_EXE=r'%s\bin\PythonService.exe' % ZOPE_HOME
sys.path.insert(0, SOFTWARE_HOME) os.environ['PYTHONPATH'] = SOFTWARE_HOME <---------------- inserted line
from nt_svcutils.service import Service
servicename = 'Zope_%s' % str(hash(INSTANCE_HOME))
class InstanceService(Service): start_cmd = '"%s" "%s" -C "%s"' % (PYTHONW, ZOPE_RUN, CONFIG_FILE) _svc_name_ = servicename _svc_display_name_ = 'Zope instance at %s' % INSTANCE_HOME _exe_name_ = PYTHONSERVICE_EXE
if __name__ == '__main__': import win32serviceutil win32serviceutil.HandleCommandLine(InstanceService)
This is much more palatable in my opinion.
Does this work? On all of W2K, Win98, and WinXP? If so, I'd be glad to ditch the current munging of sitecustomize.py. As I said, it wasn't working for me, at least on Win2K.
- C
------------------------------
Message: 4 Date: Mon, 8 Mar 2004 22:27:27 -0500 From: "Tim Peters" <tim@zope.com> Subject: RE: [Zope-dev] Zopeservice and sitecustomize To: "Sake" <sakesun@boonthavorn.com> Cc: zope-dev@zope.org Message-ID: <LNBBLJKPBEHFEDALKOLCEEFJJGAB.tim@zope.com> Content-Type: text/plain; charset="iso-8859-1"
[Sake]
I have Zope and Activestate Python installed together in the same win-xp machine. Everything works fine until I've learned that I can put "sys.setdefaultencoding('cp874')" into sitecustomize.py to accomodate my native language coding. Since I do that, my Zope 2.7.0 service can no longer start. I can start it manually from "runzope.bat", but it never start through the windows system service. A full day investigation reveal that the trouble cause by the missing of the '<SOFTWARE_HOME>\lib\python' in the system environment's "PYTHONPATH". The "runzope.bat" set that up before then execution of "Zope.Startup.run.py", hence it run fine. But "zopeservice.py" rely on the "<SOFTWARE_HOME>\bin\Lib\site-packages\sitecustomize.py" to set up the correct "PYTHONPATH". Here is the code inside Zope's sitecustomize.py
""" Add Zope packages in Windows binary distro to sys.path automagically """ import sys import os try: sp = __file__ except: sp = None if sp: dn = os.path.dirname swhome = os.path.join(dn(dn(dn(dn(sp)))), 'lib', 'python') if os.path.exists(swhome): sys.path.insert(0, swhome)
Unluckily, this sitecustomize.py is now masked with my sitecustomize.py inside Activestate's site-package directory, which actually get loaded by Zope via the Python registry load path (HKEY_LOCAL_MACHINE\SOFTWARE\Python\PythonCore\2.3\PythonPath) instead of the expected one.
It's actually a different bug: Python normally never looks at the value of the PythonPath registry key, and that's not why your sitecustomize.py is found first. That's actually a side effect of ActiveState installing win32all: if you look *under* HKLM\Software\Python\PythonCore\2.3\PythonPath, you'll find subkeys Pythonwin, win32, and win32com. It's actually the win32com subkey that puts your ActiveState Python's lib\site-packages into sys.path. It's then a bug in Zope that it lets that dirty trick hide its own lib\site-packages: Zope ships with its own Python, and *intends* to insulate you completely (in both directions) from whatever other Python(s) you may happen to have installed on the machine. So when that bug gets fixed, your sitecustomize.py will never get executed.
BTW, sys.setdefaultencoding() is almost never a good solution; working with Unicode instead usually is.
------------------------------
Message: 5 Date: Mon, 8 Mar 2004 22:35:20 -0500 From: "Tim Peters" <tim@zope.com> Subject: RE: [Zope-dev] Zopeservice and sitecustomize To: "Chris McDonough" <chrism@plope.com>, "Sake" <sakesun@boonthavorn.com> Cc: zope-dev@zope.org Message-ID: <LNBBLJKPBEHFEDALKOLCOEFKJGAB.tim@zope.com> Content-Type: text/plain; charset="iso-8859-1"
[Chris McDonough]
... From this (and without a Windows machine in front of me), I can't really make any sense out of why your Activestate Python's sitecustomize.py is being found instead of Zope's Python sitecustomize.py if you're running Zope using the Zope Python install. I suspect it may be because of placement of your sitecustomize.py file and the rule named "We look in the registry for "application paths"", but that's a guess.
Yes, and the "application path" is specifically win32com, which ActiveState installed. That has the side effect of putting the ActiveState Python's Lib/site-packages into sys.path, and it so happens that it ends up before Zope's Lib/site-packages. That's why Sake's sitecustomize.py is found first. It also so happens that all of ActiveState's win32all appears before any of Zope's attempt to supply its own win32all, so there are multiple bugs here. AFIAK, these subtle sys.path glitches are in all of Zope Corp's Windows offerings, except for the very recent ZRS-for-Windows 1.4 release.
------------------------------
Message: 6 Date: Tue, 09 Mar 2004 10:21:31 +0000 From: Chris Withers <lists@simplistix.co.uk> Subject: Re: [Zope-dev] Re: Unexpected Behaviour iterating over catalog search... To: Jean Jordaan <jean@upfrontsystems.co.za> Cc: zope-dev@zope.org Message-ID: <404D9AAB.6020001@simplistix.co.uk> Content-Type: text/plain; charset=us-ascii; format=flowed
Jean Jordaan wrote:
for brain in Catalog(some_index=some_value): # delete the object, and then brain_to_delete = Catalog(unique_index=brain.unique_prop) Catalog.uncatalog_object(brain_to_delete.getPath())
.. can't really think why that would work if Chris's original doesn't, though.
...it won't, this is analagous to the code I have that fails.
cheers,
Chris
-- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
------------------------------
Message: 7 Date: Tue, 09 Mar 2004 13:36:33 +0200 From: "Alex V. Koval" <alex@halogen-dg.com> Subject: Re: [ZODB-Dev] Re: BTrees strangeness (was [Zope-dev] Zope 2.X BIG Session problems - blocker - our site dies - need help of experience Zope developer, please) To: "Chris McDonough" <chrism@plope.com> Cc: zope-dev@zope.org Message-ID: <opr4lei7llb959jf@alex.halogen.kharkov.ua> Content-Type: text/plain; charset="koi8-r"
Hi Chris,
On Fri, 05 Mar 2004 13:08:01 -0500, Chris McDonough <chrism@plope.com> wrote:
I am monitoring site now, and will tell you about the results. OK, many thanks!
Running For: 3 days 4 hours 28 min 29 sec.
I have enabled 400 error_log ex exceptions to keep, and during 3 days I got 2 errors on the site:
Time Username (User Id) Exception 16:35:01 Anonymous User (None) KeyError: 1078763620 21:59:05 Anonymous User (None) KeyError: 1078696720
But it seems I forget to install new Transience module to the new Zope instance. Should I?
-- Alex V. Koval http://www.halogen-dg.com http://www.zwarehouse.org
It's not a bug, in fact it's a cool way to allow different types of anonymous users. That's not to say that it's a fool-proof way of doing it, but it generally works, as long as you don't rely on it for any sort of security ;) . The thing is that in later zope versions the functionality has been turned off by default, and (at least for 2.6.2) you have to turn it on manually, like so: http://your.server/acl_users/setDomainAuthenticationMode?domain_auth_mode=1 The docstring for this method (from a zope 2.7.0 install) is as follows: """Set the domain-based authentication mode. By default, this mode is off due to the high overhead of the operation that is incurred for all anonymous accesses. If you have the 'Manage Users' permission, you can call this method via the web, passing a boolean value for domain_auth_mode to turn this behavior on or off.""" btw, the method is in <zope>/lib/python/AccessControl/User.py hth Phil Andreas Jung wrote:
I think you are describing a flaw that had been removed in older versions. Does not sound like a feature but like a bug...
-aj
--On Dienstag, 9. März 2004 13:31 Uhr +0100 Juan Javier Carrera Obrero <jcarrera@uco.es> wrote:
Hi,
In Zope 2.4 or older versions when a user is created, if you specify a domain and leave the password for a user blank, then anyone from the permitted domains automatically gets the user's roles without having to log in.
However, it is not possible in Zope 2.7. I have created a user specifying a domain and leave the password for this user blank, and although I am in the domain, I have to log in.
Anybody help me about it ? How can I create a user, specifying a domain, and if the user is in the domain does not have to log in?
Thanks.-
participants (3)
-
Andreas Jung -
Juan Javier Carrera Obrero -
Phil Harris