More ranting about issues compiling 2.6.1 on older machines
I started a discussion about this the other day, and I am trying to work through this as a background task while doing the rest of the things i have to do. I thought I would point out what a PIA it is turning into to get newer version of Amanda compiled on older machines. The glib dependency requires gettext. Also glib will not compile with older versions of GCC. Now GCC used to build pretty well on older machines, but it looks like the 4.x version of it now depends upon a couple of math packages gmp, an mpfr. So, to migrate a given client (HP-UX in this case) Howard, I am having to compile the following list of things that did not used to be dependencies: gettext gmp mpfr gcc glub That's a lot of stuff just to replace working code with more maintainable code IMHO. I really think we need to come up with a plan that results in it being easier to comile clients on older machines. I have expressed my opinion that this needs to be a forkof a 2.5 branch, but I did not seem to get much in the way of buy in by others on this list ofr that. Does anyiine have a better plan? -- One of the main causes of the fall of the roman empire was that, lacking zero, they had no way to indicate successful termination of their C programs.
Re: More ranting about issues compiling 2.6.1 on older machines
stan wrote: I started a discussion about this the other day, and I am trying to work through this as a background task while doing the rest of the things i have to do. I thought I would point out what a PIA it is turning into to get newer version of Amanda compiled on older machines. The glib dependency requires gettext. Also glib will not compile with older versions of GCC. Now GCC used to build pretty well on older machines, but it looks like the 4.x version of it now depends upon a couple of math packages gmp, an mpfr. So, to migrate a given client (HP-UX in this case) Howard, I am having to compile the following list of things that did not used to be dependencies: gettext gmp mpfr gcc glub That's a lot of stuff just to replace working code with more maintainable code IMHO. I really think we need to come up with a plan that results in it being easier to comile clients on older machines. I have expressed my opinion that this needs to be a forkof a 2.5 branch, but I did not seem to get much in the way of buy in by others on this list ofr that. Does anyiine have a better plan? I have numerous clients still running amanda 2.4.x clients and talking to my 2.6.1 server. I would think that maintaining backward compatibility within the amanda server is a more fruitful path than trying to build the latest version on all sorts of older platforms. Is there reason to believe that older clients will become unsupported sometime soon? Jeff Anderson Lawrence Berkeley National Lab
Re: More ranting about issues compiling 2.6.1 on older machines
stan wrote at 08:30 -0500 on Mar 2, 2009: I really think we need to come up with a plan that results in it being easier to comile clients on older machines. I have expressed my opinion that this needs to be a forkof a 2.5 branch, but I did not seem to get much in the way of buy in by others on this list ofr that. Does anyiine have a better plan? You never really said why you need to fork 2.5 as opposed to just run 2.5.2 (or 2.4.5) on older clients. Security fixes? Specific features? I think that putting security fixes onto a branch of 2.5 might be a reasonable task. Backporting some of the newer APIs would likely be a good bit more work, and, depending on your point of view, possibly not worth it. That said, it's possible committers would be willing to entertain committing patches to a 2.5.2 branch. I can't speak for them, but if the work is made minimal (by submitting well-documented patches), they might be reasonable about it. You could test the waters with a patch to fix some buffer overflow and ask (on amanda-hackers) if they would be willing to commit it. Cutting a new release is probably beyond the scope, but making commits to a legacy branch for a while seems reasonable. And if they don't, then you could, as you seem to be hinting, start a fork yourself. I can't say how popular it would be. Personally, I've had reasonable success getting the newer code to compile / run on older machines, certainly for clients if not the server code. It may be less work than a fork (and patches possibly more acceptable to the current maintainers). But if you publish a fork (whether it be a patchset or a public repository), there's likely a greater than zero chance that someone will use it - I just can't say how much greater than zero ;).
Re: More ranting about issues compiling 2.6.1 on older machines
On Mon, Mar 2, 2009 at 4:22 PM, John Hein jh...@timing.com wrote: That said, it's possible committers would be willing to entertain committing patches to a 2.5.2 branch. I can't speak for them, but if the work is made minimal (by submitting well-documented patches), they might be reasonable about it. You could test the waters with a patch to fix some buffer overflow and ask (on amanda-hackers) if they would be willing to commit it. Cutting a new release is probably beyond the scope, but making commits to a legacy branch for a while seems reasonable. Yes, we'd be happy to do so, right now. The branch still exists. As you indicate, cutting a new release would require further discussion :) And if they don't, then you could, as you seem to be hinting, start a fork yourself. I can't say how popular it would be. Personally, I've had reasonable success getting the newer code to compile / run on older machines, certainly for clients if not the server code. It may be less work than a fork (and patches possibly more acceptable to the current maintainers). This is my preference, though -- a fork does not necessarily have to be hostile! The advantage here is that someone other than the current developers is responsible for marshalling patches and making releases. I speak only for myself, but I'm happy to hack on and commit fixes to such a fork. I just don't want the burden of maintainership. I think that the first step after the fork should be to rip out the server stuff, so that the forked project *only* builds a client. I'd also like for it to have a different package name, but to keep the version numbers compatible with Amanda (so if the fork is of Amanda-x.y.z, the first release would be AmandaMinimalClient-x.y.z, and the next AmandaMinimalClient x.y.z.1, etc.) If a few interested folks sign on as co-maintainers, then I think this can be a sustainable project that does not sap too much of anyone's time. Dustin P.S. This would have an advantage for mainline development, too: with a maintained minimal client available, we can recommend that those who cannot install the newest Amanda use the minimal client, and we can focus our compatibility testing on that minimal client. Everyone wins! -- Storage Software Engineer http://www.zmanda.com
amanda on solaris CMT chips
I was wondering if their was any features with tar or Amanda that can take advantage of sun multi-threaded processors. Seems like Amanda will peg only 1 core on our server for tar processing. Thanks
Two Questions - Clients and MySQL
You know, the more that I get to know and understand Amanda, the more I'm impressed. Thanks guys! First off, I have one laptop - but it appears that someone has to be logged on in order for the backup to work properly. I thought with the additional user, the machine just had to be on. Did I do something wrong? Is it possible to just have it sign on and backup without a real user on? I know that Zmanda does MySQL backups - but does Amanda as well? Is that one of the differentiations for the products? As always - thanks for your quick answers and thoughts... Matt Burkhardt, MS Technology Management Impari Systems, Inc. 502 Fairview Avenue Frederick, MD 21701 m...@imparisystems.com www.imparisystems.com (301) 682-7901
Re: amanda on solaris CMT chips
On Mon, Mar 2, 2009 at 4:56 PM, Krahn, Anderson akr...@gs1us.org wrote: I was wondering if their was any features with tar or Amanda that can take advantage of sun multi-threaded processors. Seems like Amanda will peg only 1 core on our server for tar processing. If you run multiple dumps in parallel, you will see more processors in use. Dustin -- Storage Software Engineer http://www.zmanda.com
Re: Two Questions - Clients and MySQL
The must-be-logged-in problem sounds like it might be an Ubuntu security thing?? On Mon, Mar 2, 2009 at 5:05 PM, Matt Burkhardt m...@imparisystems.com wrote: I know that Zmanda does MySQL backups - but does Amanda as well? Is that one of the differentiations for the products? ZRM is also open-source: http://www.zmanda.com/backup-mysql.html Dustin -- Storage Software Engineer http://www.zmanda.com
Re: More ranting about issues compiling 2.6.1 on older machines
On Mon, Mar 02, 2009 at 12:12:36PM -0800, Jeffrey D Anderson wrote: stan wrote: I started a discussion about this the other day, and I am trying to work through this as a background task while doing the rest of the things i have to do. I thought I would point out what a PIA it is turning into to get newer version of Amanda compiled on older machines. The glib dependency requires gettext. Also glib will not compile with older versions of GCC. Now GCC used to build pretty well on older machines, but it looks like the 4.x version of it now depends upon a couple of math packages gmp, an mpfr. So, to migrate a given client (HP-UX in this case) Howard, I am having to compile the following list of things that did not used to be dependencies: gettext gmp mpfr gcc glub That's a lot of stuff just to replace working code with more maintainable code IMHO. I really think we need to come up with a plan that results in it being easier to comile clients on older machines. I have expressed my opinion that this needs to be a forkof a 2.5 branch, but I did not seem to get much in the way of buy in by others on this list ofr that. Does anyiine have a better plan? I have numerous clients still running amanda 2.4.x clients and talking to my 2.6.1 server. I would think that maintaining backward compatibility within the amanda server is a more fruitful path than trying to build the latest version on all sorts of older platforms. Is there reason to believe that older clients will become unsupported sometime soon? Have you tried restoring? I have a contractor whose assignment is to prove that we can estore on evey machine in the backup system. She assures me that earlier cliets cannot do this, and that we must move foward. I have 2 reasons to beleive her. 1. I trust her, and have worked with her for years. 2. It's a fixed price job for here, and the answer she came up will definatley cost her money. -- One of the main causes of the fall of the roman empire was that, lacking zero, they had no way to indicate successful termination of their C programs.
Re: More ranting about issues compiling 2.6.1 on older machines
On Mon, Mar 02, 2009 at 04:46:43PM -0500, Dustin J. Mitchell wrote: On Mon, Mar 2, 2009 at 4:22 PM, John Hein jh...@timing.com wrote: That said, it's possible committers would be willing to entertain committing patches to a 2.5.2 branch. ??I can't speak for them, but if the work is made minimal (by submitting well-documented patches), they might be reasonable about it. ??You could test the waters with a patch to fix some buffer overflow and ask (on amanda-hackers) if they would be willing to commit it. ??Cutting a new release is probably beyond the scope, but making commits to a legacy branch for a while seems reasonable. Yes, we'd be happy to do so, right now. The branch still exists. As you indicate, cutting a new release would require further discussion :) Well, the overiding reason is the issue of clarity that I mentioned befoere. Otherwise, it certainly becomes a FAQ, and most likely simply results in many potential suers deciding not to use the project, once they evaluate the dependacy requirmants for the newer versions. As for that version still exisitng. i certainly hpe that all versions still exist in teh soruce code conytrol ssytem! if not, maybe I need to look arounf for old tarballs :-) And if they don't, then you could, as you seem to be hinting, start a fork yourself. ??I can't say how popular it would be. ??Personally, I've had reasonable success getting the newer code to compile / run on older machines, certainly for clients if not the server code. ??It may be less work than a fork (and patches possibly more acceptable to the current maintainers). This is my preference, though -- a fork does not necessarily have to be hostile! The advantage here is that someone other than the current developers is responsible for marshalling patches and making releases. I speak only for myself, but I'm happy to hack on and commit fixes to such a fork. I just don't want the burden of maintainership. I am most certainly not trying to do a hostile fork here! I think that the first step after the fork should be to rip out the server stuff, so that the forked project *only* builds a client. I'd also like for it to have a different package name, but to keep the version numbers compatible with Amanda (so if the fork is of Amanda-x.y.z, the first release would be AmandaMinimalClient-x.y.z, and the next AmandaMinimalClient x.y.z.1, etc.) That actually sounds reasoanble. If a few interested folks sign on as co-maintainers, then I think this can be a sustainable project that does not sap too much of anyone's time. That would be wonderful. I am willing to put some effort into this, and I have some old ssytems to do testing, and porting work one. P.S. This would have an advantage for mainline development, too: with a maintained minimal client available, we can recommend that those who cannot install the newest Amanda use the minimal client, and we can focus our compatibility testing on that minimal client. Everyone wins! Right on! -- One of the main causes of the fall of the roman empire was that, lacking zero, they had no way to indicate successful termination of their C programs.
Re: Two Questions - Clients and MySQL
On Mon, 2009-03-02 at 17:05 -0500, Matt Burkhardt wrote: You know, the more that I get to know and understand Amanda, the more I'm impressed. Thanks guys! Great! First off, I have one laptop - but it appears that someone has to be logged on in order for the backup to work properly. I thought with the additional user, the machine just had to be on. Did I do something wrong? Is it possible to just have it sign on and backup without a real user on? This shouldn't be necessary. Are you sure that this isn't a sleep/wake issue? How is the backup failing? I know that Zmanda does MySQL backups - but does Amanda as well? Is that one of the differentiations for the products? Yes, this is Zmanda's ZRM product although there is a community version as well, http://zmanda.com/download-zrm.php As always - thanks for your quick answers and thoughts... You bet, Paul
Re: amanda on solaris CMT chips
On Mon, Mar 02, 2009 at 05:17:16PM -0500, Dustin J. Mitchell wrote: On Mon, Mar 2, 2009 at 4:56 PM, Krahn, Anderson akr...@gs1us.org wrote: I was wondering if their was any features with tar or Amanda that can take advantage of sun multi-threaded processors. Seems like Amanda will peg only 1 core on our server for tar processing. If you run multiple dumps in parallel, you will see more processors in use. My server is a dual processor dual core unit, and when the backups run no CPU cycles go to waste :-) -- One of the main causes of the fall of the roman empire was that, lacking zero, they had no way to indicate successful termination of their C programs.
Re: More ranting about issues compiling 2.6.1 on older machines
stan wrote: On Mon, Mar 02, 2009 at 12:12:36PM -0800, Jeffrey D Anderson wrote: stan wrote: I started a discussion about this the other day, and I am trying to work through this as a background task while doing the rest of the things i have to do. I thought I would point out what a PIA it is turning into to get newer version of Amanda compiled on older machines. The glib dependency requires gettext. Also glib will not compile with older versions of GCC. Now GCC used to build pretty well on older machines, but it looks like the 4.x version of it now depends upon a couple of math packages gmp, an mpfr. So, to migrate a given client (HP-UX in this case) Howard, I am having to compile the following list of things that did not used to be dependencies: gettext gmp mpfr gcc glub That's a lot of stuff just to replace working code with more maintainable code IMHO. I really think we need to come up with a plan that results in it being easier to comile clients on older machines. I have expressed my opinion that this needs to be a forkof a 2.5 branch, but I did not seem to get much in the way of buy in by others on this list ofr that. Does anyiine have a better plan? I have numerous clients still running amanda 2.4.x clients and talking to my 2.6.1 server. I would think that maintaining backward compatibility within the amanda server is a more fruitful path than trying to build the latest version on all sorts of older platforms. Is there reason to believe that older clients will become unsupported sometime soon? Have you tried restoring? I have a contractor whose assignment is to prove that we can estore on evey machine in the backup system. She assures me that earlier cliets cannot do this, and that we must move foward. I have 2 reasons to beleive her. 1. I trust her, and have worked with her for years. 2. It's a fixed price job for here, and the answer she came up will definatley cost her money. I always restore on the server, then transfer files to the clients. That clearly works. I can see that if you need to be able to run amrecover directly on the clients there are more potential problems with old versions. Note, though, that even if the amanda configuration is totally broken, it is always POSSIBLE to restore just using dd and tar or dump. Maybe not convenient, though. You never want to get to that stage if you can avoid it. Jeff Anderson Lawrence Berkeley National Lab
Re: More ranting about issues compiling 2.6.1 on older machines
On Mon, Mar 2, 2009 at 5:55 PM, stan st...@panix.com wrote: I think that most of the new features are conecntrated on teh server end, if I am not mistaken. The last client side enhancement that rose to a visibilty level for me was client side config files, so that you don't ahve to ahe many, many deifernt dumptyes, where the only overide was, say where teh exclude file went. or am I missing something here? The major addition on the client side is the Application API. While we could probably patch a minimal client to support client-side configuration files, such a minimal client will never support the Application API. But that's OK! Dustin P.S. 2.5.0 and later are in Subversion. The remaining history (some of it, at least) is in CVS, and I have a very low-priority TODO task (for some night when I can't sleep) to try to graft that onto the git history. -- Storage Software Engineer http://www.zmanda.com
lvm snapshots for backup
Hi, I'm using amanda-2.6.0p2 and want to use lvm snapshots to backup some changing filesystems. Are there hook scripts for this or is there some plugin to use? I've seen a thing called MySQL ZRM which looks like it might work. Is that ok to use for volumes other than MySQL databases? Is it overkill? Thanks, Tom -- Tom Robinson System Administrator MoTeC 121 Merrindale Drive Croydon South 3136 Victoria Australia T: +61 3 9761 5050 F: +61 3 9761 5051 M: +61 4 3268 7026 E: tom.robin...@motec.com.au
