Bug 125505 - tell users to use 'crontab -e'
tell users to use 'crontab -e'
Product: Red Hat Satellite 5
Classification: Red Hat
Component: Documentation (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Clay Murphy
Red Hat Satellite QA List
: Documentation
: 123741 131442 (view as bug list)
Depends On:
Blocks: 123072
  Show dependency treegraph
Reported: 2004-06-08 05:43 EDT by Patrick C. F. Ernzer
Modified: 2009-08-19 23:05 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-09-07 08:47:44 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
mbox with a cron e-mail and a traceback report email (89.15 KB, application/octet-stream)
2004-06-10 03:57 EDT, Patrick C. F. Ernzer
no flags Details
simple script showing how to detect if a file descriptor is attached to a tty (263 bytes, text/plain)
2004-06-10 08:22 EDT, Chip Turner
no flags Details

  None (edit)
Description Patrick C. F. Ernzer 2004-06-08 05:43:43 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510

Description of problem:
section '8.4. Automating Synchronization' tells the user about cron
editing in a convulted way.

We support 'crontab -e' on RHEL 2.1 and should tell users about it.

Version-Release number of selected component (if applicable):
RHNsatellite(EN)-3.2-RHI (2004-03-11T15:06)
as I have no cheap way of accessing our intranet here, I did not check
if this error persists in the most current version.

How reproducible:

Steps to Reproduce:
1. read section 8.4
2. follow the steps

Actual Results:  user is told to redirect to a file, edit said file
and reimport, this is not elegant.
Whatsmore, IMHO the word 'root' should not be put in, even in that

Expected Results:  Telling the user about 'crontab -e'

Additional info:

Text suggestion:

To do this, edit the crontab as root.

  crontab -e

Add the satellite-sync job to the list. For instance, the following
item sets the synchronization to occur every night at 11:10 p.m. and
have the resulting changes emailed to the traceback mail recipient:

  10 23 * * * /usr/sbin/satellite-sync --email

When you save and quit in the editor, the crontab is activated. You
can verify the crontab with

  crontab -l

Really nice would be a little box that tells the user about $EDITOR
like follows.

The editor that is used by 'crontab -e' is by default vi. If you set
the variable EDITOR, another editor can be used. For example:

  export EDITOR=gedit

will use gedit to edit the crontab. This affects all programs that use
the variable EDITOR.
Comment 1 Patrick C. F. Ernzer 2004-06-09 03:41:32 EDT
one more thing, the crontab line should read 

10 23 * * * /usr/sbin/satellite-sync --email >/dev/null 2>/dev/null

Otherwise the user gets 2 e-mails, one from cron (which is hard to
read due to the printed hash marks) and one from the --email flag.
Yes, these two could be different recipients, but in most cases they
will not be.

Probably best to explain wht the redirection of stdout and stderr is
Comment 2 Chip Turner 2004-06-09 08:30:51 EDT
satellite-sync should only do the hashmark thing if stdout is a tty;
otherwise it shouldn't print them for the reason you point out

will --email report any tracebacks and such encountered in the running
of satellite-sync?
Comment 3 Clay Murphy 2004-06-09 18:30:30 EDT
Alright, I've merged Patrick's suggestions with those made by Chip in
a separate email (see below). In short, I suggest using crontab -e to
add a random sync job, like so:
0 1 * * * root perl -le 'sleep rand 9000' && satellite-sync --email

Also, I included Patrick's note about changing text editors. I left
the --email option as it stands since we're not sure we want to
redirect its output.

You guys holler if I got this wrong. Otherwise, I'm aligning this bug
to the 340 release, setting it to QA_READY and mentioning that it
kinda negates the fix for bug 123741.
Comment 4 Mihai Ibanescu 2004-06-09 19:45:47 EDT
Clay, that line of crontab is not valid in crontab -e.
crontab -e uses the user's crontab (i.e. root's) as opposed to
/etc/crontab. Therefore, 'root' should be taken out.

from 'man 5 crontab':

       The format of a cron command is very much the V7 standard, with
a  num-
       ber  of upward-compatible extensions.  Each line has five time
and date
       fields, followed by a user name if this is  the  system 
crontab  file,
       followed  by  a  command.   Commands  are  executed by cron(8)
when the
Comment 5 Clay Murphy 2004-06-09 19:56:15 EDT
Thanks for the catch, Mihai. I know I already said to edit the crontab
as root, but in my ignorance and haste, I assumed this inclusion was
part of the instruction for perl.

Regardless, 'root' has been removed from that line. For completeness,
I'm pasting in the email I got from Chip on this subject, since I said
I would in my last comment:

