Re: Upgrading amanda
Bryan wrote: Jean-Louis, Thank you for replying. OK ... but I'm beginning to think there are network issues. Last night this machine failed during the auth phase. First time that's happened. 'amcheck -c' later succeeded. Would the amandad.*.debug REQ packet received be an entry like this? < SERVICE noop OPTIONS features=9ffe00; yes, but the one for the sendsize SERVICE Increasing rep_tries? I'm grasping for a solution, and presuming that (from the context of REP in the *debug logs) that REP indicates an attempt to reply to the server. More tries = greater chance of success? Evidently not. Sorry, but I don't know which debug files you are talking about. What's the error message you get in the email report? Jean-Louis
Re: Upgrading amanda
Jean-Louis, Thank you for replying. OK ... but I'm beginning to think there are network issues. Last night this machine failed during the auth phase. First time that's happened. 'amcheck -c' later succeeded. Would the amandad.*.debug REQ packet received be an entry like this? < SERVICE noop OPTIONS features=9ffe00; Increasing rep_tries? I'm grasping for a solution, and presuming that (from the context of REP in the *debug logs) that REP indicates an attempt to reply to the server. More tries = greater chance of success? Evidently not. There are spare NICs on both server and client; I'm going to try a backup over a cross-over cable (e.g. take the existing cables / ports / switches out of the picture ...). Bryan On Fri, Jul 24, 2009 at 07:10:53AM -0400, Jean-Louis Martineau wrote: > You should look at the REQ packet in the amandad.*.debug file to find > what is bogus in it. > I don't understand why you want to increase rep_tries? > > Jean-Louis > > Bryan wrote: > >Looking for some guidance on a perplexing problem, plus a summary > >update on my earlier note (below): > > > >Answers to my earlier questions were 'all works with 2.5.1p3'. > >However, 2.5.1 is problematic for a client with ~750 ZFS file > >systems; on test and production runs, variously 10% to 50% of > >the client's ZFS file systems failed to back up due to missing > >ACKs on sendsize. > > > >Building 2.6.x on a SUNWCreq installation on Solaris 9/10 with > >SUNWspro 12 and/or SUNWgccfss was NOT successful (after current > >glib / pkg-config were installed). It builds on a SUNWCprog > >cluster installation. Will investigate this further later. > > > >Current problem: Moving from 2.5.1 to 2.5.2 ... > > > >Solaris 9 server, Solaris 10 client, both running 2.5.2p1, both > >built (no problems noted) with SUNWspro 12. Tape loads OK, bsd > >auth, client selfcheck succeeds, client sendsize fails, > >apparently due to: > > > > sendsize: debug 1 pid 15227 ruid 50 euid 50: start at Thu Jul 23 > > 12:01:15 2009 > > sendsize: version 2.5.2p1 > > Reading conf file "/etc/amanda/amanda-client.conf". > > Could not open conf file "/etc/amanda/DAILY/amanda-client.conf": No such > > file or directory > > sendsize: debug 1 pid 15227 ruid 50 euid 50: rename at Thu Jul 23 > > 12:01:15 2009 > >* sendsize[15227]: time 0.541: REQ packet is bogus: no dumpdate > > sendsize: time 0.541: pid 15227 finish time Thu Jul 23 12:01:15 2009 > > > >amandad agrees: > > > > < > > OPTIONS features=9ffe00; > > FORMAT ERROR IN REQUEST PACKET > > > > > amandad: udpbsd_sendpkt: enter > > amandad: time 8.705: bsd: pkthdr2str handle '000-0001' > > amandad: time 8.705: sec: udpbsd_sendpkt: PREP (2) pkt_t (len 72) > > contains: > > > > "OPTIONS features=9ffe00; > > FORMAT ERROR IN REQUEST PACKET > > " > > > >sendsize functioned (imperfectly) on 2.5.1. The effort to move > >from 2.5.1 to 2.5.2 is an attempt to gain 'rep_tries' in > >amanda-client.conf. The client conf file says: > > > > connect_tries 10 > > rep_tries 50 > > debug_amandad 1 > > debug_amidxtaped 1 > > debug_amindexd 1 > > debug_amrecover 1 > > debug_auth 1 > > debug_event 1 > > debug_holding 1 > > debug_protocol 1 > > debug_selfcheck 1 > > debug_sendsize 1 > > debug_sendbackup 1 > > > >disklist entries for the client all use spindle -1. The client > >has its own dumptype entry that says 'maxdumps 6', and otherwise > >inherits the usual gtar parameters. > > > >The problem is consistently re-produceable, before and after > >'amadmin delete' of the Solaris 10 client. > > > >Hoping that someone can provide some guidance or suggestions. > > > >Bryan > > > >On Tue, Jul 14, 2009 at 10:49:36AM -0400, Bryan wrote: > > > >>Folks, > >> > >>We've been running 2.4.x (presently 2.4.4p1) on Solaris 9 since > >>2002 (and earlier versions back to about 1997 ..). The 2.4.4 > >>release has been enormously successful, and has saved our tail > >>feathers any number of times. Clients are Solaris and Linux of > >>various vintages (including some Fedora that should be retired.) > >> > >>We're bringing up ZFS file systems; looks like it's time to move > >>to 2.6.1. I've read the UPGRADING file in the distribution, and > >>am seeking guidance on some finer points. > >> > >>We keep daily backups for 4 weeks, weeklies for 4 months, and > >>monthlies for 1 year. Can I expect that 2.6.1 amanda will be > >>able to 'amadmin find' and recover tapes written by 2.4.4? (My > >>guess is 'yes'.) Is there compelling merit to doing an upgrade to > >>2.5.1 as a tranisitional step? (Guess = no). > >> > >>Updating all of the clients in one fell swoop would present > >>challenges. > >> > >>A number of client machines (but not all) are presently running > >>2.5.1, the result of a prior but incomplete attempt to upgrade. > >>The 2.5.1 clients work fine with the 2.4.4 server. Can I expect > >>the older clients to work with a 2.6.1 se
Re: Upgrading amanda
You should look at the REQ packet in the amandad.*.debug file to find what is bogus in it. I don't understand why you want to increase rep_tries? Jean-Louis Bryan wrote: Looking for some guidance on a perplexing problem, plus a summary update on my earlier note (below): Answers to my earlier questions were 'all works with 2.5.1p3'. However, 2.5.1 is problematic for a client with ~750 ZFS file systems; on test and production runs, variously 10% to 50% of the client's ZFS file systems failed to back up due to missing ACKs on sendsize. Building 2.6.x on a SUNWCreq installation on Solaris 9/10 with SUNWspro 12 and/or SUNWgccfss was NOT successful (after current glib / pkg-config were installed). It builds on a SUNWCprog cluster installation. Will investigate this further later. Current problem: Moving from 2.5.1 to 2.5.2 ... Solaris 9 server, Solaris 10 client, both running 2.5.2p1, both built (no problems noted) with SUNWspro 12. Tape loads OK, bsd auth, client selfcheck succeeds, client sendsize fails, apparently due to: sendsize: debug 1 pid 15227 ruid 50 euid 50: start at Thu Jul 23 12:01:15 2009 sendsize: version 2.5.2p1 Reading conf file "/etc/amanda/amanda-client.conf". Could not open conf file "/etc/amanda/DAILY/amanda-client.conf": No such file or directory sendsize: debug 1 pid 15227 ruid 50 euid 50: rename at Thu Jul 23 12:01:15 2009 * sendsize[15227]: time 0.541: REQ packet is bogus: no dumpdate sendsize: time 0.541: pid 15227 finish time Thu Jul 23 12:01:15 2009 amandad agrees: < OPTIONS features=9ffe00; FORMAT ERROR IN REQUEST PACKET > amandad: udpbsd_sendpkt: enter amandad: time 8.705: bsd: pkthdr2str handle '000-0001' amandad: time 8.705: sec: udpbsd_sendpkt: PREP (2) pkt_t (len 72) contains: "OPTIONS features=9ffe00; FORMAT ERROR IN REQUEST PACKET " sendsize functioned (imperfectly) on 2.5.1. The effort to move from 2.5.1 to 2.5.2 is an attempt to gain 'rep_tries' in amanda-client.conf. The client conf file says: connect_tries 10 rep_tries 50 debug_amandad 1 debug_amidxtaped 1 debug_amindexd 1 debug_amrecover 1 debug_auth 1 debug_event 1 debug_holding 1 debug_protocol 1 debug_selfcheck 1 debug_sendsize 1 debug_sendbackup 1 disklist entries for the client all use spindle -1. The client has its own dumptype entry that says 'maxdumps 6', and otherwise inherits the usual gtar parameters. The problem is consistently re-produceable, before and after 'amadmin delete' of the Solaris 10 client. Hoping that someone can provide some guidance or suggestions. Bryan On Tue, Jul 14, 2009 at 10:49:36AM -0400, Bryan wrote: Folks, We've been running 2.4.x (presently 2.4.4p1) on Solaris 9 since 2002 (and earlier versions back to about 1997 ..). The 2.4.4 release has been enormously successful, and has saved our tail feathers any number of times. Clients are Solaris and Linux of various vintages (including some Fedora that should be retired.) We're bringing up ZFS file systems; looks like it's time to move to 2.6.1. I've read the UPGRADING file in the distribution, and am seeking guidance on some finer points. We keep daily backups for 4 weeks, weeklies for 4 months, and monthlies for 1 year. Can I expect that 2.6.1 amanda will be able to 'amadmin find' and recover tapes written by 2.4.4? (My guess is 'yes'.) Is there compelling merit to doing an upgrade to 2.5.1 as a tranisitional step? (Guess = no). Updating all of the clients in one fell swoop would present challenges. A number of client machines (but not all) are presently running 2.5.1, the result of a prior but incomplete attempt to upgrade. The 2.5.1 clients work fine with the 2.4.4 server. Can I expect the older clients to work with a 2.6.1 server? (Guess = I hope so.) Or should I upgrade the clients first and the server second? (Guess = no.) My guesses are just that, and have no basis. Some guidance (even if only more informed guesses) would be appreciated. Thank you. Bryan
Re: Upgrading amanda
Looking for some guidance on a perplexing problem, plus a summary update on my earlier note (below): Answers to my earlier questions were 'all works with 2.5.1p3'. However, 2.5.1 is problematic for a client with ~750 ZFS file systems; on test and production runs, variously 10% to 50% of the client's ZFS file systems failed to back up due to missing ACKs on sendsize. Building 2.6.x on a SUNWCreq installation on Solaris 9/10 with SUNWspro 12 and/or SUNWgccfss was NOT successful (after current glib / pkg-config were installed). It builds on a SUNWCprog cluster installation. Will investigate this further later. Current problem: Moving from 2.5.1 to 2.5.2 ... Solaris 9 server, Solaris 10 client, both running 2.5.2p1, both built (no problems noted) with SUNWspro 12. Tape loads OK, bsd auth, client selfcheck succeeds, client sendsize fails, apparently due to: sendsize: debug 1 pid 15227 ruid 50 euid 50: start at Thu Jul 23 12:01:15 2009 sendsize: version 2.5.2p1 Reading conf file "/etc/amanda/amanda-client.conf". Could not open conf file "/etc/amanda/DAILY/amanda-client.conf": No such file or directory sendsize: debug 1 pid 15227 ruid 50 euid 50: rename at Thu Jul 23 12:01:15 2009 * sendsize[15227]: time 0.541: REQ packet is bogus: no dumpdate sendsize: time 0.541: pid 15227 finish time Thu Jul 23 12:01:15 2009 amandad agrees: < OPTIONS features=9ffe00; FORMAT ERROR IN REQUEST PACKET > amandad: udpbsd_sendpkt: enter amandad: time 8.705: bsd: pkthdr2str handle '000-0001' amandad: time 8.705: sec: udpbsd_sendpkt: PREP (2) pkt_t (len 72) contains: "OPTIONS features=9ffe00; FORMAT ERROR IN REQUEST PACKET " sendsize functioned (imperfectly) on 2.5.1. The effort to move from 2.5.1 to 2.5.2 is an attempt to gain 'rep_tries' in amanda-client.conf. The client conf file says: connect_tries 10 rep_tries 50 debug_amandad 1 debug_amidxtaped 1 debug_amindexd 1 debug_amrecover 1 debug_auth 1 debug_event 1 debug_holding 1 debug_protocol 1 debug_selfcheck 1 debug_sendsize 1 debug_sendbackup 1 disklist entries for the client all use spindle -1. The client has its own dumptype entry that says 'maxdumps 6', and otherwise inherits the usual gtar parameters. The problem is consistently re-produceable, before and after 'amadmin delete' of the Solaris 10 client. Hoping that someone can provide some guidance or suggestions. Bryan On Tue, Jul 14, 2009 at 10:49:36AM -0400, Bryan wrote: > > Folks, > > We've been running 2.4.x (presently 2.4.4p1) on Solaris 9 since > 2002 (and earlier versions back to about 1997 ..). The 2.4.4 > release has been enormously successful, and has saved our tail > feathers any number of times. Clients are Solaris and Linux of > various vintages (including some Fedora that should be retired.) > > We're bringing up ZFS file systems; looks like it's time to move > to 2.6.1. I've read the UPGRADING file in the distribution, and > am seeking guidance on some finer points. > > We keep daily backups for 4 weeks, weeklies for 4 months, and > monthlies for 1 year. Can I expect that 2.6.1 amanda will be > able to 'amadmin find' and recover tapes written by 2.4.4? (My > guess is 'yes'.) Is there compelling merit to doing an upgrade to > 2.5.1 as a tranisitional step? (Guess = no). > > Updating all of the clients in one fell swoop would present > challenges. > > A number of client machines (but not all) are presently running > 2.5.1, the result of a prior but incomplete attempt to upgrade. > The 2.5.1 clients work fine with the 2.4.4 server. Can I expect > the older clients to work with a 2.6.1 server? (Guess = I hope > so.) Or should I upgrade the clients first and the server > second? (Guess = no.) > > My guesses are just that, and have no basis. Some guidance (even > if only more informed guesses) would be appreciated. > > Thank you. > > Bryan
Upgrading amanda
Folks, We've been running 2.4.x (presently 2.4.4p1) on Solaris 9 since 2002 (and earlier versions back to about 1997 ..). The 2.4.4 release has been enormously successful, and has saved our tail feathers any number of times. Clients are Solaris and Linux of various vintages (including some Fedora that should be retired.) We're bringing up ZFS file systems; looks like it's time to move to 2.6.1. I've read the UPGRADING file in the distribution, and am seeking guidance on some finer points. We keep daily backups for 4 weeks, weeklies for 4 months, and monthlies for 1 year. Can I expect that 2.6.1 amanda will be able to 'amadmin find' and recover tapes written by 2.4.4? (My guess is 'yes'.) Is there compelling merit to doing an upgrade to 2.5.1 as a tranisitional step? (Guess = no). Updating all of the clients in one fell swoop would present challenges. A number of client machines (but not all) are presently running 2.5.1, the result of a prior but incomplete attempt to upgrade. The 2.5.1 clients work fine with the 2.4.4 server. Can I expect the older clients to work with a 2.6.1 server? (Guess = I hope so.) Or should I upgrade the clients first and the server second? (Guess = no.) My guesses are just that, and have no basis. Some guidance (even if only more informed guesses) would be appreciated. Thank you. Bryan
Re: Fwd: Re: upgrading amanda to 2.5.0
On Fri, Jul 21, 2006 at 10:21:50AM +0100, Rodrigo Ventura wrote: > > Hi. I'm forwarding this mail that ought to go to amanda-users in the first > place. > > -- Forwarded Message -- > > Subject: Re: upgrading amanda to 2.5.0 > Date: Thursday 20 July 2006 16:27 > From: Rodrigo Ventura <[EMAIL PROTECTED]> > To: Jean-Louis Martineau <[EMAIL PROTECTED]> > > On Thursday 20 July 2006 12:23, you wrote: > > > 1- is there any upgrade issue between 2.4.4 and 2.5.0? Since there is an > > > UPGRADE file, can I assume there is none? > > > > It should not. > > amcheck reported two trivial issues after the upgrade: > > (1) the ~amanda/.amandahosts with wrong permission (must only be readable by > root), and it was not the case here; I think that should be readable by only the "amanda user" which typically is not root. > > (2) I had a couple of DLE's which include did not include any file, leading > amcheck to complain an error of "No include for...". > > (I'm not sure whether the other version did complain about this last item...) I don't think amcheck would complain about "include" files unless you have an "include list" directive in the dumptype. It is not very common for all DLEs to have (or need) "include list" directives. If you want to keep the arrangement you have, add the "optional" argument to the "include list" directive. That will tell amcheck to not complain if the file is missing. -- Jon H. LaBadie [EMAIL PROTECTED] JG Computing 4455 Province Line Road(609) 252-0159 Princeton, NJ 08540-4322 (609) 683-7220 (fax)
Fwd: Re: upgrading amanda to 2.5.0
Hi. I'm forwarding this mail that ought to go to amanda-users in the first place. -- Forwarded Message -- Subject: Re: upgrading amanda to 2.5.0 Date: Thursday 20 July 2006 16:27 From: Rodrigo Ventura <[EMAIL PROTECTED]> To: Jean-Louis Martineau <[EMAIL PROTECTED]> On Thursday 20 July 2006 12:23, you wrote: > > 1- is there any upgrade issue between 2.4.4 and 2.5.0? Since there is an > > UPGRADE file, can I assume there is none? > > It should not. amcheck reported two trivial issues after the upgrade: (1) the ~amanda/.amandahosts with wrong permission (must only be readable by root), and it was not the case here; (2) I had a couple of DLE's which include did not include any file, leading amcheck to complain an error of "No include for...". (I'm not sure whether the other version did complain about this last item...) Cheers, Rodrigo -- *** Rodrigo Martins de Matos Ventura <[EMAIL PROTECTED]> *** Web page: http://www.isr.ist.utl.pt/~yoda *** Teaching Assistant and PhD Student at ISR: ***Instituto de Sistemas e Robotica, Polo de Lisboa *** Instituto Superior Tecnico, Lisboa, PORTUGAL *** PGP fingerprint = 0119 AD13 9EEE 264A 3F10 31D3 89B3 C6C4 60C6 4585 --- -- *** Rodrigo Martins de Matos Ventura <[EMAIL PROTECTED]> *** Web page: http://www.isr.ist.utl.pt/~yoda *** Teaching Assistant and PhD Student at ISR: ***Instituto de Sistemas e Robotica, Polo de Lisboa *** Instituto Superior Tecnico, Lisboa, PORTUGAL *** PGP fingerprint = 0119 AD13 9EEE 264A 3F10 31D3 89B3 C6C4 60C6 4585
Re: upgrading amanda to 2.5.0
Rodrigo Ventura wrote: Hi all, regarding upgrading amanda to 2.5.0 (from 2.4.4) I have a couple of questions: 1- is there any upgrade issue between 2.4.4 and 2.5.0? Since there is an UPGRADE file, can I assume there is none? It should not. 2- I'm a bit confused about the patch levels; the amanda web page announces 2.5.0-p1 as the stable one, but there is a 2.5.0-p2 available; however, it is announced as an untested snapshot, but still, some mails on this list announce it as the latest patched version. Do you recomend p2 over p1? The latest stable release is 2.5.0p2, I fixed the web page. Jean-Louis
upgrading amanda to 2.5.0
Hi all, regarding upgrading amanda to 2.5.0 (from 2.4.4) I have a couple of questions: 1- is there any upgrade issue between 2.4.4 and 2.5.0? Since there is an UPGRADE file, can I assume there is none? 2- I'm a bit confused about the patch levels; the amanda web page announces 2.5.0-p1 as the stable one, but there is a 2.5.0-p2 available; however, it is announced as an untested snapshot, but still, some mails on this list announce it as the latest patched version. Do you recomend p2 over p1? Cheers, Rodrigo -- *** Rodrigo Martins de Matos Ventura <[EMAIL PROTECTED]> *** Web page: http://www.isr.ist.utl.pt/~yoda *** Teaching Assistant and PhD Student at ISR: ***Instituto de Sistemas e Robotica, Polo de Lisboa *** Instituto Superior Tecnico, Lisboa, PORTUGAL *** PGP fingerprint = 0119 AD13 9EEE 264A 3F10 31D3 89B3 C6C4 60C6 4585
Re: Upgrading Amanda
Kevin D. Alford wrote: I am looking for the procedures required to upgrade from 2.4.2p2 to 2.4.4p3. Your assistance in this matter is greatly appreciated. The versions are compatibel. You may upgrade the server and/or clients in a phased rollout if you like. First choose a less important client, compile and install on that one. A few days later, do the other clients, and then some days later the server. If you have trouble compiling for some strange clients (e.g. lack of a decent compiler) you are not obliged to upgrade that one. -- Paul Bijnens, XplanationTel +32 16 397.511 Technologielaan 21 bus 2, B-3001 Leuven, BELGIUMFax +32 16 397.512 http://www.xplanation.com/ email: [EMAIL PROTECTED] *** * I think I've got the hang of it now: exit, ^D, ^C, ^\, ^Z, ^Q, F6, * * quit, ZZ, :q, :q!, M-Z, ^X^C, logoff, logout, close, bye, /bye, * * stop, end, F3, ~., ^]c, +++ ATH, disconnect, halt, abort, hangup, * * PF4, F20, ^X^X, :D::D, KJOB, F14-f-e, F8-e, kill -1 $$, shutdown, * * kill -9 1, Alt-F4, Ctrl-Alt-Del, AltGr-NumLock, Stop-A, ...* * ... "Are you sure?" ... YES ... Phew ... I'm out * ***
Re: Upgrading Amanda
On Friday 23 July 2004 13:19, Kevin D. Alford wrote: >I am looking for the procedures required to upgrade from 2.4.2p2 to >2.4.4p3. > >Your assistance in this matter is greatly appreciated. > >Kevin D. Alford >Sr. Systems Engineer >TMC Technologies, Inc. >(304)368-1862 Ext. 53 Kevin, can I asume you are running the rpms now? And that you have the -devel tools like gcc onboard? If so, rip them out with an rpm -e amanda*, and build it from scratch, unpacking the tarball as root, and then doing a "chown -R amanda:disk amanda-version-number", then copying this script into that diirectory, setting its perms and ownership as above, then using this script (with suitable mods of course) invoked as ./gh.cf. Or you could call a shell to run it also. -- #!/bin/sh # since I'm always forgetting to su amanda... if [ `whoami` != 'amanda' ]; then echo echo " Warning " echo "Amanda needs to be configured and built by the user amanda," echo "but must be installed by user root." echo exit 1 fi make clean rm -f config.status config.cache ./configure --with-user=amanda \ --with-group=disk \ --with-owner=amanda \ --with-tape-device=/dev/nst0 \ --with-changer-device=/dev/sg1 \ --with-gnu-ld --prefix=/usr/local \ --with-debugging=/tmp/amanda-dbg/ \ --with-tape-server=coyote.coyote.den \ --with-amandahosts \ --with-configdir=/usr/local/etc/amanda make You will need a user named 'amanda' who is a member of group 'disk', or to modify those statements above to fit your situation. If you don't use a tape changer, remove that line, and of course fix the --with-tape-server= line to reflect the FQDN of the machine that houses the drive. If your current config dir isn't there, make that line match your environment. Once this script has run and made amanda, then become root, enter the dir again, and do a make install. (or one could install it with checkinstall, which makes an rpm out of it, and then installs the rpm) Your current crontab entries and such should remain functional, but you may want to look at the sample amanda.conf in the src tree for new features you may want to use. I hope this helps. -- Cheers, Gene There are 4 boxes to be used in defense of liberty. Soap, ballot, jury, and ammo. Please use in that order, starting now. -Ed Howdershelt, Author Additions to this message made by Gene Heskett are Copyright 2004, Maurice E. Heskett, all rights reserved.
Upgrading Amanda
I am looking for the procedures required to upgrade from 2.4.2p2 to 2.4.4p3. Your assistance in this matter is greatly appreciated. Kevin D. Alford Sr. Systems Engineer TMC Technologies, Inc. (304)368-1862 Ext. 53
