Very Computer

        ... Shaug Evans *8)=

--
O'Shaughnessy Evans |  phone:           |"IBM, backard as ever, flogs a wierdo
Sys Admin, ARDFA    |   (805) 756-1706  | product called AIX, which they deny
Cal Poly State Univ.|  fax:             | stands for 'Ain't UNIX.'  It's, ah,
San Luis Obispo, CA |   (805) 756-1702  | UNIX-compatible?" -UNIX Sys Admin HB

### SCRIPT FOLLOWS:

#!/bin/sh
#set printexitcode

# written by O'Shaughnessy Evans (oevans) in April 1995.
# here's what "dumpscript" does:
# /, /usr, /home, /oracle, and /local are dumped from the NIS host of the
# machine this script is running on.
# /usr/local is dumped from fastlane.
# /home/data is dumped from gridlock.
# All dumps are stored on the tape drive of the NIS dumphost.  Note that
# the usage of "mt" here assumes that this script is being run on that machine.
#

nishost=`ypwhich`
dumphost=airship
admin=oevans
TAPE=/dev/nrst0
REWTAPE=/dev/rst0
DUMP=/usr/etc/dump
RDUMP=/usr/etc/rdump

#
# options passed to dump...
#
#dumpopts=0cuabsdf
dumpopts=0cubsdf
logdir=/home/trans/$admin/admin/backup
blocksize=126
tapesize=6000
density=54000
tries="1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20"

#
# now we're going to back up the file systems
#

# If the current time is greater than $toolate, quit the script.
# This keeps the script from running all day if no tape was in the drive
# when the script was started (presumably by cron)

# don't start if after 8am, or some other time specified as the first
# command line option
if [ $1x = x ]; then
   toolate=8
else
   toolate=$1
fi

time=`date +%H`
if [ $time -ge $toolate ]; then
   echo Good morning!  Too late to start backups now.
   exit 1
fi

echo date: `date`
echo -n "tape status: "
mt -f $REWTAPE status
echo dumphost: $dumphost
echo nishost: $nishost

echo Rewinding tape drive $REWTAPE
until mt -f $REWTAPE rew; do
   echo Waiting for the backup drive to be ready.
   sleep 3600
   mt -f $REWTAPE rew
done

# So now there's a tape in.  Should we continue?
time=`date +%H`
if [ $time -ge $toolate ]; then
   echo Good morning!  Too late to start backups now.
   exit 1
fi

dump_filesystem()
{
   fshost=$1
   dumpfs=$2

   echo "$fshost:$dumpfs... --------------------------------------------------="
   for try in $tries; do
      mt -f $TAPE asf $pos
      if [ $? != 0 ]; then
         mt -f $REWTAPE rew
         sleep 300
         continue
      fi

      if rsh $fshost -l $admin $RDUMP $dumpopts $blocksize $tapesize $density \
       $dumphost:$TAPE $dumpfs; then
         pos=`expr $pos + 1`
         echo "   DONE: $fshost:$dumpfs backed up successfully"
         break
      fi
   done

Quote:}

until mt -f $REWTAPE rewoffl
do
   mt -f $REWTAPE rewoffl
   sleep 300  
done

Quote:>...if admin
>is set to "user", and the backup script is being run on "hostA", the "user"
>needs to have the line "hostA root" in his .rhosts file.  If anybody can
>think of a way to get around this when using dump/rdump/rsh/etc to do
>backups, let me know.  

Plus, it's a very big security hole.  very very big.

Quote:>Also, if anybody notices any real problems with this
>script, or has any suggestions for improvement, feel free to let me know
>also.  Enjoy!

Quote:>echo Rewinding tape drive $REWTAPE
>until mt -f $REWTAPE rew; do
>   echo Waiting for the backup drive to be ready.
>   sleep 3600
>   mt -f $REWTAPE rew
>done

   - Kevin

-Greg

