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.
> >$ 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 :-)
> 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
--
Matt Hyclak
Department of Mathematics
Department of Social Work
Ohio University
(740) 593-1263
|
