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.