-------- Original Message --------
Subject: 	Re: Sat-sync cron timing
Date: 	Tue, 08 Jun 2004 22:35:58 -0400
From: 	Chip Turner <cturner@redhat.com>
To: 	Clay Murphy <cmurphy@redhat.com>
CC: 	Mihai Ibanescu <misa@redhat.com>, Chris MacLeod
<cmacleod@redhat.com>, Todd Warner <taw@redhat.com>
References: 	<40C4C549.8000300@redhat.com>

Tell users to use 'crontab -e' not edit crontab directly.

It would be nice to tell users to do this:

perl -le 'sleep rand 3600' && satellite-sync --email

That gives a one hour random factor to when it runs and helps protect
our servers.  Even better is to add a simple --random-delay param to
satellite-sync that will do a little sleep before the rest of it
runs.  That way we can tell people to invoke it that way.

Instead of editing crontab or using crontab -e, we could provide users
with a sample cron.d script like this and tell them to put it in
/etc/cron.d if they want nightly sync:

0 1 * * * root perl -le 'sleep rand 9000 && satellite-sync --email

That will run between 1am and 3:30am local box time randomly each
night.  Generally extension software (like ours) should drop files in
/etc/cron.d instead of editing crontab or having users manually add
crontabs.  We could even put that sample crontab in /usr/share/docs
somewhere as an example or whatnot.


Clay Murphy <cmurphy@redhat.com> writes:

> Howdy gents,
> Todd suggested I write you. I'm trying to address bug 123741 opened by
> Andrew Anderson to resolve conflicts between automated satellite-sync
> jobs and cron.daily. See the attached log of my talk with Todd.
> As a result, I've written and emphasized a note in the Automating
> Synchronization section of the Sat. Install Guide section that says
> not to set up sync cron jobs for the top of the hour. Do you have
> anything else to offer?
> Thanks,
> -Clay
Comment 6 Chip Turner 2004-06-09 22:01:53 EDT
the discrepency here is that /etc/cron.d files have the user to run as
following the five 'when' columns, whereas /etc/crontab and a user's
crontab have assumed owners.

if we provide a sample on the file system, it should be in the cron.d
format so someone can just copy it into place (w/o having to edit
other system files).  if we only provide reference in the help files,
then either is fine
Comment 7 Patrick C. F. Ernzer 2004-06-10 03:55:59 EDT

I agree with Chip in that we really should provide a drop in for cron.d

Until then, the docs fix as in comment #3 (without 'root' of course)
looks good to me, but I still thinks we should include comment #1

Should I open separate bugs for:
  a) a not printing hash marks switch to satellite-sync (that would
help when using screen as well)?
  b) a --randomize <minutes> flag to satellite-sync?

As I am on site until next Thursday, responses on my side may be slow
until then.


Comment 8 Patrick C. F. Ernzer 2004-06-10 03:57:03 EDT
Created attachment 101023 [details]
mbox with a cron e-mail and a traceback report email

To Chip: attached is a mbox with 2 messages, the first is the e-mail that was
generate when not redirecting stdout and stderr to /dev/null. The second is a
report where the sat did traceback (the proxy it uses was down), so we can
really redirect to /dev/null. I did replace the machine name in the e-mails
with the string PRIVACY as this is a customer machine.
Comment 9 Chip Turner 2004-06-10 08:21:00 EDT
todd, attached is a script that lets you see if something is a tty or
not.  run it to test its output, doing things like test-tty.py <
/dev/null, test-tty.py | cat, etc.  should be sufficient for satsync
Comment 10 Chip Turner 2004-06-10 08:22:12 EDT
Created attachment 101025 [details]
simple script showing how to detect if a file descriptor is attached to a tty
Comment 11 Clay Murphy 2004-06-10 13:20:47 EDT
Alright, I don't know what the results of the rest of the discussion
will be, but Patrick convinced me; I've added his stdout and stderr
redirection and explained in the subsequent paragraph this prevents
duplicating a more easily read message from satellite-sync.

Also, I'm copying Todd on this bug since I don't know if he's
explicitly involved with it yet.
Comment 12 Todd Warner 2004-09-07 08:44:07 EDT
Also see bug 131442
Comment 13 Todd Warner 2004-09-07 08:46:27 EDT
*** Bug 131442 has been marked as a duplicate of this bug. ***
Comment 14 Todd Warner 2004-09-07 08:47:44 EDT
Comment 15 Todd Warner 2004-09-07 08:48:52 EDT
*** Bug 123741 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.