usr.sbin/cron/doc/CONVERSION

   1 $FreeBSD: src/usr.sbin/cron/doc/CONVERSION,v 1.4 1999/08/28 01:15:52 peter Exp $
   2 $DragonFly: src/usr.sbin/cron/doc/CONVERSION,v 1.2 2003/06/17 04:29:53 dillon Exp $
   3
   4 Conversion of BSD 4.[23] crontab files:
   5
   6 Edit your current crontab (/usr/lib/crontab) into little pieces, with each
   7 users' commands in a different file.  This is different on 4.2 and 4.3,
   8 but I'll get to that below.  The biggest feature of this cron is that you
   9 can move 'news' and 'uucp' cron commands into files owned and maintainable
  10 by those two users.  You also get to rip all the fancy 'su' footwork out
  11 of the cron commands.  On 4.3, there's no need for the 'su' stuff since the
  12 user name appears on each command -- but I'd still rather have separate
  13 crontabs with seperate environments and so on.
  14
  15 Leave the original /usr/lib/crontab!  This cron doesn't use it, so you may
  16 as well keep it around for a while in case something goes wakko with this
  17 fancy version.
  18
  19 Most commands in most crontabs are run by root, have to run by root, and
  20 should continue to be run by root.  They still have to be in their own file;
  21 I recommend /etc/crontab.src or /usr/adm/crontab.src.
  22
  23 'uucp's commands need their own file; how about /usr/lib/uucp/crontab.src?
  24 'news' also, perhaps in /usr/lib/news/crontab.src...
  25
  26 I say `how about' and `perhaps' because it really doesn't matter to anyone
  27 (except you) where you put the crontab source files.  The `crontab' command
  28 COPIES them into a protected directory (CRONDIR/SPOOL_DIR in cron.h), named
  29 after the user whose crontab it is.  If you want to examine, replace, or
  30 delete a crontab, the `crontab' command does all of those things.  The
  31 various `crontab.src' (my suggested name for them) files are just source
  32 files---they have to be copied to SPOOLDIR using `crontab' before they'll be
  33 executed.
  34
  35 On 4.2, your crontab might have a few lines like this:
  36
  37         5 * * * *   su uucp < /usr/lib/uucp/uudemon.hr
  38         10 4 * * *  su uucp < /usr/lib/uucp/uudemon.day
  39         15 5 * * 0  su uucp < /usr/lib/uucp/uudemon.wk
  40
  41 ...or like this:
  42
  43         5 * * * *   echo /usr/lib/uucp/uudemon.hr | su uucp
  44         10 4 * * *  echo /usr/lib/uucp/uudemon.day | su uucp
  45         15 5 * * 0  echo /usr/lib/uucp/uudemon.wk | su uucp
  46
  47 On 4.3, they'd look a little bit better, but not much:
  48
  49         5 * * * *   uucp  /usr/lib/uucp/uudemon.hr
  50         10 4 * * *  uucp  /usr/lib/uucp/uudemon.day
  51         15 5 * * 0  uucp  /usr/lib/uucp/uudemon.wk
  52
  53 For this cron, you'd create /usr/lib/uucp/crontab.src (or wherever you want
  54 to keep uucp's commands) which would look like this:
  55
  56         # /usr/lib/uucp/crontab.src - uucp's crontab
  57         #
  58         PATH=/usr/lib/uucp:/bin:/usr/bin
  59         SHELL=/bin/sh
  60         HOME=/usr/lib/uucp
  61         #
  62         5 * * * *   uudemon.hr
  63         10 4 * * *  uudemon.day
  64         15 5 * * 0  uudemon.wk
  65
  66 The application to the `news' cron commands (if any) is left for you to
  67 figure out.  Likewise if there are any other cruddy-looking 'su' commands in
  68 your crontab commands, you don't need them anymore: just find a good place
  69 to put the `crontab.src' (or whatever you want to call it) file for that
  70 user, put the cron commands into it, and install it using the `crontab'
  71 command (probably with "-u USERNAME", but see the man page).
  72
  73 If you run a 4.2-derived cron, you could of course just install your current
  74 crontab in toto as root's crontab.  It would work exactly the way your
  75 current one does, barring the extra steps in installing or changing it.
  76 There would still be advantages to this cron, mostly that you get mail if
  77 there is any output from your cron commands.
  78
  79 One note about getting mail from cron: you will probably find, after you
  80 install this version of cron, that your cron commands are generating a lot
  81 of irritating output.  The work-around for this is to redirect all EXPECTED
  82 output to a per-execution log file, which you can examine if you want to
  83 see the output from the "last time" a command was executed; if you get any
  84 UNEXPECTED output, it will be mailed to you.  This takes a while to get
  85 right, but it's amazingly convenient.  Trust me.
  86