[geeks] Backup software (yeah, yeah, I know)

[der Mouse]

> Things like Bacula and Amanda are massive overkill for most people,
> and they are really annoying and inflexible to set up.

Bacula I don't know.  Amanda is massive overkill for anyone with fewer
than several machines to back up, and even some of them.

> That said, Amanda does work really well from what I hear, and I think
> there is now an easier version available, but it requires Solaris.

Amanda used to be great.  Now it's merely good -- and going downhill.

Warning: rant ahead.

At work we run amanda 2.5.1p2, and I recently looked at switching to
2.6.1.  It's pretty horrible.  Here's a rough log of the issues,
assembled from the notes I took at the time.

Amanda 2.6.1 needs glib, which needs pkg-config.  I brought over all
three and started trying to make them build.

All three of them have caught the ./configure disease.  This alone
makes me question the wisdom of running them; do you really want to run
software from someone who cares that little about the security of their
users' machines?  (configure scripts are a security disaster.  They are
almost perfect trojaning targets: mind-numbing to read over; very
difficult, usually far harder than the software they configure, to
sandbox; about as difficult to check in automated ways; and, perhaps
worst of all, they train people to blindly run them.  Even if I trust
the software authors to be non-malicious, there are at least three real
risks: (1) an attack on the download, causing me to receive something
other than what the download host sent; (2) an attack on the download
site, replacing the distribution files; and (3) most disturbing of all,
cracking a developer's machine and installing an autoconf trojaned to
generate trojaned configure scripts.)

But my management chain told me we considered the risk acceptable, so I
ran the configure scripts.  I startd with pkg-config, of course.

pkg-config's configure script required manual editing to even make it
run to completion, never mind actually work right. This, to me, throws
major doubt on the quality of the rest of the software involved.

pkg-config grossly violates data hiding and opaque typing, computing a
#define containing the bytes making up a pthread_mutex_t.  I can think
of a number of reasonable, even likely, implementation techniques that
would make such a thing useless.

make output for pkg-config is scary: it uses strsignal() without a
declaration, thereby getting the return type wrong; it uses libtool in
ways that provoke warning messages; test programs have dead functions
and dead variables; they use <ctype.h> macros on objects of type char
(which violates the interface if char happens to be signed) - and those
are just the things I found by looking at the warnings in make's
output.

glib, in turn, uses this disaster (in addition to the ./configure
disaster).  But aside from that, its configure script too needed manual
editing to even complete (it made invalid assumptions about statfs()
and thus errored out needlessly partway through).

glib copies pkg-config's mistake of assuming the bytes making up a
pthread_mutex_t is a sane thing to build a #define for.  It too has
dead functions and variables; it passes arguments of the wrong type;
it's got qualifier mismatch problems at function-call interfaces; it
too violates <ctype.h>'s interface on systems with signed chars; it
makes really rudimentary pointer blunders (for example, it compares a
GQuark* for equality with a GQuark); it makes further pointer-use
blunders which cover the preceding mistake up on machines where ints
and pointers are sufficiently compatible; it passes and returns
incompatible pointer types; and, even after patching configure, it
doesn't correctly handle systems without statfs().  These too are just
the ones found by reading the warnings in make output (mostly produced
by warnings the develoepers chose to request by using -Wall to gcc, but
apparently couldn't be arsed to fix - some of them have been errors as
long as C has been C and thus can't be ascribed to gcc version
differences); there almost certainly are tons more mistakes that just
didn't get caught.

glib's Makefiles impose -k whether you like it or not, meaning that
when a build breaks, you can't just go to the end of the log and back
up a page or two to see what went wrong.

glib's got busted preprocessor logic, despite this being exactly what
./configure is supposed to eliminate, in one of its files.  I just
ripped out a page or two of code and stuck in something right for the
system at hand.

On to Amanda proper.

It uses glib, with all the mess that entails - and the bad judgement it
implies.

Once again, I had to edit configure to make it run.

The Makefile uses nonstandard, apparently GNU-make-specific, syntax -
but doesn't document the dependency on the use of a nonstandard make.
And, as far as I can see from a quick glance, it appears to be for
something with are standard way to express!

Significant pieces have been converted into perl scripts, thus meaning
you either lose their functionality or you have to install another huge
dependency with its own ton of issues.  (We already had perl on the
machine, for I know not what reason - someone else set it up - so I was
spared whatever build issues it might have.)  In particular, two APIs
are gone, and if you use them, "you must rewrite them in perl using the
new perl modules".  So to preserve your investment you have to learn a
whole new programming language?  They couldn't even be bothered to
provide a glue layer?!  Furrfu.  (This is perhaps slightly unfair;
switching languages is not an inherently bad thing.  But failing to
call it out with a big warning where people contemplating switching
will see it _is_ a bad thing.)

Then, when I finally got it to build, it didn't work.  I tried a few
test commands and got error messages that made no sense.  I had to
syscall-trace the thing to discover that perl was failing (and the
error, printed to the failing process's stderr, was going nowhere I
could find).  I don't know what was wrong; it was griping about an
undefined symbol when loading a .so, and that is about two levels
beyond my perl knowledge.

We shelved the "switch to 2.6.x" project.

(No, I haven't reported any of these.  pkg-config and glib don't
provide bug-reporting addresses, only Web-form horrors, and as far as I
can tell from grepping for "bug" or "report", amanda doesn't provide
even that much.)

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse at rodents-montreal.org
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B