Bugzilla Bug 127725

Hello.

Amanda 2.5 released. An ebuild would be nice. :-)

Hi,

has anyone already got amanda 2.5.0 ebuilds?

What is the current status? Are there any issues?

Thanks in advance,

JOhnny

Just waiting on me getting my tape drive working again for good testing - I
want to throughly test it as a new major version.

Created an attachment (id=90065) [details]
amanda-2.5.0_p2.ebuild

Based on amanda-2.4.5_p1.ebuild - added/modified a few patches to make it
compile

Created an attachment (id=90066) [details]
amanda-2.5.0-4tb-holding-disk.patch

Created an attachment (id=90067) [details]
amanda-2.5.0-amverify-loop-detect.patch

Created an attachment (id=90068) [details]
amanda-2.5.0-socklen.patch

Created an attachment (id=90069) [details]
amanda-2.5.0-tar-1.14.90.patch

I've been running this now on my box for a week. I experienced no problems with
the update. Please add this to portage.

Created an attachment (id=90680) [details]
amanda-2.5.0_p2-DEBUG_CODE.patch

This patch of my own making has amanda build properly with USE=-debug.
Otherwise it will fail because in an #ifdef [...] #else, int i is used but not
defined. Apparently this one slipped past upstream in their testing. 8-)

Not sure if I should enter a new bug for this but, I'd love to have a "client"
and "server" keywords on this ebuild.

When I was making my packages on Slack I tuned them to only have what is
necessary. I find more "optimal" to only have the client binaries on the client
machine.

Now that Gentoo 2006.1 is released may I kindly ask if a version bump would be
possible?

And also now that amanda 2.5.1 is available ...

Did someone test the 2.5.1 with the 2.5.0_p2 ebuild ?

Created an attachment (id=99809) [details]
amanda-2.5.1-ebuild.tar.bz2

I tried to update the ebuilds, but so far ran into compilation issues both with
xfs and another bug I could not fix. Maybe you can take a look

(In reply to comment #14)
> Created an attachment (id=99809) [edit] [details]
> amanda-2.5.1-ebuild.tar.bz2
> 
> I tried to update the ebuilds, but so far ran into compilation issues both with
> xfs and another bug I could not fix. Maybe you can take a look
> 

I don't use xfs, but the other bug(if the same than mine) seems to come from an
bad defined function (db_rename).
Looking through the code, I'd suggest to stick a bit longer on the 2.5.0p1. The
code contains too many commented debug strings. It seems too meuch in 'devel'
for me.

You corrected yourself, I mean 2.5.0p2

Created an attachment (id=100501) [details]
amanda-2.5.1_p1.ebuild

I have been running app-backup/amanda-2.5.1_p1 stable since Wed Sep 27 2006
now, doing backups three times a week for two different hosts, to a HP-DAT72
tape drive, using aespipe/amcrypt (DEPEND="app-crypt/aespipe") for one of the
sources. I'm happy with it so far, especially when amcrypt started working in
this version.

I tried your ebuild J Roovers, but as for all the 2.5.1 versions, I keep having
this error while compiling :

amlogroll.c:(.text+0x22a): undefined reference to `dbrename'

I'm running an amd64 opterion. Gentoo 64 bits.. perhaps error comes from this.
Should I open a bug ? Am I the only one ?

I'm having the same problem on a i386 system.

No, I get the exact same error when I set USE=-debug.

(In reply to comment #20)
> No, I get the exact same error when I set USE=-debug.
> 

From my investigation, this "dbrename" function is normally called "rename".
Both 2.50 et 2.5.1 amanda releases have this kind of debug code. I don't find
it really clean. I hope the next release will be better.

I successfully compiled the 2.5.1p1 with USE="debug" despite I don't need it.
At least, it's installed. 

Thanks Jeroen

2.5.1p2 compiling well with 2.5.1p1 ebuild

I don't like to complain, but will this be in portage proper soon?  The reason
I ask is that there is a known issue with the latest versions of tar and
incremental backups with amanda.  This issue is supposedly fixed in amanda 2.5.
I have several machines which I have to mask the latest versions of tar in
order to get successful (incremental) backups.  It's just a matter of time
before the old version of tar is removed from portage...

marduk, since the backup herd is (IMHO) quite busy with other things, I think
it is appreciated if you would take actions yourself here.  Contact Daniel to
be sure.

Fabien,

As much as I'd like to, I have neither the time nor the expertise at the moment
to take on that responsibility.  But thanks for your input and I will wait
patiently for the backup herd to catch up.

I had the `dbrename' problems on 2.5.1_p1 on x86.

When I version bumped to 2.5.1_p2, it installed fine.

I also wish this ebuild was better maintained in portage & would also like a
client-only flag (bacula has one, so why not amanda!).  Can I do anything to
help with either of these item 

For everybody lurking here and complaining, there are a few things you should
know. Outside of bacula and one other package that has a dedicated maintainer,
amanda and everything else in the backup set are maintained by just two of us.

I additionally have an annoying hardware problem that blocks me from using my
tape drive at the moment - I migrated to PCIe hardware, and the sole PCI slot
that I have left does't work (it's physically damaged).

