On Friday 04 August 2006 10:21, Matt Hyclak wrote:
>On Fri, Aug 04, 2006 at 07:03:39AM -0400, Gene Heskett enlightened us:
>> This is a frequent problem when using a 'packaged' version of amanda.
>> The rpm packagers in particular have demonstrated many times that they
>> do not understand how amanda treats security issues. Amanda's build
>> gives it enough perms to do the instant job each piece needs to do, and
>> no more. This is why, when potential users run into these sort of
>> problems, that we universally recommend that it be built from the
>> tarball, following amanda's instructions so that the amanda build and
>> install can be done correctly.
>
>Not to get off topic, and no offense Gene, but that second sentence is
>entirely inaccurate.
Only if you are looking at it from the redhat/fedora side of the fence,
Matt.
>There are several problems with Amanda RPMs which
>require compromises be made, but not understanding security and how
> amanda works is definitely *not* one of them. What some of the problems
> are include:
>
>- Inability to know the hostname of the amanda server (or any server for
> that matter) on the clients network. Since amanda requires these at
> build time, the only logical compromise is to use localhost
With all due respect Matt, that puts a bullet through the heart of any
chance to do a recovery with the recovery tools as they specifically
reject the localhost as a valid name because it could be any machine
anywhere. Thats one of the security things amanda enforces. Without
that, recovery is a mt, dd, gzip and tar exersize. Doable, but a pita.
Either that, or you have to patch that back out of amanda before the object
package is built.
>- Inability to know what user the software will be built as (if
> rebuilding a source RPM). There are RPM mechanisms in place that fix
> that, though not pretty, which set ownership to the appropriate user and
> permissions. I would argue that the fact these are in there (at least in
> the
> RedHat-produced RPMs) counter your point about not understanding the
> security needs.
Then the only way to do amanda as an rpm is in the form of a source rpm
isn't it?
>As always, I consider http://www.math.ohiou.edu/~hyclak/casit/amanda/ a
>worthwhile read for anyone using an RPM-based system, and recommend that
>users of Amanda rebuild SRPMs for their environment. Jay has made it
> easier with the latest Fedora Development RPMs to do that in the future.
Whats needed is that this src rpm be self building as it installs, after
installing its own user, makeing that user a member of the group disk or
backup as appropriate and detecting via uname responses the host servers
name during the configure stage, and the install process switching users
as appropriate during the build and install phases.
However rpm does not that I know of, and I'm certainly not a real card
carrying expert about rpm, support the continuous build and install of a
src rpm in one command line execution. AFAIK it just builds the package,
leaving the user to then install it in a seperate step. Maybe its time
for rpm-5.0?
And we were, in the present case, talking about SuSe rpms, not
redhat/fedora. Redhat/fedora rpms haven't recently been enough of a
problem to generate noticable traffic on the list. They were, in spades,
2-3 years ago, as I'm sure you are aware, with no little traffic defending
rpms coming from the redhat camp's packager, whose name escapes me at this
late date but it wasn't you. And I don't recall that it was Jay at the
time either, but I could be wrong about that. But after he (whomever) had
lurked and listened on the list for a while, it seemed that the problems
with redhat/fedora rpms went away. So in that regard, redhat/fedora seems
to have adjusted their packageing enough fix it.
I guess that because amanda is so easily built and installed, I'm naturally
going to do it that way. And I haven't been reticent about posting my
script to do that, along with suitable caveats about what needs to be
changed. I haven't changed that script but once in 6 years since I wrote
it, and that was when I switched to vtapes nearly 2 years ago. Its not a
very long script, but it guarantees that option compatibility is
maintained from snapshot to snapshot.
In any event, it turned out to not be an amanda problem, but a SuSe
furnished 50-udev.rules problem and I believe the OP has now posted that
he has fixed it.
>Respectfully,
>Matt
--
Cheers Matt, Gene
People having trouble with vz bouncing email to me should add the word
'online' between the 'verizon', and the dot which bypasses vz's
stupid bounce rules. I do use spamassassin too. :-)
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.
|
