[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Pyatcron-devel-list] Cron backend (ex: Got root?)

Subject: [Pyatcron-devel-list] Cron backend (ex: Got root?)
Date: Thu, 13 Nov 2003 11:07:30 +0100

Hi there,

First of all, welcome to you Brian, it's a pleasure to have new members in
this project.

Few things on the project:

1. About CVS commits, I have a good knowledge of it and if you feel
uncomfortable with it, don't hesitate to send me your files through the
list. I have increased the mail size limit to 100Ko.
About CVS, what should be good is to start defining the directory structure,
in order to fill in correctly the CVS repository. What I would suggest is
the following:
pyatcron/docs                     #documentation folder
             /specifications      # documents related to specs and design
             /guides              # user and admin guides
            /pluggins             # pluggins, with two "g" and an "s"
(Julien ;-)
            /glade                # glade files
            /pixmaps              # icons, pictures,sound files,...
        README                    # The standard README file
        INSTALL                   # basic compilation and installation
        COPYRIGHT                 # the GNU GPL release 2.0
        AUTHORS                   # list of authors, contributors, doc
writers, designer,...

2. About the Cron backend, I've spend few hours on Paul Vixie Cron system
(which is the standard one of the Fedora GNU/Linux distribution). I'm
currently writing a spec document (I will publish it on the CVS in the
following hours).
System is very simple: /var/spool/cron contains crontab files for single
users, without the need of any root access, and /etc/crontab contains the
system cron tasks. There is a small difference between users and system file
(system holds process owner name).
So, what I think is that the UI for normal users should simply be an editor
of the user crontab file (Julien: We won't use crontab /tmp/something.txt to
activate a user crontab, but edit directly the crontab file). When using as
root, we should default to system crontab editor, and why not provide a drop
down box of existing user crontab files for edition? What do you think?

3. We are focusing on the Cron tasks, which are recurent tasks. We shouldn't
forget the "at" command, which should be used for "one time task" execution.
In the wizard/property panel, if the user does not activate a "recurence"
option, the software should use the "at" daemon to plan the tasks. This
implies that the Python class that will deal with Cron should be able to
deal with "at" when needed.

So, briefly, I will do the maximum to finish this first spec documents,
which describes the Cron system and how to configure it. Then, based on
that, what would be good is trying to distinguish class definition that will
be the "backend". And for UI designers, think about this ability to edit
user crontab files; As the Cron daemon itself distinguish users and system,
it seems to be usefull and not so hard to implement this in address@hidden

Note that I'm used to write documentations using DocBook. The only thing to
do to get a human readable file is using the db2* softwares (db2pdf
<documentation-filename.sgml> will produce a PDF file).


Xavier Nicolovici

PS: I've found that some of the emails sent through the list are droped by
the Exchange server we have at work. Sorry then if I miss some emails.

-----Message d'origine-----
De : Brian Dee [mailto:address@hidden
Envoyé : jeudi, 13. novembre 2003 00:13
À : pyatcron-devel
Objet : RE: [Pyatcron-devel-list] Got root?

On Wed, 2003-11-12 at 15:57, Childers, Matthew wrote: 
I just did a little research on cron and found this: it looks like all
crontab does is check your syntax so you aren't installing bad crontabs.
>From what I can tell when cron loads it looks in /var/spool/cron for
crontabs of users in /etc/passwd.  Then it also looks for /etc/crontab.
It will look for mod times on it's spool directory and /etc/crontab
every minute, and if one has been modified, then it will reload all
crontabs.  So I tried updating my crontab in /var/spool/cron, as root,
and sure enough it worked.  So it looks like all we will have to do is
edit the /var/spool/cron directly (once we figure out the permissions
problem), and it should work.

Schweet!!! You da man. ; ) So, what do you all think would be best
concerning the permissions? I think that pam would be the best solution. In
my experience at least, I have more jobs run as root than any other user. 

This e-mail contains proprietary information some or all of which may be 
legally privileged. It is intended for the recipient only. If an addressing or 
a transmission error has misdirected this e-mail, please notify the author by 
replying to the e-mail. If you are not the intended recipient you must not use, 
disclose, distribute, copy, print, or rely on this e-mail.
We take reasonable precautions to ensure our e-mails are virus free. However, 
we cannot accept responsibility for any virus transmitted by us and recommend 
that you subject any incoming e-mail to your own virus checking procedures.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]