That's why I posted a request on the adopt-a-dev for either a PCIe SCSI
adapter, or a SCSI->iSCSI bridge (for the back of the tape drive). I know from
maintaining amanda in the past, that a full test of backup+restore is very well
advised before just putting it in the tree.

I considered sending an email directly to Robin, but want to be open in my
offer of (SOME) financial support to encourage others would like to join me.

I am not in a position to provide either a PCIe SCSI adapter, or a SCSI->iSCSI
bridge (for the back of the tape drive).  We might be able to send and (old)
x86 box that still had PCI.

I would also be more than happy to donate $20 or so towards the purchase of the
adapter or the bridge.  I've donated to the Gentoo Foundation in the past & it
was easy.  Could you apply for funding from them?  I'd be happy to put in a
good word & make an initial donation to help "grease the wheels."

I should mention the reason that I'm on two PCIe systems presently, is that I
had to downsize after I moved - I simply don't have space for more systems.

This is the cheapest PCIe SCSI card I've found to date ($479USD):
http://www.pc-pitstop.com/scsi_controllers/ul5d.asp
And it's still overkill for what I need.

iSCSI bridges seem to start around $600USD.

I've been trying to avoid making a direct request of the foundation (and
supplying my own hardware as I can afford it, which is very slowly), due to the
lack of financial reports coming from the Foundation.

If you don't need 2x:
$206 PCIe SCSI (U-320) HBA which claims Linux compatibility:
<http://www.compsource.com/ttechnote.asp?part_no=412911B21&src=PW>
product info:
<http://h18000.www1.hp.com/products/servers/proliantstorage/adapters/sc11xe/index.html>

