Re: [Zope-dev] xron does not work with python 2.2

2003-09-23 Thread Jean Jordaan
it seams that the Product XRON does not work with python 2.2.
Perhaps you should be thankful .. We tried to use xron a year
or so ago, and it bit us repeatedly. We dropped it and use
cron to tickle a Zope URL or to call an external method. For
those, see:
http://mail.zope.org/pipermail/zope/2003-February/131882.html
http://article.gmane.org/gmane.comp.web.zope.plone.user/2490
--
Jean Jordaan
http://www.upfrontsystems.co.za
___
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] xron does not work with python 2.2

2003-09-23 Thread Dieter Maurer
robert wrote at 2003-9-23 12:57 +0200:
  it seams that the Product XRON does not work with python 2.2.
  
  I can create an instance, however when I try to enter into it from the zmi, I 
  get an error:
  The object at http://localhost:8080/sprint/scheduler has an empty or missing 
  docstring. Objects must have a docstring to be published.
  
  When I run the same site with Python 2.13 everything is fine.
  
  What could be the reason for that?

A new type check has been added to ZPublisher.BaseRequest
to prevent ZPublisher to publish elementary Python types in Python  2.2.
Maybe, you get hit by this.

If not, check that the object has indeed a docstring.


Dieter

___
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] Xron on linux: Dispatcher thread stops after a while

2001-05-28 Thread Steve Alexander

Homan Els wrote:

 ZOPE 2.2.2 , Xron -0-0-9, Python 1.5.2
 
 Hi Steve,
 
 I am running Zope  under linux (Suse 6.4).   And I would like to use
 Xron.  But, I can not get it running.
 I did read your email : Xron on linux. And therefore I would like to
 know, how you did manage to use Xron.
 I have the general Xron problem, that the zope-server is not responding
 anymore after the installation of Xron.



What user do you run Zope as?

There's a problem with Linux where if you start off a thread, then 
change uid in the main thread, the thread that you spawned before will 
remain in the old uid, or unexpected things will happen.

This is what Zope does when you run it as root. Zope initializes its 
products as root, and then changes to user nobody.

You can find out more about this if you search for discussions about 
BIND and Linux.

The solution for Zope and Xron is to run Zope as user nobody. You 
might need to chown the files in your zope directory.

Note that you will not be able to run Zope on a privileged port (below 
1024) if you do this.

The alternative is to hack Zope so that it calls Xron after it has 
changed use to nobody, so Xron can safely spawn its thread as user 
nobody. If you do this, you'll be able to run zope as the root user, 
and Zope + Xron will work running on port 80.

--
Steve Alexander
Software Engineer
Cat-Box limited





___
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 )



RE: [Zope-dev] Xron error!!!

2001-05-24 Thread Loren Stafford

1. If you can use the management interface, you can disable a Xron Scheduled
Method by deleting it from the Schedule catalog or setting its reschedule
interval to null.

2. If you delete (or just rename __init__.py to something else in) the Xron
Product. And restart Zope, there will be no Dispatcher to execute Xron
Scheduled Methods; so looping will stop.

3. The messages in the log file should indicate what kind of error the Xron
Dispatcher is encountering. If this is some kind of environmental condition,
perhaps you can fix it external to Zope and the Dispatcher will stop
looping.

4. The Dispatcher is designed to cancel erring Xron Scheduled Method,
precisely so that it will not go into a loop. The fact that it seems to be
looping indicated some very unusual condition. Please let us know what the
log file says.

5. You can truncate the bloated tail end of a Data.fs file using standard
system tools. I don't remember how right at the moment, but a search in the
mail archives on trucate and data.fs might be fruitful. Don't throw away the
original file, because you might truncate other transactions that you wanted
to save. IOW, finding the right spot to truncate is the trick.

-- HTH
-- Loren


 -Original Message-
 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf
 Of Espen Sorbye Frederiksen
 Sent: Thursday, May 24, 2001 13:06
 To: [EMAIL PROTECTED]
 Subject: [Zope-dev] Xron error!!!


 My Xron file has gone crazy and does not stop running. I have stopped my
 server and started it again, but the xron file is still running. This
 causes the Z2.log file and Data.fs files to
 grow to enormous files and I struggle to be able to log into the system.

 First: Can I delete the overloaded Data.fs file in the var/ directory, or
 will this cause serious trouble?

 Secondly: Is there a cure against that void Xron file of mine or must I
 manually delete it from were my own files are stored?

 Thanks for any kind of help,

 Espen


 ___
 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 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 )



