amandas group membership in FC6?

[Gene Heskett]

On Saturday 25 November 2006 13:37, David G. Miller wrote:
>Gene Heskett wrote:
>> On Saturday 25 November 2006 11:05, David G. Miller wrote:
>>> Gene Heskett <gene.heskett at verizon.net> 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?
>>>
>>> You probably had the default of "Create private group for user" still
>>> checked when you created the user.  When that's checked, the user
>>> gets created and the default group for the user is set to a new group
>>> with the same name as the user.  You should still be able to change
>>> the default group to "disk" for your amanda user.  I run Gnome so I
>>> can't help you with the details.
>>
>> Useing kde-3.5.5, I didn't notice that option in the tools supplied.
>> There was Kusr, and something called user manager.  But the first time
>> I just ran 'adduser amanda'.
>
>See Anne's recent post and correction.  system-config-users lets you
>manipulate group membership, etc.

I'll have to join the chorus of objections here.  That tool doesn't seem 
to be available anyplace on the kmenu.  If thats the 'approved' tool to 
do that, then it needs to be a heck of a lot more accessible than buried 
someplace in an sbin directory that you have to issue a 'locate 
system-config' and see what falls out with a name that *might* indicate 
it what you want.

>>> Dumb question: why didn't you just do a "yum install amanda
>>> amanda-client"?  It's much easier than building amanda and manually
>>> setting up the user, etc.
>>
>> 2 reasons,
>> 1) whats in the repos is often a year or more out of date, and due to
>> the restrictions of the rpm packaging system usually has permission
>> problems that can only be sorted correctly by nuking the rpm and
>> following the build instructions to install the tarball.  This is the
>> first time I've had problems installing a tarball in 6 years!
>>
>> 2) I'm one of the canaries in this particular coal mine, I make and
>> install the new snapshots as often as Jean-Louis releases them, so if
>> there are any gotcha's I can report back the next day on their lists.
>> Thats one of my contributions to your having the worlds best backup
>> software.
>
>I like my backup software to be VERY stable so I'll put up with whatever
>Fedora decides is sufficiently stable to include in their distro.

Fedora has taken perfectly good code, and broke it all to hell making it 
fit in the rpm format, on several occasions.  Often the packager doesn't 
use it himself, and has no idea how to go about throwing it out in the 
street to see if it can survive in traffic.  Sorry if thats a bit too 
candid an opinion, but back when I wanted to start using it, I screwed 
around with whatever version was in rpm at the time for almost 3 months 
fighting with perms, finally discovering the mailing list, and got 
instructions on how to build it.  The result worked the first night.  And 
every night since except for an obscure bug that effected several 
snapshots in a row last spring, and a typo in the srcs of two snapshots, 
probably 5 & 2 years ago.  Stable?  Yes, very.  We have 10x the trouble 
with gnu.org's ongoing screwing with tar, to the extent we now have a 
list of tars that work and tars that will not recover.  In that regard, 
amanda is many times more stable that tar.  But you folks always think 
tar is stable, so you go get the last release, make an rpm out of it, and 
apparently never actually test it in the real world.  We do.  Every 
night...

>From time to time one of the packagers checks into the list, and tries to 
understand the problems.  But then like smoke in a whirlwind, gone again 
for 2 years or more because we think this is a great time to get amanda 
fixed, but your packager has thin skin & boogies.  To get an idea of what 
it can do today, go get the latest snapshot from Jean-Louis's site at 
umontreal, link near bottom of page at amanda.org, unpack it, and read 
the ChangeLog.  I don't even know if it goes back as far as the version 
fedora is currently shipping, but a lot of new capabilities have been 
added since then, with the only backwards breakage being the timestamps 
which once enabled in the wider format aren't compatible with 
pre-timestamped archives that have only a date stamp.

>With regard to this problem:
>> [amanda at coyote GenesAmandaHelper-0.5]$ ls -l /mnt/hdb/home
>> total 36
>> drwxr-xr-x 21     33 disk   4096 Nov  8 23:37 amanda
>> drwx------  3 amanda amanda 4096 Nov  9  2004 elladene
>> drwx------ 14    502    502 4096 Nov 12  2002 elmer
>> drwx------ 36 gene   gene   4096 Nov  9 16:32 gene
>> drwx------  2 root   root   4096 Oct 22  2002 lost+found
>> drwx------  3    503    503 4096 Nov 21  2002 roadrunner
>> drwxr-xr-x 18 gene   gene   4096 Aug 14 03:42 shop
>> drwxr-xr-x 19   1000   1000 4096 Aug 13  2004 shop-gene
>> drwxr-xr-x  6   1002   1002 4096 Dec 14  2005 spamd
>
>find provides a mechanism for finding all of the files with a particular
>UID or GID and then doing whatever you'd like with them.  Something
>along the lines of:
>
>find / -uid 33 -exec chown amanda:disk {} \; -print
>
>The predicate -gid can be used with numeric group IDs.  If you want to
>confirm the changes, use -ok instead of -exec.

Valid for the FC2 tree's, amanda is 501 on FC6.  I probably am overdoing 
it, but I (root) just 'chown -R amanda:disk *' from inside 
the /home/amanda dir.

Point taken though.  Thanks.

>Cheers,
>Dave

-- 
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.