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