IMHO, on BSD, the culturally right way to set up AMANDA is to conform
to the BSD Way as much as possible. This means:
use dump(8). On FreeBSD 4.2 and NetBSD 1.5, /sbin/dump is sgid tty,
but not suid:
-r-xr-sr-x 2 root tty 331452 Nov 20 07:06 /sbin/dump
leave the permissions on the raw devices intact, as 640 group
operator, e.g.
crw-r----- 2 root operator 13, 0x00020000 Jan 15 13:25 /dev/da0s1a
crw-r----- 1 root operator 17, 0 Dec 6 18:08 /dev/rsd0a
put the user that amanda runs as in group operator. I run amanda as
'amanda', but some people run amanda as 'operator'. It really
doesn't matter.
Note that all you have to do for this part is put amanda/operator in
group operator. The original scheme called for the people who ran
dump and changed 9-track tapes to be in group operator; these people
had permission to read the raw disks, but not necessarily root.
All that said, I concur with the other debugging hints. Note
particularly that there are two levels of permission checking:
amandad on the client choosing whether to accept the check/dump request
the operating system deciding whether to permit amanda to run dump
and read from the disk
In almost all cases I've seen, the problem is the first part. Once
you get by that, amcheck will get you clear diagnostic output - one of
the functions of selfcheck is to verify that user amanda can
read/write dumpdates and read the raw disks (when the service is
dump).
For example, I just chmod'd a raw disk to 0600 on a client, ran
amcheck, and got this output:
Amanda Backup Client Hosts Check
--------------------------------
ERROR: [hostname]: [can not access /dev/rsd0a (sd0a): Permission denied]
Client check: 6 hosts checked in 1.556 seconds, 1 problem found.
Greg Troxel <[EMAIL PROTECTED]>
