>... Amanda has way too much config information compiled >in that (in my opinion) is better suited for the config file. If the >paths/users/portranges/etc were read from the config file then there would >be little need for recompiling.
In general I agree, however there are reasons it's this way (I'm not saying they're *good* reasons :-). A major design decision in Amanda is that there is **no** config file on the client side. One of the reasons for that, I'm sure, was maintenance. You can back up literally hundreds of clients with Amanda, and managing all of them **after the initial installation** could be a headache. I suspect in the original environment, even getting access to some of the clients was a problem (locked away in some office, for instance). Second, the client is independent of the server. Notice that when you set up a dumptype for a client you tell it to use "DUMP", you do *not* tell it to use /usr/sbin/ufsdump. Putting the client configuration back on the server, then, might (depending on how it was implemented) violate this, and could lead to other problems. Third, having Amanda figure things like paths out in ./configure is less error prone than a dynamic config file. Do you know if your version of dump uses -E or -S to generate estimates? Putting the potential to mess that up in an easily editable config file has its own set of risks. As I said, I agree, in principle, that all the hard coded stuff in Amanda is a problem. But we need to make sure the "solution" does not make things worse. >Frank John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
