Re[2]: [Zope3-dev] ServerControlForm.html / Restart, Shutdown does not work
Hello Tim, Monday, July 18, 2005, 6:38:12 PM, you wrote: snip TP Another: did this actually work before? The only place I've found TP that set LoopCallback.exit_status is TP zope/app/server/servercontrol.py, TP and both methods there have TODO: ... does not work yet comments TP (in both Zope and Zope3 SVN trunks). snip Yes it did work. That was the quickest way on win32 to shutdown Zope. I cannot tell you the exact time when it was working last, but I'm sure it was working 1-2 months before. -- Best regards, Adammailto:[EMAIL PROTECTED] -- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] problems with ZOPE_WATCH_CHECKERS
Hi there, I'm trying to debug the security of a Zope 3 application (in Zope 3.1 beta) and I am having trouble getting ZOPE_WATCH_CHECKERS to work. If I set it to 1, I expect to see information on which attributes on which object are denied. I however see nothing whatever. If I set it to a higher value, I *do* see a few granted messages, though suspiciously few messages appear and rather confusing ones, especially as I am trying to a access a page that doesn't tie into the ZMI: [CHK] + Granted getattr: __call__ on bound method ContextHelpView.getContextualTopicView of zope.app.publisher.browser.viewmeta.ContextHelpView object at 0x442764ec [CHK] + Granted getattr: __call__ on bound method ContextHelpView.getContextualTopicView of zope.app.publisher.browser.viewmeta.ContextHelpView object at 0x442a17ec [CHK] + Granted getattr: __call__ on bound method ContextHelpView.getContextualTopicView of zope.app.publisher.browser.viewmeta.ContextHelpView object at 0x442ef5ec What's going on? Why do the only messages I ever see involve ContextHelpView? Is it possible that this mechanism is broken? Some debugging did seem to indicate the right logging checkers get created, but perhaps the logging methods do not actually get called most of the time? In an attempt at deeper debugging I tried removing the C implementation (_zope_security_checker.so) temporarily, as the checker.py code seems to indicate it should fallback on the Python version. Unfortunately, Zope 3 fails to start in this case... Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] zope.security.interfaces.ForbiddenAttribute: ('utcoffset', UTC)
On Jul 18, 2005, at 7:04 PM, Garrett Smith wrote: This might be something on my end, but I figure I'd throw it out in case it's related to any changes related to naïve/non-naïve time zones. Here's the relevant part of the traceback: File /opt/aktari/zope/src/zope/i18n/format.py, line 175, in format info = buildDateTimeInfo(obj, self.calendar, bin_pattern) File /opt/aktari/zope/src/zope/i18n/format.py, line 603, in buildDateTimeInfo tz_secs = tzinfo.utcoffset(dt).seconds I'll dig further, but at a casual glance I couldn't turn up any security declarations for UTC objects. Could this be a case where datetime values are suddenly spouting proxied tzinfos? Hm. security proxies, of course, can't be persisted, so this would only happen if your datetime were proxied (which is completely reasonable). Did you try just making a security declaration and seeing if that fixed the issue? I haven't encountered the problem. I would think you could just do something like class class=pytz.UTC allow interface=zope.interface.common.idatetime.ITZInfo / /class I'm not sure where to put this in zope.app...maybe zope.app.interface? Gary___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Formatting dates
On Jul 19, 2005, at 12:22 AM, Garrett Smith wrote: Now that dates have UTC time zones associated with them, will we be adjusting how they're displayed in various views? Somehow it doesn't seem appropriate to display UTC by default. I'd assume Zope would use the server's timezone offset. Here's an excerpt of me describing our plan for ZC software on IRC, which Stephan has approved for post-3.1 Zope (taken from http:// zope3.pov.lt/irclogs/%23zope3-dev.2005-07-15.log.html): GaryPosterso we already agree on tz-aware storage. My intent is to always expect an adapter of request to tzinfo.20:49 GaryPosterwe plan to have our apps allow specifying tz in the zope 3 preferences stuff20:49 GaryPosterso a logged-in user would have a default timezone20:50 GaryPosterThis would affect collected timezone-less times from our forms,20:50 GaryPosterand affect the astimezone for the display of the stored utc datetimes.20:50 GaryPosterWe're stubbing this for our current apps, since it hasn't been high-priority enough20:51 We go on (in the log) to talk about strategies for unauthenticated users. Gary ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] zope.exceptions.exceptionformatter
Shane Hathaway wrote:
I'd like to change Zope 3 to log exceptions using
zope.exceptions.exceptionformatter. Zope's exceptionformatter formats
tracebacks with information from __traceback_info__ and
__traceback_supplement__ variables, which is very useful for debugging
problems with page templates. I've made all the necessary changes in my
own Zope 3 sandbox. I've also added an option to exceptionformatter for
displaying module filenames rather than module names, so that old
concern is gone.
However, the place where it's possible to properly install
exceptionformatter as the traceback generator is inside ZConfig. AFAICT,
ZConfig tries hard to not import anything from the zope package. So I
don't know how to get my code installed without poking a hole in
ZConfig. What should I do?
FWIW, here are the patches I'm proposing.
Shane
Index: zope/app/traversing/adapters.py
===
--- zope/app/traversing/adapters.py (revision 33328)
+++ zope/app/traversing/adapters.py (working copy)
@@ -146,6 +146,8 @@
not provided.
+__traceback_info__ = (obj, name)
+
if name == '.':
return obj
Index: zope/exceptions/exceptionformatter.py
===
--- zope/exceptions/exceptionformatter.py (revision 33328)
+++ zope/exceptions/exceptionformatter.py (working copy)
@@ -19,6 +19,7 @@
import sys
import cgi
import linecache
+import traceback
DEBUG_EXCEPTION_FORMATTER = 1
@@ -27,14 +28,15 @@
line_sep = '\n'
show_revisions = 0
-def __init__(self, limit=None):
+def __init__(self, limit=None, with_filenames=False):
self.limit = limit
+self.with_filenames = with_filenames
def escape(self, s):
return s
def getPrefix(self):
-return 'Traceback (innermost last):'
+return 'Traceback (most recent call last):'
def getLimit(self):
limit = self.limit
@@ -122,14 +124,16 @@
name = co.co_name
locals = f.f_locals
globals = f.f_globals
-modname = globals.get('__name__', filename)
-s = ' Module %s, line %d' % (modname, lineno)
+if self.with_filenames:
+s = ' File %s, line %d' % (filename, lineno)
+else:
+modname = globals.get('__name__', filename)
+s = ' Module %s, line %d' % (modname, lineno)
+revision = self.getRevision(globals)
+if revision:
+s = s + ', rev. %s' % revision
-revision = self.getRevision(globals)
-if revision:
-s = s + ', rev. %s' % revision
-
s = s + ', in %s' % name
result = []
@@ -158,7 +162,6 @@
result.extend(self.formatSupplement(supp, tb))
except:
if DEBUG_EXCEPTION_FORMATTER:
-import traceback
traceback.print_exc()
# else just swallow the exception.
@@ -168,14 +171,12 @@
result.append(self.formatTracebackInfo(tbi))
except:
if DEBUG_EXCEPTION_FORMATTER:
-import traceback
traceback.print_exc()
# else just swallow the exception.
return self.line_sep.join(result)
def formatExceptionOnly(self, etype, value):
-import traceback
return self.line_sep.join(
traceback.format_exception_only(etype, value))
@@ -210,7 +211,7 @@
return cgi.escape(s)
def getPrefix(self):
-return 'pTraceback (innermost last):\r\nul'
+return 'pTraceback (most recent call last):\r\nul'
def formatSupplementLine(self, line):
return 'b%s/b' % self.escape(str(line))
@@ -233,13 +234,32 @@
if hasattr(sys, 'tracebacklimit'):
limit = min(limit, sys.tracebacklimit)
-text_formatter = TextExceptionFormatter(limit)
-html_formatter = HTMLExceptionFormatter(limit)
+def format_exception(t, v, tb, limit=None, as_html=False,
+ with_filenames=False):
+Format a stack trace and the exception information.
-def format_exception(t, v, tb, limit=None, as_html=0):
+See 'traceback.format_exception', but adds supplemental
+information to the traceback and accepts two options, 'as_html'
+and 'with_filenames'.
+
if as_html:
-fmt = html_formatter
+fmt = HTMLExceptionFormatter(limit, with_filenames)
else:
-fmt = text_formatter
+fmt = TextExceptionFormatter(limit, with_filenames)
return fmt.formatException(t, v, tb)
+
+
+def print_exception(t, v, tb, limit=None, file=None, as_html=False,
+with_filenames=True):
+Print exception up to 'limit' stack trace entries from 'tb' to 'file'.
+
+Similar to 'traceback.print_exception', but adds supplemental
+information to the traceback and accepts two options, 'as_html'
+
Re: [Zope3-dev] problems with ZOPE_WATCH_CHECKERS
On Jul 19, 2005, at 12:35 PM, Martijn Faassen wrote: Martijn Faassen wrote: Martijn Faassen wrote: Hi there, I'm trying to debug the security of a Zope 3 application (in Zope 3.1 beta) and I am having trouble getting ZOPE_WATCH_CHECKERS to work. Note that I was trying this as matters are aggrevated by zope.app.exception.browser; there's a view registered for IUnauthorized which suppresses a traceback from appearing in the log, so it becomes extremely hard to debug security with that enabled. If I disable that, I do see a traceback, which at least helps me further. This did help me further, until I realized that this view is in some way involved in presenting the login dialog as well, and disabling it doesn't let me log in. As a result, I am now stuck debugging this security issue. There must be a way others use that does work -- what am I missing? I only want to be able to see which permission on which object is failing. Here are two choices: - Go TTW to the root exception logger and configure it to not ignore Unauthorized exceptions. Provoke the problem again and then look at the exception TTW. - log in using a standard server. stop your server and change the server to a PDB server in the config. Reprovoke; you'll be dumped in the code where the error is happening. The security environment is now a bit wonky so it is a bit problematic. Gary ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re[4]: [Zope3-dev] ServerControlForm.html / Restart, Shutdown does not work
Hello Tim, Tuesday, July 19, 2005, 8:18:01 PM, you wrote: [Tim Peters] None of the above appears to have anything to do with LoopCallback, though, so if any of that used to work but doesn't anymore, there's a cause outside of the changes I made to LoopCallback. Best guess is that the stuff above never worked in Zope3, and that's the meaning of the TODO: ... does not work yet comments in zope/app/server/servercontrol.py. Yes, you're right. I just missed my old buddy, the Shutdown function. I think the functions were designed with a daemonic Zope in mind, but that won't on win32. I think it is still a better way to stop Zope3, than simply closing the command window in which it is running (ouch, that hurts). What do you say, can there be any data loss if I use the Shutdown button? Does Zope write everything out to disc before it quits? Or, a better question: how to stop Zope3 cleanly (and when possible quickly, for development sessions)? -- Best regards, Adammailto:[EMAIL PROTECTED] ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: Re[4]: [Zope3-dev] ServerControlForm.html / Restart, Shutdown does not work
[Tim Peters] ... Best guess is that the stuff above never worked in Zope3, and that's the meaning of the TODO: ... does not work yet comments in zope/app/server/servercontrol.py. [Adam Groszer] Yes, you're right. I just missed my old buddy, the Shutdown function. I think the functions were designed with a daemonic Zope in mind, but that won't on win32. Running Zope as a Windows Service plays that role on win32, and over the last year Mark Hammond contributed code intending to make Zope2 run cleanly as a Windows service. AFAIK, though, none of that code made its way into Zope3. I think it is still a better way to stop Zope3, than simply closing the command window in which it is running (ouch, that hurts). Yes, it is better. The way it's shutting down now (using the button) at least allows the C runtime libraries to flush and close files, just by virtue of allowing Python (which is a C program) to exit cleanly. What do you say, can there be any data loss if I use the Shutdown button? Does Zope write everything out to disc before it quits? It didn't look to me like there's any code in Zope3 now supporting controlled (graceful) shutdown, although this is the first time I looked at Zope3's shutdown code and may have missed something. There's elaborate (probably _overly_ elaborate) code in Zope2 trying to do controlled shutdown. Or, a better question: how to stop Zope3 cleanly (and when possible quickly, for development sessions)? Sorry, no idea here. Anyone else? ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] How to shutdown Zope3 gracefully?
[Adam Groszer] What do you say, can there be any data loss if I use the Shutdown button? Does Zope write everything out to disc before it quits? [Tim Peters] It didn't look to me like there's any code in Zope3 now supporting controlled (graceful) shutdown, although this is the first time I looked at Zope3's shutdown code and may have missed something. There's elaborate (probably _overly_ elaborate) code in Zope2 trying to do controlled shutdown. [Adam Groszer] Or, a better question: how to stop Zope3 cleanly (and when possible quickly, for development sessions)? [Tim Peters] Sorry, no idea here. Anyone else? -- Best regards, Adammailto:[EMAIL PROTECTED] ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] How to shutdown Zope3 gracefully?
Adam Groszer wrote: [Adam Groszer] What do you say, can there be any data loss if I use the Shutdown button? Does Zope write everything out to disc before it quits? Zope (or rather ZODB FileStorage) writes all transactions to disk when they are committed. (Baring extraordinary bugs) any committed transaction cannot be corrupted. [Tim Peters] It didn't look to me like there's any code in Zope3 now supporting controlled (graceful) shutdown, although this is the first time I looked at Zope3's shutdown code and may have missed something. There's elaborate (probably _overly_ elaborate) code in Zope2 trying to do controlled shutdown. To clarify here, there is no danger of losing/corrupting already committed transactions in ZODB. Any current transactions will simple be uncommitted. If you want to programmatically tell Zope to stop you can use code like this: from zope.app import zapi from zope.app.applicationcontrol.interfaces import IServerControl control = zapi.getUtility(IServerControl) control.shutdown(0) [Adam Groszer] Or, a better question: how to stop Zope3 cleanly (and when possible quickly, for development sessions)? [Tim Peters] Sorry, no idea here. Anyone else? Control-C. As I said above, there is no danger of corrupting data in a stock install. There *is* the possibility of having on-going interactions with external systems that need some sort of shutdown (eg. relational databases, etc). In that case I would recommend the Python standard library module atexit. In summary: It might be nice if Z3 closed file handles and waited for outstanding requests to be handled, but the current shutdown story is perfectly safe. -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] How to shutdown Zope3 gracefully?
[Adam Groszer] Or, a better question: how to stop Zope3 cleanly (and when possible quickly, for development sessions)? [Tim Peters] Sorry, no idea here. Anyone else? [Benji York] Control-C. Adam is running on Windows. Bring up Zope3 from a DOS box, and after it's running hit Ctrl+C in the DOS box. Nothing visible happens, and the Python process keeps running, for up to 30 seconds. Unsure why. Probably because it's sitting in a select() with a 30-second timeout, and Ctrl+C doesn't interrupt that on Windows. Ctrl+Break stops it instantly, but then the C libraries don't get a chance to clean up (like Unix kill -9). The Windows Service shutdown code in Zope3 also does a very hard kill (a Win32 TerminateProcess()). Mark Hammond tried to fix the Windows Service shutdown code in Zope2, and improve Windows Ctrl+C handling, but Zope3 doesn't have his new stuff. As I said above, there is no danger of corrupting data in a stock install. There *is* the possibility of having on-going interactions with external systems that need some sort of shutdown (eg. relational databases, etc). In that case I would recommend the Python standard library module atexit. In summary: It might be nice if Z3 closed file handles and waited for outstanding requests to be handled, but the current shutdown story is perfectly safe. Well, the Z3 Windows Service shutdown code isn't wholly safe, ditto Ctrl+Break, and Ctrl+C has surprising behavior. This: from zope.app import zapi from zope.app.applicationcontrol.interfaces import IServerControl control = zapi.getUtility(IServerControl) control.shutdown(0) appears to be the same thing the Z3 Shutdown server button does, and at least lets Python exit cleanly. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] How to shutdown Zope3 gracefully?
Tim Peters wrote: Adam is running on Windows. Sorry, my email has been up and down today, I didn't read the message mentioning that until later. Ctrl+Break stops it instantly, but then the C libraries don't get a chance to clean up (like Unix kill -9). The Windows Service shutdown code in Zope3 also does a very hard kill (a Win32 TerminateProcess()). All very true. I think you'll also agree that it doesn't pose any particular danger during development. Well, the Z3 Windows Service shutdown code isn't wholly safe, ditto Ctrl+Break If you're referring to the fact that Python's shutdown code (including calling atexit registered functions) don't get run in those instances, then I would agree that it isn't wholly safe. I'd also say that it isn't very smart to do that in a production environment, but we're talking about development, and I don't see a problem there (and haven't yet, as that's how I always shut down Zope 3 on Windows) snip code appears to be the same thing the Z3 Shutdown server button does, and at least lets Python exit cleanly. Right. -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
RE: [Zope3-dev] Formatting dates
So this will specifically impact: - The use of date/time formatters - Date/time widgets Anything else? Since datetime values are immutable, I assume you're envisioning that widgets create tz-aware values. With that in mind, I don't understand 'collected timezone-less times from our forms'. -Original Message- From: Gary Poster [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 19, 2005 11:47 AM To: Garrett Smith Cc: Zope3-Dev (zope3-dev@zope.org) Subject: Re: [Zope3-dev] Formatting dates On Jul 19, 2005, at 12:22 AM, Garrett Smith wrote: Now that dates have UTC time zones associated with them, will we be adjusting how they're displayed in various views? Somehow it doesn't seem appropriate to display UTC by default. I'd assume Zope would use the server's timezone offset. Here's an excerpt of me describing our plan for ZC software on IRC, which Stephan has approved for post-3.1 Zope (taken from http:// zope3.pov.lt/irclogs/%23zope3-dev.2005-07-15.log.html): GaryPosterso we already agree on tz-aware storage. My intent is to always expect an adapter of request to tzinfo.20:49 GaryPosterwe plan to have our apps allow specifying tz in the zope 3 preferences stuff20:49 GaryPosterso a logged-in user would have a default timezone20:50 GaryPosterThis would affect collected timezone-less times from our forms,20:50 GaryPosterand affect the astimezone for the display of the stored utc datetimes.20:50 GaryPosterWe're stubbing this for our current apps, since it hasn't been high-priority enough20:51 We go on (in the log) to talk about strategies for unauthenticated users. Gary ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] How to shutdown Zope3 gracefully?
[Tim Peters] Ctrl+Break stops it instantly, but then the C libraries don't get a chance to clean up (like Unix kill -9). The Windows Service shutdown code in Zope3 also does a very hard kill (a Win32 TerminateProcess()). [Benji York] All very true. I think you'll also agree that it doesn't pose any particular danger during development. Yes. ... Well, the Z3 Windows Service shutdown code isn't wholly safe, ditto Ctrl+Break If you're referring to the fact that Python's shutdown code (including calling atexit registered functions) don't get run in those instances, then I would agree that it isn't wholly safe. In part I was, but not mostly: the C runtime libraries don't get a chance to clean up either. In particular, it doesn't help that FileStorage writes each transaction to disk if the data is actually just sitting in some internal C library I/O buffer and the C library doesn't get a chance to flush internal buffers at shutdown time. FileStorage does a sync() call on the file descriptor after each transaction to try to minimize the chance of problems like that, but the effect of sync() doesn't seem well-defined on Windows. I'd also say that it isn't very smart to do that in a production environment, but we're talking about development, and I don't see a problem there (and haven't yet, as that's how I always shut down Zope 3 on Windows) What is? Ctrl-C, Ctrl-Break, or pulling the power cord wink? ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