: You should probably build a log file per dump you create, and print
: it out.  Include information like the 'df' listing (so you know
: how large the restore partition needs to be, should you need your
: backup tapes), date, time, and tape id.  Therefore, if the system
: crashes, you can use just the tape and that piece of paper, and
: restore.  You probably also want to store block size information,
: and ANY information you might need, such as the 'restore' command.

        Good idea.  Thanks.

: >echo Rewinding tape drive $REWTAPE
: >until mt -f $REWTAPE rew; do
: >   echo Waiting for the backup drive to be ready.
: >   sleep 3600
: >   mt -f $REWTAPE rew
: >done

: This is odd, anytime I tell the tape to rewind, the mt command
: blocks until it's done.  Does yours operate differently?  What kind
: of drive do you have?  dat, 8mm?  hp, sun, exabyte?  1.2, 2, 3, 5
: gig?
:
:    - Kevin

Mine blocks too.  If there's no tape in the drive, it will return an
error though, and let the system go on with life.  In this case, I
figured this will give the user time to notice that he forgot to
put in the backup tape, and pop one in.  Kind of pointless, I suppose.
A better way to do things would probably be to just exit the script
if the rewind doesn't work.

... Shaug

: create an account called 'dump'  - much more secure.  Make the user
: group operator.  Note that group operator has read privledges on
: your scsi devices (or that group should, anyways)  Note that some
: machines absolutely refuse to allow .rhosts for root.

        Actually, the group that owns my tape devices is 'staff'.  I'm running
        SunOS 4.1.3, and that's what they installed as.  I suppose it would be
        a good idea to make my tape devices read-and-write only by the 'staff'
        group, then, instead of everybody, eh?  (Except, of course, that some
        of my users need to use the tape drives.)

        So, I made a user called dumper.  His group is staff, in order to be
        the same as the tape devices.  Since there's a root cron job to execute
        the backup script, I figured it made sense to make the script setuid and
        setgrpid so that it looks like dumper is running it instead of root.
        Now, when I rsh to another machine to dump a filesystem, I can do it
        as dumper.  In this case, I only need dumper to have a .rhosts file
        with any entries that it expects to get dump requests from.  This
        keeps the danger-word "root" out of anybody's .rhosts file.  Do
        you see any difference in security between making the backup script
        setuid dumper and executing it as root, and just having a crontab entry
        for dumper?  My instinct tells me that it's a little safer to use a
        crontab entry for dumper, but I can't see any reason why (except that
        I've been told setuid scripts are inherently insecure).

        So, did I correctly interpret your reply about creating a separate
        "dump" user?

        Thanks for you help & comments,

                ... Shaug