nice, thanks for the cheaper one.
Now just to find somewhere that stocks it and will ship to Canada without
hassles (compsource won't it seems), then I can probably manage it after the
spending-hump of christmas.

Pardon the bug spam, but here's a US vendor I've ordered from before that has
it in stock & will ship to Canada
<http://www.sparco.com/cgi-bin/wfind2?spn=A89K999>

Thanks again for your work, Robin!

Not a problem with the bug-spam.

Richard: since you seem to have one, I have one question with that one, the HP
specs say it only supports tape drives, and I find that weird (not a limitation
I'll hit as I don't have any SCSI enclosures anymore, but I'm just wondering).

I don't have this particular card--I use PCI on my tape server (which actually
runs FreeBSD--I have several gentoo clients).

Tape-only solutions used to be more common.  I think they disable the onboard
bios and fix the IRQ and I/O of the card.  I think tape changers can work.

This seems to be the bare minimum you'd need to use the tape drive and is the
lowest cost card I could find.

There are other entry-level cards with prices between this one and the one you
linked (closer to the latter) to if you'd like to be able to expand in the
future.  I looked at froogle and pricewatch.

(In reply to comment #27)
> For everybody lurking here and complaining

For what it's worth, I am thinking of putting my own 2.5.1_p2  ebuild in the
tree. I have been testing them for months on an HP tape drive with a 12 tape, 3
tape a week cycle, using a couple of BSD clients and (more importantly) a
Gentoo/Linux server, and I am just about to begin a new tape cycle, so I can
slot in the oldest tape this very night and see if the amcrypt-encrypted stuff
on tape is still usable. If it is, I could put the 2.5.1_p2 in the tree. It has
two new RDEPENDs not listed in the last ebuild I posted, namely for
app-crypt/aespipe and app-crypt/gnupg.

[ebuild   R   ] app-backup/amanda-2.5.1_p2  USE="berkdb debug gdbm -samba -xfs"
0 kB [1]

Robin, if you're OK with this, I will just go ahead and do my thing. I'll
initially p.mask it too if you like, so you can look over it first.

(From update of attachment 100501 [details])
2.5.1_p2 is in portage.

(In reply to comment #36)
> (From update of attachment 100501 [details] [edit])
> 2.5.1_p2 is in portage.
> 

Jeroen: this version still requires the patch in this message:
http://www.nabble.com/Re:-tar-backups-fail-if-a-file-changes-t2720848.html

It's in the amanda subversion tree for future releases.

(In reply to comment #37)
> Jeroen: this version still requires the patch in this message:
> http://www.nabble.com/Re:-tar-backups-fail-if-a-file-changes-t2720848.html
> 
> It's in the amanda subversion tree for future releases.

The patch doesn't apply against 2.5.1_p2. This one does:

--- client-src/sendbackup.c.    2006-07-25 20:27:56.000000000 +0200
+++ client-src/sendbackup.c     2006-12-13 03:31:03.000000000 +0100
@@ -597,6 +597,12 @@
     }
 #endif

+    if(pid == tarpid) {
+       if(ret == 1) {
+           rc = 0;
+       }
+    }
+
 #ifdef IGNORE_TAR_ERRORS
     if(pid == tarpid) {
        /*

I have added the patch I previously posted and have also introduced the minimal
USE flag, which basically adds --without-server to the configure options so
that only the amandad, am*recover and (sadly) amplot executables get installed.
The changes are in CVS now.

I am thinking of adding a doc USE flag to allow users to not install all the
documentation, but then an examples USE flag would be nice as well.

I've done 2 backups with this version now, and restored a file from a backup
made with this version and restored a file from a backup made with 2.4.x and
all has worked.  My configuration has the amanda server with a single tapedrive
(not a changer) and a single amanda client (running 2.4.5) that is also
backed-up.

I've run into a couple of minor issues that I had to fix to make amrecover
work. 
First "server_args     = -auth=bsd amindexd amidxtaped" needs to be added to
each service in the xinetd configuration. 
Second, the amandahosts file needs a line "tapeserver    root    amindexd
amidxtaped".
After changing those 2 files amrecover works. Solution found here:
http://forums.zmanda.com/archive/index.php/t-179.html

One other very minor problem is that amrecover chose /dev/null as the default
tape drive to restore from. I had to specify the drive path manually for the
backup to restore, whereas in the past it was automatically selected.

My separate amanda client (backup only, I don't have amrecover installed on the
client) and my custom tape label both worked "out of the box".

This build completely fixes bug 157923.

(In reply to comment #40)
> First "server_args     = -auth=bsd amindexd amidxtaped" needs to be added to
> each service in the xinetd configuration. 

I'm sorry, amcheck (and presumably amdump) fails after doing this. The amanda
xinetd service (apparently not the other 2) needs to have "server_args     =
-auth=bsd amdump amindexd amidxtaped". This allowed amcheck to pass, and I
expect amdump will run correctly now.

Is there any problems with client, or only with server ? Is it safe to run 2.5
client with 2.4 server ?

2.5 is in the tree properly now, as of 2.5.1_p3-r1. Do NOT use any other 2.5
builds before that.
I have one of the upstream developers working with me now.

The 2.5.1_p2 and 2.5.1_p3 that jer committed should NOT have gone into the
tree. I knew about the breakages that p2 contained, and upstream told me to
wait for p3.

jer: please see the email I have sent you.