Re: amandas group membership in FC6?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.


[Index of Archives]     [Current Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [Yosemite Photos]     [KDE Users]     [Fedora Tools]     [Fedora Docs]

  Powered by Linux