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 attachment 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 attachment 90066 [details, diff] amanda-2.5.0-4tb-holding-disk.patch
Created attachment 90067 [details, diff] amanda-2.5.0-amverify-loop-detect.patch
Created attachment 90068 [details, diff] amanda-2.5.0-socklen.patch
Created attachment 90069 [details, diff] 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 attachment 90680 [details, diff] 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 attachment 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] > 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 attachment 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.
Comment on attachment 100501 [details] amanda-2.5.1_p1.ebuild 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.
