Showing posts with label Shell scripts. Show all posts
Showing posts with label Shell scripts. Show all posts

Saturday, September 27, 2008

using Crontab scheduler

Using The CRON Unix/Linux Program Scheduler

CRON is a Unix/Linux program scheduler. It'll automatically execute commands on your server according to a schedule you specify.

Almost anything that needs to be done according to a schedule and that doesn't need direct human supervision can be set up with Unix/Linux CRON.

To create a CRON schedule, put a list of commands and their schedules in a plain text file. This text file is called the "CRON table." Upload the CRON table to your server. Then telnet or SSH to your server.

Once at your server, type CRONtab filename replacing "filename" with the file name of the CRON table you uploaded to your server. This will register your CRON table with the CRON system.

If you want to verify that the CRON system has indeed registered your CRON table, type:

CRONtab -l

(the letter el, not the number 1). That will display a list of the current registered CRON schedules.

The CRON Table
The CRON table has six fields. The first five fields are schedule time fields and the sixth is the command itself:

1. The minute of the hour the command shall execute.

2. The hour the command shall execute.

3. The day of the month the command shall execute.

4. The month the command shall execute.

5. The day of the week the command shall execute.

6. The command.

All six fields are on one line. There is one space between each field. Only field 6 may contain spaces within itself. Here is an example of what a schedule might look like:

10 3 1 1 * /usr/bin/perl /www/cgi-bin/script.cgi

Comments in the CRON table, ignored by the server, are lines beginning with the # symbol.



The Five Schedule Time Fields
The order of the fields might seem backward. Most of us are used to thinking hour before minute, as in 9:45. Also month before day, as in June 21. However, the fields are minute before the hour and day before month, with the day of the week as the fifth field.

Here are the first five fields and their allowed values:

Allowed

Field Values

----- -------

Minute 0-59

Hour 0-23

Day of the Month 1-31

Month 1-12 (also 3-letter month abbr)

Day of the Week 0-7 (also 3-letter day of week abbr)

Each of the above values can also contain ranges, lists, and step values. If a field contains an asterisk (*), it tells CRON to accept all allowed values.

Example

-------

Range 1-3

List 3,5,7

Step 15-45/5 (another example: */5)

For explanation, let's assume the above is in the Minute field.

Range 1-3 is a range of 1 through 3, inclusive, and means 1, 2, or 3 minutes after the hour.

List 3,5,7,9 means 3, 5, 7, or 9 minutes after the hour. Step 15-45/5 means every 5 minutes while the clock is 15 through 45 minutes after the hour, inclusive.

Step */5 means every five minutes while the clock is 0 through 59 minutes after the hour (* meaning all allowed values, which would be range 0-59 minutes).



Hypothetical Situations
For purposes of explaining each field, let's use three hypothetical situations.

1. A script must run one minute before the end of every year.

2. A script must run at 2:20 every Tuesday morning.

3. A script must run every 15 minutes from 9 in the morning to 9 in the evening. And it must run every 30 minutes the rest of the time. (Note, this requires two schedule lines.)



The Minute Field
The minute is the first field. The values examples of range, list, and step, above, illuminate the versatility built into the system.

For each of the three hypothetical situations, the minute field would be:

1. 59

2. 20

3a. */15

3b. */30



The Hour Field
The hour is the second field. The allowed values are the same as the minute field, 0-59.

For each of the three hypothetical situations, the hour field would be:

1. 23

2. 2

3a. 9-21

3b. 0-8,22-23



The Day Of the Month Field
The day of the month is the third field. The allowed values are 1 through 31.

For each of the three hypothetical situations, the day of month field would be:

1. 31

2. *

3a. *

3b. *



The Month Field
The month is the fourth field. The allowed values are 1 through 12. Instead of digits, 3-letter abbreviations may be used:

1 2 3 4 5 6 7 8 9 10 11 12

jan feb mar apr may jun jul aug sep oct nov dec

For each of the three hypothetical situations, the month field would be:

1. 12

2. *

3a. *

3b. *



The Day Of the Week Field
The day of the week is the fifth field. The allowed values are 0 through 7. Digits 1 through 6 represent Monday through Saturday, respectively. On some systems, 0 represents Sunday and on others 7 represents Sunday. On a few systems, both 0 and 7 represent Sunday. Your hosting company can tell you which applies to your server. Or, you may wish to try 0 and see if the script runs on Sunday. If it doesn't, try 7. Instead of digits, 3-letter abbreviations may be used:

0 1 2 3 4 5 6 7

sun mon tue wed thu fri sat sun

For each of the three hypothetical situations, the day of week field would be:

1. *

2. 2

3a. *

3b. *



The Hypothetical Situations Schedules
For each of the three hypothetical situations, the complete schedule (with an example sixth field) would be:

1. 59 23 31 12 * /usr/bin/perl /www/cgi-bin/script.cgi

2. 20 2 * * 2 /usr/bin/perl /www/cgi-bin/script.cgi

3a. */15 9-21 * * * /usr/bin/perl /www/cgi-bin/script.cgi

3b. */30 0-8,22-23 * * * /usr/bin/perl /www/cgi-bin/script.cgi



The Sixth Field, The Command
The sixth field is the actual command that will be executed according to the schedule specified in the first five fields. The sixth field includes any parameters to be passed to the command.

When the command is a Perl script, you might or might not need to specify the location of Perl as part of the command. Your hosting company can tell you which applies for your server.

Here are a three command examples:

/www/cgi-bin/script.cgi

/usr/bin/perl /www/cgi-bin/script.cgi

/usr/bin/perl /www/cgi-bin/script.cgi response.txt



The first example is a Perl script without the location of Perl being specified.

The second example is the same script, but this time the location of Perl is specified.

The third example includes a parameter. Here, the parameter is "response.txt," which might be the file name that an autoresponder is to send, assuming the autoresponder script is named script.cgi. When a script requires parameters, it's instructions should clearly indicate what the parameters are and what they represent.



On-line Documentation for CRON and CRONtab
You can type either or both of the following commands at the telnet or SSH prompt for the on-line CRON and CRONtab manuals. (It is assumed that any hosting company with CRON available also has the manuals on-line.)

man CRON

man CRONtab

Those two on-line manuals provide a lot of technical information.



A Practice Script
You can use the following script to practice what you have learned.

#!/usr/bin/perl
# Verify above line is correct for your server.

use strict;

my @date = localtime;

$date[4]++;

$date[5] += 1900;

$date[5] = substr($date[5],2);

open W,">track.txt";

print W "$date[2]\:$date[1]\:$date[0] on ";

print W "$date[4]\/$date[3]\/$date[5]\n";

# Above is USA style date. For European
# style, reverse digits 4 and 3. close W;
# end of practice script