RE: [Zope-dev] Xron error!!!

2001-05-24 Thread Michel Pelletier

On Thu, 24 May 2001, Loren Stafford wrote:

 5. You can truncate the bloated tail end of a Data.fs file using standard
 system tools. I don't remember how right at the moment, but a search in the
 mail archives on trucate and data.fs might be fruitful. 

Use the unix command 'split'.  I immagine cygwin ports this simple program
to windows.

Of course, you can also do the truncation in a couple lines of python, but
I'll leave that as an exercise to the reader. ;)

-Michel


___
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 )



Re: [zope-dev] Xron, suse 6.4

2001-05-17 Thread Homan Els



Hi,

Could  you please send your external python method.  + Product for using in
combination with a cron job.
Because, this can really help me a lot.

Thanks,

Els

Nicholas Lo wrote:

 Sorry man, I still have the same problem :( However, instead I use Xron, I
 write a simple product which is able to call up another python process to
 the cron job. Though this is not a perfect solution, it solve many of my
 problems. My simple 'external' python program does not sit inside the Zope
 framework, so it cannot benefit from Zope's many good features :(

 -- nick

 - Original Message -
 From: Homan Els [EMAIL PROTECTED]
 To: Nicholas Lo [EMAIL PROTECTED]
 Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
 Sent: Wednesday, May 16, 2001 10:55 PM
 Subject: [zope-dev] Xron, suse 6.4

  Hi Nick,
 
  I am having the same problem with installing Xron on my suse 6.4
  machine.
  My question is, are you now running Xron with succes ?  And how did you
  do this ...?
 
  Because, I would like to run this product as well.
 
  Thanks,
 
  Els
  *
  - Original Message -
  From: Nicholas Lo [EMAIL PROTECTED]
  To: [EMAIL PROTECTED]
  Sent: August 18, 2000 12:41 AM
  Subject: xcron test
 
 
   Hi Loren,
  
   I have a problem with installing Xron 0.9 onto my machine. Currently,
   I'm running SuSE Linux 6.4 on a 600MHz/128Mb/20Gb PC. I have followed
   the release note and set the STUPID_LOG_FILE environment variable to
   point the log file, and Xron itself is, of course, resides in the
   /Products directory. When I start Zope, the console looks okay.
  However,
   the browser keeps on loading and loading and could not show the Zope
   management screen. I have also tried Xron on my notebook, which is
   running Win98. Everything works just fine. I just wonder what's gone
   wrong.
  
   Thanks.
  
   Nick
  
  **
 
  --
  ___
  Els Homan
  European Molecular Biology Laboratory (EMBL)
  6, rue Jules Horowitz, B.P.181
  38042 Grenoble cedex 9. France
  [EMAIL PROTECTED] (Email)
  04 76 20 74 66 (Phone)
  04 76 20 71 99 (Fax)
  __
 

--


___
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 )



RE: [Zope-dev] Xron

2001-05-11 Thread Loren Stafford

This is a known problem. Search back thru the archives of [EMAIL PROTECTED] for
Xron and you will find some helpful information. I'll also try to find the
relevant email and forward it to you separately.

-- Loren (lstaffor)

 -Original Message-
 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf
 Of Homan Els
 Sent: Friday, May 11, 2001 06:23
 To: [EMAIL PROTECTED]
 Subject: [Zope-dev] Xron


 Hi,

 I did install the xron product from Istaffor, but it doesn't work.

 I am using Zope - .2.3.2, and installed xron. But, when I want to access
 the zope - server, I get a zero response back.

 Does anyone no the answer to this problem ?

 Thanks,

 Els Homan

 __



 ___
 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 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 )



Re: [Zope-dev] Xron fragility

2000-10-13 Thread Toby Dickenson

Yes, using Client.py was the easiest way to do that. The biggest problem
with Client.py is its dependency on HTTP. If your server is set up to
only accept HTTPS, then you can't use Xron -- not a desirable trade-off.

If security is the problem, you could configure the HTTP part to
listen only on a loopback interface. (yes, this is supported on NT and
windows 95 too)

We need another mechanism that achieves the same goal -- simulating the
environment of a request -- without going all the way back to the
socket.

I always thought the use of Client was very elegent. The performance
hit is negligible, and all the plausible alternatives need many more
lines of code.

Another advantage is that it promotes testability of the scheduled
events since it is easy (trivial) to reproduce the environment in
which they run when scheduled.

Toby Dickenson
[EMAIL PROTECTED]

