Martin quoting me:
I was referring to the thread at
http://mail.zope.org/pipermail/zope-pas/2004-September/86.html,
entitled [Zope-PAS] Challengers (and Zope 3)
...
Sorry, I may've gotten my history mixed up a little here, but in any
case, I think the point remains: no-one's said
Zope3 has never supported PAS and I doubt it ever well.
That is a shame - the thread I referred to shows that Jim was working on
exactly that - it's a shame that never came to fruition (and indeed, its not
clear why that attempt failed - should PAS have been fixed to make that
transition
Well, Zope moved onwards from PAS to PAU and I think Plone should too,
because:
It seems like just yesterday that PAS offered the promise of being the nice
clean way forward for authentication, and even offered a path to Zope3.
I've been subscribed to zope-dev since then, but somehow the
I think you've misunderstood slightly here ... PAS was and is a Zope 2
user folder implementation. It pre-dates Zope 3 (at least as we know it
now).
I was referring to the thread at
http://mail.zope.org/pipermail/zope-pas/2004-September/86.html, entitled
[Zope-PAS] Challengers (and Zope 3)
Hi Leo,
I'm not familiar with the Zope side of the world at all, so this may be
completely useless...
However, if one tries to consume a NamedTemporaryFile and then open its
generated blob before closing the tempfile, Windows complains:
import ZODB.blob, tempfile
f =
Hi there,
I want to write a PAS Plugin that does only the authentication.
it should do the authentication and then store it in a
session for a coupple of hours.
Now I am unsure which services I have to implement.
IAuthenticationPlugin ??
IExtractionPlugin ??
Without more information,
Hi Tres,
If it can validate credentials, however those credentials are
extracted
and checked, then yes. There is *no* generic requirement that a user
have any properties.
If your site depends on externally-provided properties to
generate stuff
which iscritical of the application, then
Hi Chris,
Sorry, do you mean the box where the Zope 2.9.1 distro was built or the
one where I was installing it?
The latter.
If the latter, how dowe fix Zope so it doesn't get tripped up by other
pywin32 distros on the same box?
If this is the problem, it will probably only happen when
* that directory is on your PATH before the Windows SYSTEM32 directory
(which is where pywin32 sticks its copy of these files, for
various reasons)
Do both this and the above have to be true, or will things work if
either of them are true?
Either one has the end result of locating the
I notice the 2.9.1 binary a rolled a couple of weeks back seems to emit
this warning every time I start Zope.
Is there something I've done wrong or is something else causing this?
What version of pywin32 did you use for the build? Is an earlier one
already installed on the target box with
Chris quoting Jim:
lame program for uploading keys, I find the ssh-based access
mechanism to be far more usable and secure.
Secure, maybe, but is it really worth it?
Usable? Don't agree, especially if you're trying to develop on Windows...
As a data-point, for the last year or 2, I've
All recent PySECURITY_ATTRIBUTES complaints I know about have come
from people using both Zope and Plone. I don't know anything about
Plone installation, but it's natural to suspect that Plone is the
source of the other pywin32 installation, and possibly of compounding
sys.path convolutions
/Collectors/Zope/1925
I believe what it says there. Until Mark Hammond can make a new
release of pywin32, you'll have to search for code that:
imports win32api [and] add a line above that: import pywintypes
That's already been done in Zope.
Thanks Tim!
FYI, there is a new pywin32 build
[Sid]
So, leaving other issues aside *wink*, I'm no puzzled by the challenge
code in PAS. It looks like there was some attempt at distinguishing
challenging by some sort of 'protocol', but it leaves a lot to be
desired, or I don't understand how it's supposed to work.
Probably both ;)
The
| Sidnei, are you guys going to release those plugins (including the
| NTLM ones) or is that all for-pay?
Right now it's all for-pay. That might change in the future.
All the bits are there for people to roll their own NTLM plugin.
Specifically:
* Many months ago I released a sample challenge
[Tim]
So, best guesses (please scream where I'm wrong):
- This is because service.py doesn't define a SvcShutdown method, just
a SvcStop method,
- It's a good idea to add a SvcShutdown method to service.py.
- It would suffice to add
SvcShutdown = SvcStop
to service.py.
If
Mark, should Zope's nt_svcutils/service.py also be changed to import
pywintypes first? Its import block looks like this now:
import sys, os, time, threading, signal
import win32api, win32event, win32file, win32pipe,
win32process, win32security
import win32service, win32serviceutil,
[Michael Haubenwallner, to Andreas Jung]
Must be yesterdays version then (i had just that error
message, after
removing an ancient pywintypes23.dll from C:\WINNT\system32).
There are 2 pywintypes23.dlls now:
$ZOPE_HOME\bin\PyWinTypes23.dll
Update of /cvs-repository/Packages/Signals
In directory cvs.zope.org:/tmp/cvs-serv23505
Modified Files:
Tag: Zope-2_7-branch
WinSignalHandler.py
Log Message:
As at pywin32-204, we must ensure pywintypes is the first win32 module
imported in our process, otherwise we can end up with
[Tim Peters, having trouble with 2.8b2 on Windows, ending with
Files\Zope-2.8.0-b2\lib\python\Signals\WinSignalHandler.py, line 203,
in registerHandler
hevent = win32event.CreateEvent(sa, 0, 0, event_name)
TypeError: The object is not a PySECURITY_ATTRIBUTES object
That sounds alot
Run Zope in console fails for me with application has
failed to start
because pywintypes23.dll was not found...
That is surprising :) The reason it *should* work is that
pythonservice.exe, pythonw.exe and pywintypes23.dll are all in the same
directory.
One thing I ran into last night: I
Am Donnerstag, den 26.05.2005, 09:03 +1000 schrieb Mark Hammond:
What path does the final Inno file refer to? Is the entire
path missing, or
just that file missing from that path? IIRC, we explode the pywin32
installer and grab the file from there. I'm pretty sure
that file
So this file of course exists, in a different path. Inno
expected \build
\bin\lib\site-packages\win32\PythonService.exe and it is in \build\bin
\lib\site-packages\PythonService.exe
Should I change Inno's reference (have to do that for the b2
release) or
should it go into a different path
Howdy,
The InnoSetup complained about pythonservice.exe to be missing during
packaging the installer. Any ideas?
What path does the final Inno file refer to? Is the entire path missing, or
just that file missing from that path? IIRC, we explode the pywin32
installer and grab the file from
WinBuilders recently had a number of changes checked in to support later
pywin32 versions and numerous fixes. At around the same time WinBuilders was
copied into the Zope 2.7 and 2.8 trees - but without these improvements.
This is the underlying reason behind the 2.8 binaries for Windows not being
[Tim]
Unfortunately I still haven't heard anything re my contributor
greement, so am unable to make these changes myself.
Jim (Fulton) found processed your contrib agreement since you wrote
this, so you should be all set now.
Excellent - thanks Jim! I have checked those WinBuilder
[Tim]
[Andreas Jung]
I would like to cut the 2.8 beta 2 release this weekend. So I
hope that the windows related issues are fixed until Sunday. I
hope anyone can fix the ZConfig issue with the default IP
address when Zope starts up.
That wasn't the problem. The problem was that Zope
[Andreas Jung]
At least the following are important (besides the problem with the
Winbuilder)
[Tim Peters]
What WinBuilders problem? I keep hearing there's a
problem there,
but don't know what it is -- and I had no problem using WinBuilders
for Zope 2.8.
[Andreas]
I know only
On Windows, this 15 months old change in ZConfig sets the default
hostname for inet_address to 'localhost':
...
So if nobody can tell me why ZConfig was changed, I propose to
That sounds good to me, as I can't understand why Windows would be different
here either.
While looking at this, I
b): I can either create branches for WinBuilders responding
to the Zope
Versions. Or (what I like better) I can put the WinBuilders
somewhere in the Zope 2 tree to allow versioning along a branch
automatically so continuous tests know where to get the
WinBuilders from.
+1
Andreas:
| there are several open issues in the Zope collector with
| Zope running on Windows. I can't see anyone worrying
| about the Windows platform (I also don't care about
| Windows as UN*X guy). So if you are interested
| in running Zope on Windows in a reasonable way than *you*
|
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf
Of Aruna Kathiria
It started but Im not getting the python command prompt as how we get it
on unix when we use zopectl start (in debug mode).
The debug capabilities of Python services on Windows do not extend to
providing any kind of
This there anyother way to debug specific zope site on
windows.
In your Zope's $instance\bin, you should find runzope.bat - you can execute
this from a command-prompt. Depending on things I don't quite understand,
you may or may-not also need to enable debug-mode in your .conf files. Any
[Duncan]
+1 on fixing the problem of log rotation on windows.
I don't like a solution that requires you to wait an
arbitrary period for
the snapshot to appear.
Yes, I see your concern. Assuming we stick to a rename operation, the
external process could simply wait for the expected file to
Hi all,
A number of Enfold's customers have requested a reasonable logfile rotation
scheme for Zope on Windows. Enfold would like to work on this and
contribute it back to Zope. The intention of this mail is to find a
consensus on the general solution we should adopt, so we can supply patches
Ressurecting a bit of an old thread:
From: Chris McDonough [mailto:[EMAIL PROTECTED]
Sent: Wednesday, 4 August 2004 11:19 PM
Subject: Re: [Zope-dev] Possible Windows Service improvements.
...
I'm a Windows signal idiot.
I was too. I think I understand them a little better now after having
Would a lockfile work ok to signify running state? IOW, Zope would
lock a file as one of the last steps during startup (which it actually
does now, but might do it a bit too early). The Windows
service manager
would attempt to lock the same file after timeout seconds (although
I'm not sure
[Me]
By adding a layer around run.py, I believe we could arrange
for these fatal errors to be handled with a special return code.
[Jim]
I assume by fatal, you mean errors that we should not try to restart
from.
Correct.
Let me see if I understand the use cases here:
- Normal shutdown.
Hi all,
I am starting to venture into the wonderful world of Zope! With the
benefit of a complete lack of Zope experience, I have been able to look at
the Windows service support from a fairly clean slate. However, I also
realize this lack of experience means my ideas may be naive - hence I
[Me]
I propose:
We insist the child process can be created and continues to
run for x seconds (where x~5).
[Jim]
I recommend against this strategy. It's too implicit and has
bitten us on
Unix in the past. The problem with the strategy if the
program starts very fast
and then dies, we
I propose:
Each time the child process terminates with a non-zero
return code, the tail
x-bytes of the child output be written to the Windows event
log, where x~2k.
This is a good idea. FWIW, I believe the Zope HEAD already has some
work done towards this (in
FWIW, the equivalent of the service manager code under UNIX
is zopectl
rather than runzope.
Ahh, ok. That makes more sense now, thanks.
When you say these errors above, do you mean any unhandled
exception?
If so (and any nonzero exit code indicated a startup
failure), would we
really
42 matches
Mail list logo