The script will create a file named "track.txt" and print the time and date. Every time it runs, it creates a new file. The script is specifically made for running from the telnet/SSH prompt or with CRON, not for a browser. (Running this script in your browser will generate an internal server error. That's because the script never returns anything to the browser.)

When the script is uploaded, you can test it from the telnet/SSH prompt. To test, type the command you'll be using when you create the CRON schedule.

Once the script runs correctly, create the CRON schedule. You may wish to use */3 or something similar in the minute field while testing. As you now know, that will launch the script every three minutes; then the longest you'll wait between tests is three minutes.

Once the test is over, remove the test script from the CRON schedule. Launching a script, whether with CRON or through a browser, does take some server resources.

Tuesday, July 29, 2008

Site backup shell script

Backup Site Directory

Place this script backup.sh in your DOCROOT for each of your sites.


MYSITES : /home/username/sites/askapache.com
MYSITE : askapache.com
MYSITEBK: askapachecom
MYUSER : username
MYGROUP : groupname
MYGROUPS:
MYFNAME : askapachecom-01x16x07.tgz
MYFNAMEX: askapachecom-01x16x07-08x43.tgz
MYBNAME : /home/username/backups/SITES/askapache.com/askapachecom-01x16x07.tgz
MYBNAMEX: /home/username/backups/SITES/askapache.com/askapachecom-01x16x07-08x43.tgz
MYBDIR : sites/askapache.com/


The Script


#!/bin/sh

# SETTINGS
export MYSITES=`pwd -L`
export MYSITE=`basename ${MYSITES}`
export MYSITEBK=${MYSITE%%.*}${MYSITE#*.}
export MYUSER=`whoami`
export MYGROUP=`groups`

#====================== GLOBAL VARIABLES =================================
# FILES #
export MYFNAME=${MYSITEBK}-`date +%mx%dx%y.tgz`
export MYFNAMEX=${MYSITEBK}-`date +%mx%dx%y-%Hx%M.tgz`
export MYBNAME=${HOME}/backups/SITES/${MYSITE}/${MYFNAME};
export MYBNAMEX=${HOME}/backups/SITES/${MYSITE}/${MYFNAMEX};
export MYBDIR=sites/${MYSITE}/

# COLORS #
cR='\E[31;1m'
cG='\E[32;1m'
cY='\E[33;1m'

#====================== GLOBAL FUNCTIONS =================================
# pheader #
function pheader {
cd ${HOME}
clear
tput sgr0
echo -e "$cG\n\n"
echo ' _____________________________________________________________________ '
echo ' | |'
echo ' | |'
echo ' | |'
echo " | SiteBack v.1.1 ${MYSITE}"
echo ' | |'
echo ' | |'
echo ' | |'
echo ' _____________________________________________________________________ '
echo -e "$cG\n\n"
tput sgr0
sleep 3
}

# pfooter #
function pfooter {
tput sgr0
echo -e "$cG"
echo ' _____________________________________________________________________ '
echo ' | |'
echo ' | SiteBack COMPLETED SUCCESSFULLY |'
echo ' _____________________________________________________________________ '
echo -e "\n\n\n"
tput sgr0
cd ${OLDPWD}
}

#====================== MAIN =================================

pheader

echo -e "$cY\n @@@ CHECK FOR PRESENCE OF BACKUP FILE"
if [ -e $MYBNAME ] ; then
echo -e "$cR !!! FILE FOUND.. CHANGING DESTINATION"
MYBNAME=${MYBNAMEX}
else
tput sgr0
fi
echo -e "$cG\n [ DONE ]\n\n"

echo -e "$cY\n @@@ CHANGING FILES TO CORRECT GROUP AND USER PERMISSIONS... "
echo -e "$cG\n [ DONE ]\n\n"
sleep 2

echo -e "$cY\n @@@ BACKUP IN PROGRESS... "
sleep 5

tput sgr0
tar -czf ${MYBNAME} ${MYBDIR}
echo -e "$cG\n [ DONE ]\n\n"

pfooter

exit 0;

Automated folder backup shell script

!/bin/bash
#
# GNU Free Documentation License 1.2

# .mysnapshot
# |-- hourly.0 (one hour ago)
# |-- nightly.0 (one night ago)
# |-- weekly.0 (one week ago)
# `-- monthly.0 (one month ago)
#

### Source and Destination
source=$HOME/sites
dest=$HOME/.mysnapshot/${1:-hourly}.0/`basename $source`

### Make Nice - lower load
renice 19 -p $$ &>/dev/null

### Non-Absolute links, check source exists
cd $source || exit 1

### Hide errs, copy dirtree
find . -depth -print0 2>/dev/null | cpio -0admp $dest &>/dev/null

cd $OLDPWD

exit 0




mysnapshot.sh crontab entries

MAILTO=user@domain.com
# MY SNAPSHOTS
@hourly /home/user/scripts/mysnapshot.sh hourly &>/dev/null
@midnight /home/user/scripts/mysnapshot.sh nightly &>/dev/null
@weekly /home/user/scripts/mysnapshot.sh weekly &>/dev/null
@monthly /home/user/scripts/mysnapshot.sh monthly &>/dev/null

Thursday, July 3, 2008

Shell script to auto restart web server httpd if it goes down

First set the crontab as follows
*/5 * * * * /path/to/script.sh >/dev/null 2>&1

Shell script as follows

#!/bin/bash
# Apache Process Monitor
# Restart Apache Web Server When It Goes Down
# -------------------------------------------------------------------------
# RHEL / CentOS / Fedora Linux restart command
RESTART="service httpd restart"

# uncomment if you are using Debian / Ubuntu Linux
#RESTART="/etc/init.d/apache2 restart"

#path to pgrep command
PGREP="/usr/bin/pgrep"

# find httpd pid
$PGREP httpd

if [ $? -eq 0 ]
then
# restart apache
$RESTART
fiA better and more reliable solution is monit monitoring software for restarting services such as mysql, apache and sendmail under UNIX

Change password

#!/usr/local/bin/expect -f
# Password change shell script, tested on Linux and FreeBSD
# ----------------------------------
# It need expect tool. If you are using Linux use following command
# to install expect
# apt-get install expect
# FreeBSD user can use ports or following command:
# pkg_add -r -v expect
# ----------------------------------
# If you are using linux change first line
# From:
#!/usr/local/bin/expect -f
# To:
#!/usr/bin/expect -f
# display usage
if {$argc!=2} {
send_user "usage: $argv0 username password \n"
exit
}
# script must be run by root user
set whoami [exec id -u]
if {$whoami!=0} {
send_user "You must be a root user to run this script\n"
exit
}
#
set timeout -1
match_max 100000
# stopre password
set password [lindex $argv 1]
# username
set user [lindex $argv 0]
# opem shell
spawn $env(SHELL)
# send passwd command
send -- "passwd $user\r"
expect "assword:"
send "$password\r"
expect "assword:"
send "$password\r"
send "\r"
expect eof