Hi,

I have two solaris 9 boxes:
SunOS bmsapp01 5.9 Generic_118558-06 sun4u sparc SUNW,Sun-Fire-V440
and
SunOS bmsdb01 5.9 Generic_118558-06 sun4u sparc SUNW,Sun-Fire-V440.
The bmsapp01 server has a SDLT tape drive attached to it. I am trying to perform a remote ufsdump to the tape drive on bmsapp01 from bmsdb01.
I have performed this on other Sun server combinations successfully (backing up the database server to the tape drive on the application server) using the syntax from the command line as root on the database server:

ufsdump 0fuc - <filesystem> | rsh <applicationserver> dd of=/dev/rmt/0cbn

These machines are behind a very secure firewall so there has not been a problem with creating the .rhosts file in / on the application server.

However on the two Sun servers listed above, performing a remote ufsdump gives:

# ufsdump 0fuc - / | rsh bmsapp01 dd of=/dev/rmt/0cbn
DUMP: Date of this level 0 dump: Fri 09 Jun 2006 02:32:21 PM BST
DUMP: Date of last level 0 dump: the epoch
DUMP: Dumping /dev/md/rdsk/d10 (bmsdb01:/) to standard output.
dd: /dev/rmt/0cbn: open: Permission denied
DUMP: Mapping (Pass I) [regular files]
DUMP: Mapping (Pass II) [directories]
DUMP: Writing 63 Kilobyte records
DUMP: Estimated 10872978 blocks (5309.07MB).
DUMP: Dumping (Pass III) [directories]
DUMP: Broken pipe
DUMP: The ENTIRE dump is aborted.

The remote tape drive can be contacted from the database server and its status can be checked:

# rsh bmsapp01 mt -f /dev/rmt/0cbn status
Quantum Super DLT 320 tape drive:
sense key(0x7)= Write Protected residual= 0 retries= 0
file no= 0 block no= 0

The tape drive can be written to from the application server correctly using the ufsdump syntax:

bash-2.05# ufsdump 0fuc /dev/rmt/0bcn /
DUMP: Date of this level 0 dump: Fri 09 Jun 2006 02:41:04 PM BST
DUMP: Date of last level 0 dump: the epoch
DUMP: Dumping /dev/md/rdsk/d10 (bmsapp01:/) to /dev/rmt/0bcn.
DUMP: Mapping (Pass I) [regular files]
DUMP: Mapping (Pass II) [directories]
DUMP: Writing 63 Kilobyte records
DUMP: Estimated 16548348 blocks (8080.25MB).
DUMP: Dumping (Pass III) [directories]
DUMP: Dumping (Pass IV) [regular files]
DUMP: 16.95% done, finished in 0:48
DUMP: 34.01% done, finished in 0:38
DUMP: 47.56% done, finished in 0:33
DUMP: 61.64% done, finished in 0:24
DUMP: 77.43% done, finished in 0:14
etc...

So the tape can be written to locally, and its status can be checked remotely. However it cannot be written to remotely. The ufsdump is performed as root.
The entry in /.rhosts on bmsapp01 is + + and the permissions on /dev/rmt/0cbn are:

bash-2.05# ls -lt /dev/rmt/0cbn
lrwxrwxrwx 1 root other 45 May 31 2005 /dev/rmt/0cbn -> ../../devices/pci@1c,600000/scsi@1/st@5,0:cbn

The permissions on /devices/pci@1c,600000/scsi@1/st@5,0:cbn are:

bash-2.05# ls -lt /devices/pci@1c,600000/scsi@1/st@5,0:cbn
crw-rw-rw- 1 root sys 33,221 Jun 9 02:55 /devices/pci@1c,600000/scsi@1/st@5,0:cbn

Does anyone have any idea of why there is a permissions problem when performing a remote ufsdump and how this can be overcome?

Thanks in anticipation,

J

I believe that you can directly specify the name of the remote drive in the ufsdump command. Try this:
Check the man page of ufsdump for more details.

This syntax:

ufsdump 0fuc <appserver>:/dev/rmt/0cbn <filesystem>

works on one of our combinations of application and database server.
However on the application and database server combination that has caused me to open this thread, this what happens:

# mt -f bmsapp01:/dev/rmt/0cbn status
bmsapp01:/dev/rmt/0cbn: No such file or directory

Please note though, on the same server as mentioned originally in the call:

# rsh bmsapp01 mt -f /dev/rmt/0cbn status
Quantum Super DLT 320 tape drive:
sense key(0x0)= No Additional Sense residual= 0 retries= 0
file no= 0 block no= 0

The rsh method is successful in getting the mt -f status command to work.
However it is not possible to get ufsdump to work using rsh:

# ufsdump 0fuc - / | rsh bmsapp01 dd of=/dev/rmt/0cbn
dd: /dev/rmt/0cbn: open: Permission denied
DUMP: Date of this level 0 dump: Sun 11 Jun 2006 03:36:51 PM BST
DUMP: Date of last level 0 dump: the epoch
DUMP: Dumping /dev/md/rdsk/d10 (bmsdb01:/) to standard output.
DUMP: Mapping (Pass I) [regular files]
DUMP: Mapping (Pass II) [directories]
DUMP: Writing 63 Kilobyte records
DUMP: Estimated 10872978 blocks (5309.07MB).
DUMP: Dumping (Pass III) [directories]
DUMP: Broken pipe
DUMP: The ENTIRE dump is aborted.

