Gene Heskett wrote:
> 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).
So what group does amanda have in /etc/passwd (the number in the fourth
field)? See what that number maps to in /etc/group. I'm betting it
goes to an 'amanda' group and not the 'disk' group. It's also possible
that you have two amanda lines in your passwd file, or two groups in
/etc/group that map to the same number (or the same group name in twice
with two different numbers). In those cases the first match is what
the system uses, but it can certainly be confusing to debug if you
don't notice the other one.
Your system is finding an amanda group for the amanda user somewhere,
it's just a mater of finding out where it is getting it from. I would
suggest looking into whether you might have compiled it in, but I know
you always use your same build script, so I'll just mention it as a
possibility for future readers of the archives.
>>
>> 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?
That looks correct to me, so I'd look more into the passwd/group
files mentioned above.
Frank
--
Frank Smith fsmith AT hoovers DOT com
Sr. Systems Administrator Voice: 512-374-4673
Hoover's Online Fax: 512-374-4501
|
