Bug 125505 - tell users to use 'crontab -e'
tell users to use 'crontab -e'
Status: CLOSED CURRENTRELEASE
Product: Red Hat Satellite 5
Classification: Red Hat
Component: Documentation (Show other bugs)
unspecified
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:
Environment:
Last Closed: 2004-09-07 08:47:44 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
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:
Always

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

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

Chip

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

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.

RU

PCFE
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
Golden!
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.