On Saturday 25 November 2006 20:42, Frank Smith wrote:
>Gene Heskett wrote:
>> Greetings;
>>
>> Despite the fact that the user 'amanda' is a member of the group
>> 'disk', all compilations and new files generated by the user amanda
>> seem to be owned by amanda:amanda instead of the expected amanda:disk.
>>
>> The end result is that many of my backup operations are failing
>> because the amanda utility doesn't have perms to delete or write to
>> files actually owned by amanda:disk.
>>
>> I just went thru all the directory trees amanda needs to access and
>> chowned everything back the way its supposed to be, but then I built
>> the 20061124 tarball just now, and everything is still owned by
>>
>> amanda:amanda.
>>
>> From my /etc/group file:
>> disk:x:6:root,amanda
>>
>> So I blew it away, called up KUsr and verified that amanda was indeed
>> a member of the group disk. Even deleted the user and re-added it and
>> made sure this new copy of amanda was a member of the group disk.
>>
>> Then as "amanda", I unpacked it again and rebuilt it, but I still have
>> the same problem. Because none of the files are owned by amanda:disk,
>> the end result is several megs of dead, can't do a thing code that I'd
>> just as well not bother with the 'make install'.
>>
>> Anything that amanda has touched over the last 4 days since I started
>> running it again has been converted to being owned by amanda:amanda,
>> and if the file existed, and was to be deleted as part of the
>> housekeeping, was not because the old file was owned by amanda:disk.
>> So my backups are being slowly trashed because the indice files are
>> not updatable.
>>
>> Whats the deal with FC6 and its owner:group handling? Am I setting up
>> the user wrong or what?
>
>Perhaps something changed the amanda user's primary group in
>/etc/passwd? When new files are created, the user/group set are
>the ones in passwd, and /etc/group is only consulted by the system
>if the user is not the owner of the directory, then it checks if it
>is in the same group (assuming you have group write perms).
>
>Another possibility is that you are forcing the group amanda runs as
>in xinetd to be 'amanda' and not 'disk'.
>
I hadn't thought of that, but the amanda file in the xinetd.d dir is the
same one I used for FC2:
# default = off
#
# description: Part of the Amanda server package
# This is the list of daemons & such it needs
service amanda
{
only_from = coyote.coyote.den # gene.coyote.den
disable = no
socket_type = dgram
protocol = udp
wait = yes
user = amanda
group = disk
groups = yes
server = /usr/local/libexec/amandad
server_args = -auth=bsd amdump amindexd amidxtaped
}
service amandaidx
{
disable = no
socket_type = stream
protocol = tcp
wait = no
user = amanda
group = disk
groups = yes
server = /usr/local/libexec/amindexd
}
service amidxtape
{
disable = no
socket_type = stream
protocol = tcp
wait = no
user = amanda
group = disk
groups = yes
server = /usr/local/libexec/amidxtaped
}
According to the amanda coders, this is correct usage. Is it not now?
Thanks Frank.
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2006 by Maurice Eugene Heskett, all rights reserved.