___
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 )




Re: [Zope-dev] Xron fragility

2000-10-12 Thread Loren Stafford


From: "Kapil Thangavelu" [EMAIL PROTECTED]


[snip]
   Xron has a single dispatcher thread. This thread knows how long to
sleep
   for until the next job needs to run.

 this model has problems when new jobs (for immeadiate execution) are
 entered after the system sleeps. i think it should it taken into
account
 that people will use this dispatching thread to achieve async
operations
 on a request, and that these might need to be done immeadiately.


This is not (or should not be) a problem in current Xron design. The
Dispatcher wakes up early if the Schedule catalog is changed.

-- Loren




___
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 )




Re: [Zope-dev] Xron fragility

2000-10-12 Thread Loren Stafford

  What if you want a small job to be done every 30 seconds?

 I generally don't... I'm satisfied with cron granularity, although
others
 might not be.  Do you have this requirement?

I thought a little about the granularity issue and decided to go with
the most general solution. I have no requirement for 30-second
intervals, but I wanted to avoid support requests from those who might
have such a need.

Also, I have no need for large numbers of scheduled methods. But I used
a heavy-duty data structure (Catalog) and the sleeping dispatcher model,
just so there would be no arbitrary limits that would cause me support
headaches later.


It uses Client.py to run a job.
  
   Why is this?  This doesn't make any sense to me on its face.  Why
not
 just
   call the method from a separate thread?
 
  Which separate thread? Do you create a new ZODB thread? That sounds
as
  if it might use quite a few resources.
 
  Is there a Zope API for making ZODB threads call methods on objects,
as
  signalled by other threads? I'm guessing the easiest way to do that
is
  to use Client.py to make a new http request.


Yes, using Client.py was the easiest way to do that. The biggest problem
with Client.py is its dependency on HTTP. If your server is set up to
only accept HTTPS, then you can't use Xron -- not a desirable trade-off.
We need another mechanism that achieves the same goal -- simulating the
environment of a request -- without going all the way back to the
socket.

-- Loren



___
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 )




Re: [Zope-dev] Xron fragility

2000-10-11 Thread Chris McDonough

Steve,

I am also interested in scheduling... though I haven't looked closely at
Xron.


 The Xron product seems rather "fragile" in use.

 That is, if things go wrong when an Xron DTML Method is triggered, that
 method doesn't get rescheduled.

Does Xron take an optimistic approach to repeating jobs?  In other words,
does it assume every job is a one-time job and that the last duty that a
repeating job performs is to reschedule itself?

 An example of this is that my intranet DNS server needed to be rebooted.
 Xron couldn't look up the appropriate domain name, and stopped working.

 --
 2000-10-11T08:16:34 PROBLEM(100) Products.Xron.Loggerr
 Trigger event: http://my.development.server:4080/my_xron_method
 Trigger time: 2000/10/11 09:14:00 GMT+1
 Failed to trigger event.
 Type=bci.NotAvailable
 Val=host not found (File:
 http://my.development.server/my_xron_method/trigger Line: [])
 None None for None
 --
 2000-10-11T08:19:04 PROBLEM(100) Products.Xron.Loggerr Failed to disarm
 event


 Also, if something bad happens in the Dispatcher thread, the thread
 dies.

What does the Dispatcher thread do?  Does it fire off worker threads?

 Before I leap in and start patching Xron, I'd like to have a discussion
 about how Xron should handle problems.

 My first thought is that on errors in the dispatcher thread, Xron should
 enter an "error state" where it probes every so often to see whether it
 can resume normal operation. The length of time between probes could
 increase with each probe, to give good performance with transient
 problems whilst preventing Xron from choking resources.

What are other threads in Xron doing while the Dispatcher thread is hosed?
What are the other threads?


___
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 )




Re: [Zope-dev] Xron fragility

2000-10-11 Thread Steve Alexander

Chris McDonough wrote:
 
 Steve,
 
 I am also interested in scheduling... though I haven't looked closely at
 Xron.
 
  The Xron product seems rather "fragile" in use.
 
  That is, if things go wrong when an Xron DTML Method is triggered, that
  method doesn't get rescheduled.
 
 Does Xron take an optimistic approach to repeating jobs?  In other words,
 does it assume every job is a one-time job and that the last duty that a
 repeating job performs is to reschedule itself?

It is the Xron DTML Method's responsibility to reschedule itself.
It could be its first duty, however. Then again, as all the work happens
inside a ZODB transaction, it doesn't matter when the reschedule
happens.

 What does the Dispatcher thread do?  Does it fire off worker threads?