:       So, I made a user called dumper.  His group is staff, in order to be
:       the same as the tape devices.  ...

        'dumper' doesn't need to belong to the same group as the tape drives;
        he needs to belong to the same group as the hard drives (or whatever
        devices I'm backup up from).  So the script seems to work well now
        that dumper is in the group 'operator' (which the hard drives belong
        to).

        Thanks again for everybody's comments and suggestions.

        ... Shaug

Quote:>    (Except, of course, that some
>    of my users need to use the tape drives.)

Quote:>    So, I made a user called dumper.  His group is staff, in order to be
>    the same as the tape devices.  Since there's a root cron job to execute
>    the backup script, I figured it made sense to make the script setuid and
>    setgrpid so that it looks like dumper is running it instead of root.
>    Now, when I rsh to another machine to dump a filesystem, I can do it
>    as dumper.  In this case, I only need dumper to have a .rhosts file
>    with any entries that it expects to get dump requests from.  This
>    keeps the danger-word "root" out of anybody's .rhosts file.  Do
>    you see any difference in security between making the backup script
>    setuid dumper and executing it as root, and just having a crontab entry
>    for dumper?  My instinct tells me that it's a little safer to use a
>    crontab entry for dumper, but I can't see any reason why (except that
>    I've been told setuid scripts are inherently insecure).

If your system only supports crontabs for root, you can execute commands
under another person's uid by one of two methods that I know.

1.  If your 'su' command has the -c option, use it (man su)
    A sample command would be:  su dumper -c /etc/my_dump_script

2.  If not, try this:
    echo "/etc/my_dump_script -myargs" | su dumper

One of those should work on your system so that you can run cronjobs under
another uid.

Hope this helps,
Nate

Quote:

>:   So, I made a user called dumper.  His group is staff, in order to be
>:   the same as the tape devices.  ...

>    'dumper' doesn't need to belong to the same group as the tape drives;
>    he needs to belong to the same group as the hard drives (or whatever
>    devices I'm backup up from).  So the script seems to work well now
>    that dumper is in the group 'operator' (which the hard drives belong
>    to).

>    Thanks again for everybody's comments and suggestions.

>    ... Shaug

And yes, my reason for group operator is that you need to be able to
read the HDs.

   - Kevin

Quote:>Here's a backup script I wrote for the network of SunOS 4 machines that I
>manage.  I've put a decent amount of work in getting my backups to this
>point, so I figured other people might find this script as useful as I have.
>One note to make is regarding the variable "admin" set and used in the
>script.  Whoever "admin" is needs to have a line in their .rhosts allowing
>root on the backup machine to use their account.  In other words, if admin
>is set to "user", and the backup script is being run on "hostA", the "user"
>needs to have the line "hostA root" in his .rhosts file.  If anybody can
>think of a way to get around this when using dump/rdump/rsh/etc to do
>backups, let me know.  Also, if anybody notices any real problems with this
>script, or has any suggestions for improvement, feel free to let me know
>also.  Enjoy!
>    ... Shaug Evans *8)=
>### SCRIPT FOLLOWS:

I hacked one together myself.  It's short (no error checking), but
I can put it on any system and it will backup whatever is mounted.
Hope someone finds it useful.

#!/bin/sh
#File name: /usr/adm/bin/do.backups
#could be fired off out of cron if you make sure a new tape is always available
#Author: J.C. Webber III
#Date last modified: Thu Aug 31 08:45:29 PDT 1995

PATH="$PATH:/usr/local/bin:/usr/adm/bin";export PATH

#VARIABLES
# This first variable is vendor specific.
# SGI = df -l
# Mips = df -t local
# Sun = df -t 4.2
# HP = bdf -l
DF='df -l'
# Tape devices are vendor specific also.
REWTAPE=/dev/rmt/tps0d4
TAPE=/dev/rmt/tps0d4nrnsv
# list filesystems to skip, seperated by '|'
EXCLUDE='tmp|var|news'

# Get a list of mounted filesystems to backup.
FS=`$DF|egrep -v Filesystem\|Total\|$EXCLUDE|awk '{print $7}'`

# position the tape at BOT
mt -t $REWTAPE rewind

# output a header to the tape to identify what filesystems are on it
cat - <<EOF | dd of=$TAPE
`hostname`
`date`
Level = 0
`$DF|egrep -v $EXCLUDE`
EOF

# do the actual backups
for fs in $FS
do
        echo "Doing $fs"
        dump 0udsbf 54000 26000 32 $TAPE $fs
done

# rewind the tape
mt -t $REWTAPE rewind
# eject the tape
mt -t $REWTAPE unload
exit 0

--

"Comparing Dos to UNIX is like comparing a mix-master to a chef's kitchen"

      You ever tried the backup scripts that came with the gnu-tar package?
   They are called level-0 and level-1 and does the job very well I think!

   Lars

: If your system only supports crontabs for root, you can execute commands
: under another person's uid by one of two methods that I know.

: 1.  If your 'su' command has the -c option, use it (man su)
:     A sample command would be:  su dumper -c /etc/my_dump_script

   Yeah, this is what I was doing in the dumpscript before the suggestion
   to create a "dump" user was offered.  Cron on our system allows
   crontabs from users other than root, so I just use an entry for
   "dumper" to execute the script.

   ... Shaug