Amanda-Users

Re: [UPDATE] How to control which tape is next?

2003-10-22 21:03:49
Subject: Re: [UPDATE] How to control which tape is next?
From: Gene Heskett <gene.heskett AT verizon DOT net>
To: amanda-users AT amanda DOT org
Date: Wed, 22 Oct 2003 20:54:52 -0400
On Wednesday 22 October 2003 14:45, Matt Hyclak wrote:
>On Wed, Oct 22, 2003 at 11:07:17AM -0400, Gene Heskett enlightened 
us:
>> >FWIW, I have made packages of 2.4.4-p1 that are pretty much the
>> > RH packages with a couple tweaks to the .spec file. Namely,
>> > there are 2 variables at the top of the .spec to define your
>> > tapeserver and your config name. The problem with packaging
>> > binary files for amanda is that you have to resort to using
>> > localhost where a hostname is required so the thing will at
>> > least mostly work. Because of this, I put the variable at the
>> > top of the spec file and recommend people rebuild the source rpm
>> > after making the appropriate changes to the .spec.
>> >
>> >If anyone is interested in this, you can get it from (sorry it
>> > wraps):
>> > http://www.math.ohiou.edu/mirror/casit/contrib/9/SRPMS/amanda-2.
>> >4.4 p1-2mrh3.src.rpm
>> >
>> >To install it "correctly" goes something like this:
>> >
>> >$ rpm -i amanda-2.4.4p1-2mrh3.src.rpm
>> >edit the .spec file (in /usr/src/redhat/SPECS if you build as
>> > root)
>>
>> Q: Does this automaticly set the ownerships and perms in the built
>> rpm?  Amanda should be built by a non-priviledged user, then
>> installed by root.  Otherwise the perms get fubared.  I ask
>> because I've never done it this way to test.
>
>Yes, it goes through after the files are built and sets the
> appropriate ownership and permissions correctly. It assumes the
> user will be called amanda, which is the "right way" to do it on a
> RH system.

Great Matt.  And that pretty much takes care of my first objection.  
Even better if the installer actually setup that user, and made that 
user a member of the needed group too.

The second would be taken care of if the building of the src to an rpm 
it was trained to barf voluminously and exit if the config (the spec 
file) still says 'localhost' anyplace in it.  A bit arbitrary maybe, 
but for gnubies, a "barked knuckle" the first time sure beats no 
recovery when the gnubie needs it 6 months on down the log.

>> >$ rpmbuild -ba amanda.spec
>> ># rpm -Uvh amanda-2.4.4p1-2mrh3.i386.rpm ...
>> >      (in /usr/src/redhat/RPMS/i386 if you build as root)
>> >
>> >You don't have to build amanda as root from the rpm (and I
>> > recommend that you don't just on principle). I've fed these
>> > changes up to Jay and he's created bugzilla entries (or at least
>> > was going to. If he hasn't, maybe this can be his poke in the
>> > ribs...) to make it a little easier to build amanda for your
>> > location and still have the package be managed instead of
>> > resorting to *cringe* tarballs. ;-)
>> >
>> >Matt
>>
>> Just out of curiosity, why the cring at the thought of tarballs?
>
>In general because you often have little control over what a 'make
> install' does. Many applications out there ignore PREFIX settings
> and the like and you end up with files barfed all over your system.
> I don't think amanda is that way, but I don't want to take that
> chance :-)

Nah, amanda is clean in that regard.  That "make install" has been 
tweaked, then the tweaks have been tweaked until its as solid as any 
long term project should be.  In my lingo, thats the equivalent of 
"10 foot tall and bulletproof".  :-)

But you are right too, many otherwise great projects fail because the 
Makefile.in was just an afterthought, not always valid for oddball 
hardware etc.

>> There are good and valid reasons to use the rpms and have a
>> managed install.  In amanda's case, where the correct perms and
>> such are required for proper overall functionality, and which may
>> vary according to the users whims, something the rpms don't seem
>> to handle right, I've found the tarballs to be much the easier way
>> to maintain amanda.  And I've learned the hard way to never, ever,
>> let the up2date utility anywhere near your amanda install.  One
>> early version, if not the first one released, must have been a bit
>> buggy though.  I did not check anything amanda related, but it did
>> it anyway.  Took me 2 days to clean up the mess that made.
>
>Yes, amanda is one thing I make sure yum ignores since I upgrade
> that by hand myself.
>
>> We also spend about 25% of our support efforts here on this list
>> trying to convince gnubies that they cannot run it reliably using
>> localhost.  Most probably have acquired the localhost habit from
>> an rpm install.  The README etc in the tarballs carry warnings,
>> but theres no good place in the rpms for such advisories.  After a
>> while some of us can get downright bored, even growly about it. 
>> My apologies in that case :)
>
>Which is why I've only posted the src.rpm and encouraged people to
> rebuild it using the correct settings for their site. The problem
> is in distributing it on a large scale (i.e. part of a distro), but
> there really is no good solution to that. If there is interest in
> the src.rpm, I'll be sure to post it as it gets updated (assuming
> Jay doesn't beat me to it).
>
>Matt

I think Jay needs the help.  Not because he is doing a bad job, he 
isn't, but when one is that busy, stuff starts falling thru the 
cracks...   Maybe you could take over the amanda rpm maintainance for 
those distros that use rpms, says he, donning the kevlar underwear. 
:-)

-- 
Cheers, Gene
AMD K6-III@500mhz 320M
Athlon1600XP@1400mhz  512M
99.21% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attornies please note, additions to this message
by Gene Heskett are:
Copyright 2003 by Maurice Eugene Heskett, all rights reserved.