Xron has a single dispatcher thread. This thread knows how long to sleep
for until the next job needs to run. It uses Client.py to run a job.
Jobs are Xron DTML Methods. They have a "trigger" method that gets
called through the web from localhost, by the Dispatcher thread.

  Before I leap in and start patching Xron, I'd like to have a discussion
  about how Xron should handle problems.
 
  My first thought is that on errors in the dispatcher thread, Xron should
  enter an "error state" where it probes every so often to see whether it
  can resume normal operation. The length of time between probes could
  increase with each probe, to give good performance with transient
  problems whilst preventing Xron from choking resources.
 
 What are other threads in Xron doing while the Dispatcher thread is hosed?
 What are the other threads?

There are no other threads in Xron.
Xron creates a single thread to do all event dispatching. The work is
done in Zope ZODB threads (or whatever the correct terminology is). The
dispatcher thread communicates with a ZODB thread by using Client to
make a web request.

Xron usually makes requests as the anonymous user. However, I've patched
my Xron to make requests as XronUser by hardcoding (!) the username and
password for that in the RPC.py module of Xron. Then, I've manually
created a XronUser user in my root user folder. I give XronUser the
local roles needed to run methods I want to be scheduled via Xron.

This is not the ideal way to make Xron use authentication. I posted a
proposed design for that to zope-dev in August.

http://lists.zope.org/pipermail/zope-dev/2000-August/006548.html
http://lists.zope.org/pipermail/zope-dev/2000-August/006549.html
http://lists.zope.org/pipermail/zope-dev/2000-August/006550.html

--
Steve Alexander
Software Engineer
Cat-Box limited
http://www.cat-box.net

___
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 )




Re: [Zope-dev] Xron fragility

2000-10-11 Thread Steve Alexander

Chris McDonough wrote:
 
 As a side note, I do not like the fact that Xron requires you to use special
 DTML methods.  I suppose this is a requirement in this architecture due to
 the fact they need to be autocataloged, but I don't really like that feature
 either :-).

I think Xron could work with anything that has "trigger" and "disarm"
methods, that gets put into the Schedule catalog.


   What does the Dispatcher thread do?  Does it fire off worker threads?
 
  Xron has a single dispatcher thread. This thread knows how long to sleep
  for until the next job needs to run.
 
 Do you think this is this any more effective than having a producer thread
 do a lookup every minute to see what jobs are current, after which it should
 put the current jobs in a queue?

What if you want a small job to be done every 30 seconds?

  It uses Client.py to run a job.
 
 Why is this?  This doesn't make any sense to me on its face.  Why not just
 call the method from a separate thread?

Which separate thread? Do you create a new ZODB thread? That sounds as
if it might use quite a few resources.

Is there a Zope API for making ZODB threads call methods on objects, as
signalled by other threads? I'm guessing the easiest way to do that is
to use Client.py to make a new http request.

 I see... would it be naive if I were to say that I think that a scheduler
 should fire off threads of its own and not rely on an external facility to
 run the jobs?

I'd really like to see a scheduler as a standard part of Zope.
I think it would be good to have scheduled methods called from within
Zope, rather then going through http. I don't know enough about how
ZPublisher/ZODB works to know where to start this though.

--
Steve Alexander
Software Engineer
Cat-Box limited
http://www.cat-box.net

___
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 )




Re: [Zope-dev] Xron fragility

2000-10-11 Thread Chris McDonough

  As a side note, I do not like the fact that Xron requires you to use
special
  DTML methods.  I suppose this is a requirement in this architecture due
to
  the fact they need to be autocataloged, but I don't really like that
feature
  either :-).

 I think Xron could work with anything that has "trigger" and "disarm"
 methods, that gets put into the Schedule catalog.

I guess I'm not real real hot on the dependency on a catalog at all.  I'm
having a hard time imagining a situation where you have so many events that
you need to index them -- especially using a ZCatalog.  It just seems like
too many moving parts and overkill for the job.  :-)

   Xron has a single dispatcher thread. This thread knows how long to
sleep
   for until the next job needs to run.
 
  Do you think this is this any more effective than having a producer
thread
  do a lookup every minute to see what jobs are current, after which it
should
  put the current jobs in a queue?

 What if you want a small job to be done every 30 seconds?

I generally don't... I'm satisfied with cron granularity, although others
might not be.  Do you have this requirement?

   It uses Client.py to run a job.
 
  Why is this?  This doesn't make any sense to me on its face.  Why not