So, I can get the remote working on other combinations of application and database server, but not this one.

Does anyone have any suggestions?

Thanks in anticipation,

Jabberwocky

Check the permissions on the device files. You may want to set the permissions to world write and test if the backup is getting fired.

I checked the permissions on the device files:

bash-2.05# rsh bmsapp01 ls -lt /dev/rmt/0cbn
lrwxrwxrwx 1 root other 45 May 31 2005 /dev/rmt/0cbn -> ../../devices/pci@1c,600000/scsi@1/st@5,0:cbn
bash-2.05# rsh bmsapp01 ls -lt /devices/pci@1c,600000/scsi@1/st@5,0:cbn
crw------- 1 root sys 33,221 Jun 10 03:21 /devices/pci@1c,600000/scsi@1/st@5,0:cbn

I changed the permisssions on /devices/pci@1c,600000/scsi@1/st@5,0:cbn on the application server to:

bash-2.05# rsh bmsapp01 ls -lt /devices/pci@1c,600000/scsi@1/st@5,0:cbn
crwxrwxrwx 1 root sys 33,221 Jun 10 03:21 /devices/pci@1c,600000/scsi@1/st@5,0:cbn

However it is still not possible to get a remote ufsdump working by using either method:

bash-2.05# ufsdump 0fuc bmsapp01:/dev/rmt/0cbn /
DUMP: Date of this level 0 dump: Mon 12 Jun 2006 10:52:43 AM BST
DUMP: Date of last level 0 dump: the epoch
DUMP: Dumping /dev/md/rdsk/d10 (bmsdb01:/) to bmsapp01:/dev/rmt/0cbn.
DUMP: Mapping (Pass I) [regular files]
DUMP: Mapping (Pass II) [directories]
DUMP: Writing 63 Kilobyte records
DUMP: Estimated 10872978 blocks (5309.07MB).
DUMP: /dev/rmt/0cbn: Permission denied
DUMP: NEEDS ATTENTION: Cannot open `bmsapp01:/dev/rmt/0cbn'. Do you want to retry the open?: ("yes" or "no") yes
DUMP: /dev/rmt/0cbn: Permission denied
DUMP: NEEDS ATTENTION: Cannot open `bmsapp01:/dev/rmt/0cbn'. Do you want to retry the open?: ("yes" or "no") no
DUMP: The ENTIRE dump is aborted.

or:

bash-2.05# ufsdump 0fuc - / | rsh bmsapp01 dd of=/dev/rmt/0cbn
DUMP: Date of this level 0 dump: Mon 12 Jun 2006 10:55:26 AM BST
DUMP: Date of last level 0 dump: the epoch
DUMP: Dumping /dev/md/rdsk/d10 (bmsdb01:/) to standard output.
dd: /dev/rmt/0cbn: open: Permission denied
DUMP: Mapping (Pass I) [regular files]
DUMP: Mapping (Pass II) [directories]
DUMP: Writing 63 Kilobyte records
DUMP: Estimated 10872978 blocks (5309.07MB).
DUMP: Dumping (Pass III) [directories]
DUMP: Broken pipe
DUMP: The ENTIRE dump is aborted.

Thanks,

J

Doh!

The problem is with the tape type; the tape drive is a SDLT 320. This takes SDLT Tape 1 data cartridges, I was using a DLT 4 cartridge which the tape drive will recognise, but only use as READ ONLY. Using SDLT Tape 1 tapes allows the tape to be written to.

However there was only one way to perform the ufsdump:

bash-2.05# mt -f bmsapp01:/dev/rmt/0cbn status
bmsapp01:/dev/rmt/0cbn: No such file or directory
bash-2.05# ksh
# set -o vi
# ufsdump 0fuc - / | rsh bmsapp01 dd of=/dev/rmt/0cbn
DUMP: Date of this level 0 dump: Mon 12 Jun 2006 04:48:38 PM BST
DUMP: Date of last level 0 dump: the epoch
DUMP: Dumping /dev/md/rdsk/d10 (bmsdb01:/) to standard output.
DUMP: Mapping (Pass I) [regular files]
DUMP: Mapping (Pass II) [directories]
DUMP: Writing 63 Kilobyte records
DUMP: Estimated 10872978 blocks (5309.07MB).
DUMP: Dumping (Pass III) [directories]
DUMP: Dumping (Pass IV) [regular files]
DUMP: 56.44% done, finished in 0:07
DUMP: 10872916 blocks (5309.04MB) on 1 volume at 5092 KB/sec
DUMP: DUMP IS DONE
DUMP: Level 0 dump on Mon 12 Jun 2006 04:48:38 PM BST
10872917+2 records in
10872918+0 records out

Thanks,

J