pyatcron-devel-list
[Top][All Lists]
Advanced

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

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


From: Julien Olivier
Subject: Re: [Pyatcron-devel-list] Cron backend (ex: Got root?)
Date: Thu, 13 Nov 2003 12:20:51 +0000

On Thu, 2003-11-13 at 10:07, NICOLOVICI Xavier wrote:
> Hi there,
> 

Hi Xavier.

> 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.

I'd like that.

> 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
>         /src
>             /pluggins             # pluggins, with two "g" and an "s"
> (Julien ;-)

Eh eh, actually it's "plugins", with one "g" and as "s" :)

>             /glade                # glade files
>             /pixmaps              # icons, pictures,sound files,...

Sound files ? I don't we'll need sound, will we ?

>         README                    # The standard README file
>         INSTALL                   # basic compilation and installation
> procedure
>         COPYRIGHT                 # the GNU GPL release 2.0
>         AUTHORS                   # list of authors, contributors, doc
> writers, designer,...
> 

Will the python scripts be in the root folder (pyatcron) or in a "src"
folder ? A possible idea (maybe stupid) would be to have the main python
script in the root folder and other python scripts in "src" or "lib".

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

The thing is that, on my Fedora distribution at least, the user files in
/var/spool/cron/ are really owned by root and are not user-writeable
other than by using the "crontab" command. So I fail to understand how
you want to edit those files directly if they are not user-writeable.

>  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?
> 

yes, that should be possible. What I'd like, though, is the possibility
to have two distinct programs. One called "pyatcron" and one called
"pyatcron-admin". The pyatcron program would handle users' crontabs. If
launched as root, it would handle root's crontab. Pyatcron-admin would
need root acess (using PAM) and would handle system cron jobs.

Why differentiate them ? because users should'nt have to type su -c
"pyatcron" to edit system jobs. With 2 distinct programs, we can have
one for normal users and one needing authentification. More over, we can
have one entry in the preferences (or system tools) menu, and one in the
system settings menu.

We could even have a slightly different UI for the admin tool than for
the user tool.

> 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.
> 

OK, so the question is the same as for cron. How does a non-root user
add a job to his /var/spool/at ?

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

I think I hadn't understood you. You mean that you want user to ba able
to access their crontab file directly from pyatcron ? That would be
easily done. But I fear a problem: as tasks are generated by task
plugins, each task will generate a line in crontab. So what happens if a
user modifies the crontab and, then, saves. Will the crontab file be
modified again by the tasks he declared ? Ir will the tasks be
synchronized by the crontab file (much much harder, if not impossible) ?

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

DocBook sounds great.

> Regards,
> 
> 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.
> 

Aargh... that could be a problem. Please check the archives to keep in
sync then.

-- 
Julien Olivier <address@hidden>




reply via email to

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