just
  call the method from a separate thread?

 Which separate thread? Do you create a new ZODB thread? That sounds as
 if it might use quite a few resources.

 Is there a Zope API for making ZODB threads call methods on objects, as
 signalled by other threads? I'm guessing the easiest way to do that is
 to use Client.py to make a new http request.

Well... AFAIK, there is no such thing as a ZODB thread... there are a number
of Python threads used by Zope.  We'd just fire off another one to perform a
task as part of the thing that takes an event off the queue.  This might be
naive.  I need to try it.

 I'd really like to see a scheduler as a standard part of Zope.
 I think it would be good to have scheduled methods called from within
 Zope, rather then going through http. I don't know enough about how
 ZPublisher/ZODB works to know where to start this though.

I'll need to try to call get_transaction().commit() from a
manually-constructed Python thread fired off from Zope and see what happens.
I think it'll just work.  I'll find out in a few minutes.  :-)



___
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 )




Re: [Zope-dev] Xron fragility

2000-10-11 Thread Chris McDonough

 I'll need to try to call get_transaction().commit() from a
 manually-constructed Python thread fired off from Zope and see what
happens.
 I think it'll just work.  I'll find out in a few minutes.  :-)

Yes, it just works.  :-)



___
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 )




Re: [Zope-dev] Xron fragility

2000-10-11 Thread Chris McDonough

  Do you think this is this any more effective than having a producer
thread
  do a lookup every minute to see what jobs are current, after which it
should
  put the current jobs in a queue?  E.g., as the "run" method of a
separate
  producer thread:

 the same problem applies, a solution might be a timer and a signal
 handler to catch a signal event when a new job is entered into the
 system. events could be managed as some sort of collection of linked
 lists (or whatever ds).

I think this problem is solved by:

- polling for "current" events every 60 seconds *exactly on the 0th second
of the
  minute* (this ensures that stopping and starting the scheduler won't
accidently
  cause a "current" repeating event to fire twice).

- allowing one-time events (which are most likely to need to be executed
immediately)
  to be "current" for the minute implied by the event's timestamp as well as
the minute
  just before that one.  This ensures that an event that has a timestamp
that was "current"
  when entered, but has subsequently been passed due to event polling
overhead
  will be executed (even if it is entered at hh:mm:59.999 or similar).  It
also assumes
  that the scheduling poller will never take more than 60 seconds to poll
all events,
  which is a fairly safe assumption.

- the executor of the event is required to invalidate one-time events once
they've
  been executed (or before they're executed) so they don't get fired twice.

I don't believe there is any need for a signal handler or anything of the
sort, the problem seems to just require careful synchronization.

 i played around with this in a monitor thread and you just can't achieve
 the proper semantics to execute an arbitray zope method. you have to
 recreate the request, response as well as have all the required support
 modules (DTML, tracebacks, etc) to successfully call a method, you are
 in essence reduplicating the publishing machinery. i tried to think of a
 way to get around this but i came up short. you can still access
 variables and simple methods.

This would need to be thought through...  the same problem exists for unit
testing.  :-(

  I see... would it be naive if I were to say that I think that a
scheduler
  should fire off threads of its own and not rely on an external facility
to
  run the jobs?

 the dispatcher thread itself has a connection to the ZODB, its using
 client as RPC to invoke the methods on Publishing threads. Since there
 is a hardcoded limit to ZODB connections firing off more connections
 does not seem like a good idea.

AFAIK, threads will block if they can't get a DB connection.  What risks
does that imply?  Is it a problem?




___
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 )




Re: [Zope-dev] Xron and security

2000-08-23 Thread Steve Alexander

Loren Stafford wrote:
 
 Thanks, Steve.
 
 I have few questions below  8-) (I'm always better with questions than
 answers.)
 
 -- Loren
 
 From: "Steve Alexander" [EMAIL PROTECTED]
  Hi Loren,
 
   I'd be glad to listen to well considered proposals for how Xron should
   handle security.
 
  Consider this a "straw man".
 
 
  On installation, Xron creates a user in the root user folder called
  "XronUser".
 
  Xron is resonsible for setting this user's password. Therefore, it is
  known to both the Xron product, and also to the root user folder.
 
  When a Xron method is run, there is a property that indicates whether it
  is called anonymously, or authenticated as XronUser.
 
 Is there a good reason not to always pass authentication in the request? The
 authentication property would have to be stored in the Schedule catalog, and
 I'd like to keep the Schedule as small as possible.

