Solved

good practices/required entries for a crontab file for user root

Posted on 2010-11-20
7
517 Views
Last Modified: 2013-12-27
what are the good practices/required entries for a crontab file for user root?

[open solaris ver: 5.11]
0
Comment
Question by:rastafaray
[X]
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
7 Comments
 
LVL 22

Expert Comment

by:Rick Hobbs
ID: 34180688
Most important are a regular backup and sar.
0
 

Author Comment

by:rastafaray
ID: 34180812
TY rickhobbs.

what is a "sar" pl?
0
 
LVL 16

Expert Comment

by:Joseph Gan
ID: 34183968
Plase look at
 
# man sar

and

# man crontab
0
Three Reasons Why Backup is Strategic

Backup is strategic to your business because your data is strategic to your business. Without backup, your business will fail. This white paper explains why it is vital for you to design and immediately execute a backup strategy to protect 100 percent of your data.

 
LVL 22

Expert Comment

by:Rick Hobbs
ID: 34184735
System Activity Reporter.  Can be used to create reports similar to Perfmon in Windows.  Memory usage, disk usage, threads in use, etc, etc, etc.
0
 
LVL 9

Accepted Solution

by:
expert_tanmay earned 500 total points
ID: 34202588
*Always* version control everything you do in crontab. It provides an instant backup, accountability, easy rollbacks, and a history.

The entries in your crontab should be in some sort of order. What order depends on your preferences and on the nature of your entries, but some options might include:
   * Put the most important at the top.
    * Put the ones that run more often at the top.
    * Order by time they run.
    * Order by job groups (e.g. all entries dealing with the mail system).

It's very important to test out your final product. Cron entries have a nasty habit of working from the command line, but failing when called by cron, usually due to missing environment variables or path problems.

Don't be afraid to call external scripts. Anything even slightly complex should not be in the crontab itself, but inside of an external script called by the crontab. Make sure you name the script something very descriptive, such as flush_older_iptables_rules.pl. While a script means another separate dependency to keep track of, it offers many advantages:
   * The script can be run standalone outside of cron.
    * Different crontabs call all share the same script.
    * Concurrency and error handling is much easier.
    * A script can filter output and write cleaner output to log files.

In addition to using non-root accounts whenever possible, it is also very important to make sure that someone is actively receiving emails for each account that has cronjobs.

Heavily document your crontab file. The top line should indicate how the entries are organized.

Whenever possible, use some other account than root for cron entries. Not only is is desirable in general to avoid using root, it should be avoided because:
   * The root user probably already gets lots of email, so important cron output is more likely to be missed.
    * Entries should belong to the account responsible for that service, so Nagios cleanup jobs should be in the Nagios user's crontab. If rights are needed, consider granting specific sudo permissions.
    * Because root is a powerful account, its easier to break things or cause big problems with a simple typo.

Resist strongly the urge to add 2>/dev/null to the end of your entries.

Unfortunately, cron emails all output to you by default - both stdout and stderr. This means that the output tends to be overloaded - both informational messages and errors are sent. It's too easy for the error messages to get lost if you tend to to receive many informational cron messages. Even well-intentioned messages tend to cause problems over time, as you grow numb (for example) to the daily message showing you the output of a script that runs at 2 AM. After a while, you stop reading the body of the message, and then you mentally filter them away when you see them - too much mail to read to look that one over. Unfortunately, that's when your script fails and cron sends an error message that is not seen.

Don't put passwords into your crontab.

Both for safety and sanity, use the full paths to all commands.
0
 

Author Closing Comment

by:rastafaray
ID: 34252231
THANK YOU
0

Featured Post

Technology Partners: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Why Shell Scripting? Shell scripting is a powerful method of accessing UNIX systems and it is very flexible. Shell scripts are required when we want to execute a sequence of commands in Unix flavored operating systems. “Shell” is the command line i…
The purpose of this article is to demonstrate how we can use conditional statements using Python.
Get a first impression of how PRTG looks and learn how it works.   This video is a short introduction to PRTG, as an initial overview or as a quick start for new PRTG users.
In a recent question (https://www.experts-exchange.com/questions/29004105/Run-AutoHotkey-script-directly-from-Notepad.html) here at Experts Exchange, a member asked how to run an AutoHotkey script (.AHK) directly from Notepad++ (aka NPP). This video…

688 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question