On Saturday 25 November 2006 22:29, Frank Smith wrote:
>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)?
It was originally the same as amanda, 501::501 but I've edited that to
501::6 now. I've also SGID'd the amanda home dir. It ran alright this
morning I believe. But the real answer will be when Jean-Louis releases
the next snapshot.
>See what that number maps to in /etc/group. I'm betting it
>goes to an 'amanda' group and not the 'disk' group.
There was not, and still is not, a group named amanda, just the amanda
entry in the disk line.
>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.
Nope, just 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
Thanks Frank. We'll see if its fixed in due time I guess.
--
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.