I can't think of a concrete example of when I'd want to have a Xron
method called with no authentication, when authentication is available.

XronUser would be a privilaged user, and it might be useful to run
scheduled methods without using that privilage. However, in the 2.2
security model, you can drop privilage using proxy roles, so I don't
think your suggestion above is a limitation.

So, no, I can't see a good reason not to always pass authentication in
the request.


  The Xron product could change the password of XronUser every day to a
  new random value.
 
 That's more than folks do to maintain secrecy of the "superuser" password.
 Is the extra trouble worthwhile?

I put this in as an example to illustrate that only the Xron product,
and the Zope root user folder need to know the XronUser password. You're
right, it really doesn't need to change every day :-)

However, there should be manage_... method in Xron that will change the
password to a new random value. Then, if people wanted the password
changed every day, they could use a Xron DTML Method to do it :-)

Perhaps also a button somewhere in the Xron product, or in the Schedule,
to call the manage_resetXronPassword method.

  The domains associated with XronUser could be just localhost.localdomain
  (not sure about this). Or based on whatever the machine's host-name is
  (probably better).
 
 At a virtual-hosted site, how could Xron know what the host-name is?

Xron must know (in some sense) what the host name is now, in order to
use ZClient to call a Xron DTML Method. I guess this is because the URL
to use comes from absolute_url() in Zope.

I'm using Xron 0.0.9 on a virtual-hosted site, and it works.

However, restricting a User's domains doesn't work as I would expect.

The configuration is ZServer behind Apache+ProxyPass. If I put any value
in the "domains" field of a User, other than "127.0.0.1", that User
cannot log in at all. I haven't looked into this particularly yet.


In AccessControl/User.py, login restriction by domain works using
REMOTE_HOST and REMOTE_ADDR from the REQUEST.

I sent myself an email from a Xron DTML Method on two Zope 2.2.1b1
machines, one just running ZServer, the other virtual-hosted as
described above.

In the case of the virtual-hosted server, I get emailed REMOTE_ADDR
127.0.0.1

In the case of the bare ZServer, I get emailed REMOTE_ADDR
my_server's_ip_address

Also, for the virtual server, ZClient seems to choose an appropriate
HTTP_HOST.


So, it seems that the correct domain restriction to use depends on just
how you're using ZServer.

I can think of three ways around this:

  1: Don't bother restricting by domain for XronUser.

  2: Allow a Manager to configure what domains XronUser may log in from.

  3: Use ZClient to call a method in Xron. Xron inspects the REQUEST
passed
 for this method, extracts the REMOTE_ADDR and REMOTE_HOST, and uses
 one of these as the domain restriction.

If you go with 3, there will need to be some button in Xron's management
interface to re-determine the correct domain to use.

If I were writing the software, I'd choose 2, and let the Manager of a
site make the decision.

--
Steve Alexander
Software Engineer
Cat-Box ltd
http://www.cat-box.net

___
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 )




Re: [Zope-dev] Xron and security

2000-08-22 Thread Loren Stafford

Thanks, Steve.

I have few questions below  8-) (I'm always better with questions than
answers.)

-- Loren

From: "Steve Alexander" [EMAIL PROTECTED]
 Hi Loren,

  I'd be glad to listen to well considered proposals for how Xron should
  handle security.

 Consider this a "straw man".


 On installation, Xron creates a user in the root user folder called
 "XronUser".

 Xron is resonsible for setting this user's password. Therefore, it is
 known to both the Xron product, and also to the root user folder.

 When a Xron method is run, there is a property that indicates whether it
 is called anonymously, or authenticated as XronUser.

Is there a good reason not to always pass authentication in the request? The
authentication property would have to be stored in the Schedule catalog, and
I'd like to keep the Schedule as small as possible.

 The Xron product could change the password of XronUser every day to a
 new random value.

That's more than folks do to maintain secrecy of the "superuser" password.
Is the extra trouble worthwhile?

 The domains associated with XronUser could be just localhost.localdomain
 (not sure about this). Or based on whatever the machine's host-name is
 (probably better).

At a virtual-hosted site, how could Xron know what the host-name is?

 Site administrators can assign local roles to XronUser as necessary.

 If Phillip Eby's proposed changes to the access file get included in
 some future version of Zope, XronUser could be included as one of these
 bootstrap users by simply writing to a file.

 --
 Steve Alexander
 Software Engineer
 Cat-Box ltd
 http://www.cat-box.net




___
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 )