Bug 60962

Do you propose the same for each other users crontabs?  What if they don't have
write access to /etc, this could cause problems.  Why not just backup the
/var/spool/cron directory as well as /etc.

I don't see this as an issue.

The reason this is an issue is that taring (-xzf) up /root and /etc SHOULD
backup all the configuration settings other than those of users. 

If it is a personal crontab it should be kept under that persons home directory.
The other place that make sense to keep the root users crontab is under the
/root directory. Perhaps you might want symbolic links back to the /etc tree.

The point is that the design of the directory structure should help separate out
backup items - all user configs should be some where under /home and all system
wide configs should be under /etc. The other one that needs more thought is
weather the hardware specific items (/etc/sysconfig) should be in their own
directory tree along with the rpm database.  

Using this system one SHOULD be able to load a new system  load any unique
software then restore /etc, /root, and  /home and everything should run like it
did before. The uniformity of the use of directories is what makes RedHat my
distribution of choice; any thing that causes settings to be under a variety of
directory trees reduces maintainability. 

I would also like to point to one of RedHats own documents
http://www.redhat.com/docs/manuals/linux/RHL-7.2-Manual/ref-guide/s1-filesystem-fhs.html

And The FHS standard keepers that RedHat has endorsed.

http://www.pathname.com/fhs/2.2/fhs-5.1.html

seem to support this as an issue. 

You will see that Var is for /var contains variable data files. This includes
spool directories and files, administrative and logging data, and transient and
temporary files.

Further reading will point out that /var/spool contains data which is awaiting
some kind of later processing a definition that crontab fails to meet. Dont
you think that the crontab file is a configuration file? 

I dont see how crontab, as a user editable file that defines system operation
can belong in /var/spool with the definition given by FHS. 

Actually, I feel that crontabs *are* files that are waiting for processing.  And
they are variable, and dynamic.  Plus, since each user's crontab will go to
/var/spool/cron/  this lends itself to easier backup procedures.

I still don't see this as an issue, but I guess we will wait for an official
answer from Red Hat.  Since it has been the same way since time out of mind, I
doubt it will change any time soon.

The crontab files in /var/spool, are NOT user editable crontab files.
They are files submitted to cron which are spooled.  The system
crontab file is /etc/crontab, and it runs the various jobs in the
/etc/cron.* directories as needed.  Per user crontab files are not
stored in any particular location, or with any particular filename.

The files in /var/spool are just spool files of the user's current
submission.

I missed this the first time through...

>Further reading will point out that /var/spool contains data which is awaiting
>some kind of later processing a definition that crontab fails to meet. Don't
>you think that the crontab file is a configuration file? 

The crontab files in /var/spool are spooled cron jobs, much like when
a user prints something, it gets spooled into /var/spool/lpd or wherever.

They are absolutely _not_ configuration files.

This is getting into semantics here  the crontab file looks like a duck,
sounds like a duck, has webbed feet, quacks like a duck  Are you really saying
that crontab not a configuration file?  Of course not ; because it is. The fact
is, a user configures a crontab. And one CAN edit the crontab (remember
crontab e  )

There is no intention to edit print spool or mail data  that is what makes it
spool data  it is finished data,  not intended to be changed.  Its data cued up
on its way somewhere. You just cant say the same about a crontab. 

/var/spool is for DATA that is awaiting processing  -- now if you want to say
that the crontab is data waiting to be processed  then so is every script and
program. E-mail is data waiting to be delivered; print spool is data waiting for
a printer.  A crontab is semi-permanent (like all conf files) and never goes
away  even through reboot. 

As someone who has spent time in both the M$ and  Linux worlds, I see that
redhat has quite an advantage in the ease of recreating a system if there has
been respect to the FHS.  I just dont like seeing a sloppy foundation laid here. 

The argument that it would be problematic in a network/logon environment fails
to pass the waving arms test  I can see there is a problem  but to mess up the
FHS with a kluge workaround is not a good long term solution.  

I can imagine a system where users crontabs would be in something like a
/home/user/.etc  directory and then read by the cron daemon (at boot and also
after any user does a crontab e) when it would be COPIED into a combined cron
list under /var/cron  (or should it be in /proc or /tmp?). 

What I am really saying, is regardless how many times you choose to reopen
this bug report, it will be reclosed NOTABUG, because it is not a bug, and
will not be changed.

If you want this changed, then contact the Linux Standards Base, and other
relevant standards bodies and wail your story to them.  We do not change
things like this on the whim of a user who doesn't understand the system,
merely because the user is persistant and continously reopens bug reports.

Bugzilla isn't a technical support forum, nor is it a forum for debate,
or discussion.  It is a bug report and bug tracking database, and this
is not a bug report.  End of story.