|
Re: amcheck/amdump fails (sometimes) to amanda client
2004-05-20 17:46:08
Paul Bijnens wrote:
Gene Heskett wrote:
> This is the wrong group, the group may be bin, backup or disk, but it
> should have essentially root rights to the system. A gid <=10 is
> desireable.
But it does work if you use gnutar instead of dump, or if
you add amanda to group disk as additional group (and maybe add
"groups = yes" in xinetd.conf)
Actually, on a FreeBSD system there usually isn't a group called "disk".
There is, however a group called "operator" that has read permission on the
disks. In this case, inetd (FreeBSD does not nomally use xinetd) was adding
the operator group as specified in /etc/group, so it worked.
Maybe that is indeed the cause of the problems, but I don't
understand how running it manually on the server is different from
crontab. In both cases is the client invoked through xinetd.
You're right. It makes no difference. When it's run from the tape server's
crontab, it appears that amandad doesn't even get invoked. I'm still
looking for the difference.
By the way, on RedHat systems, the group disk has read AND WRITE permissions
on the disk devices. This is not only unnecessary, but a bad idea as well.
Read permissions are sufficient to perform a dump.
--
Steven Schoch
_________________________________________________________________
FREE pop-up blocking with the new MSN Toolbar ? get it now!
http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/
|
|
|
