Re: Amanda must be run as user amandabackup when using bsdtcp authentication
Maybe, but I have another machine with the exact same inetadm output and that one works fine so it's not the cause of this specific problem Abilio On May 19, 2009, at 5:31 AM, Frank Smith wrote: Abilio Carvalho wrote: Anyone? I'm kinda lost at a problem that seems so basic, and I could really use a second pair of eyes. As far as I can see, all config files are correct, permissions on /tmp and /var amanda subdirectories are fine, etc. It's NOT just a case of me overlooking something that can be found on the 15 mins amanda backup doc. At least, I don't think so. Thanks Abilio On May 18, 2009, at 5:30 PM, Abilio Carvalho wrote: I'm getting this when I do am amcheck -c, but I don't know what I'm missing. Here's the relevant data: Server works: I have 6 hosts configured, only 1 is failing. Client that fails is a new install I'm doing atm. amanda was configured with: ./configure --without-server --with- user=amandabackup --with-group=disk --prefix= --with-amandahosts -- without-ipv6 /var/lib/amanda and the .amandahosts in it is owned by amandabackup:disk output of inetadm -l svc:/network/amanda/tcp is: SCOPENAME=VALUE name=amanda endpoint_type=stream proto=tcp isrpc=FALSE wait=FALSE exec=/libexec/amanda/amandad -auth=bsdtcp user=amandabackup default bind_addr= default bind_fail_max=-1 default bind_fail_interval=-1 default max_con_rate=-1 default max_copies=-1 default con_rate_offline=-1 default failrate_cnt=40 default failrate_interval=60 default inherit_env=TRUE default tcp_trace=FALSE default tcp_wrappers=FALSE Can you help me figure out what unbelievably basic thing I missed? Thanks Shouldn't the 'wait' parameter be 'true'? Frank -- Frank Smith fsm...@hoovers.com Sr. Systems Administrator Voice: 512-374-4673 Hoover's Online Fax: 512-374-4501 --- This e-mail is strictly confidential and may be privileged. It is intended solely for the addressee. If you are not the intended recipient, any copying, distribution or any other use of this message is prohibited and may be unlawful. In such case, please notify the sender Immediately and destroy this e-mail.
Re: Amanda must be run as user amandabackup when using bsdtcp authentication
the prefix with no argument is how the config.log interprets prefix='', which I did to install amanda in the default directories rather than inside a specific subdir. Again, like frank's attempt I have another machine with the same config options and that one works fine. Cheers Abilio On May 19, 2009, at 5:21 AM, Gene Heskett wrote: On Monday 18 May 2009, Abilio Carvalho wrote: Anyone? I'm kinda lost at a problem that seems so basic, and I could really use a second pair of eyes. As far as I can see, all config files are correct, permissions on /tmp and /var amanda subdirectories are fine, etc. It's NOT just a case of me overlooking something that can be found on the 15 mins amanda backup doc. At least, I don't think so. Thanks Abilio On May 18, 2009, at 5:30 PM, Abilio Carvalho wrote: I'm getting this when I do am amcheck -c, but I don't know what I'm missing. Here's the relevant data: Server works: I have 6 hosts configured, only 1 is failing. Client that fails is a new install I'm doing atm. amanda was configured with: ./configure --without-server --with- user=amandabackup --with-group=disk --prefix= --with-amandahosts -- without-ipv6 Ahh, whats the '--prefix=' but no argument for it? Other than that you are enough different from my setup I'm afraid I'm not going to be able to help. /var/lib/amanda and the .amandahosts in it is owned by amandabackup:disk output of inetadm -l svc:/network/amanda/tcp is: SCOPENAME=VALUE name=amanda endpoint_type=stream proto=tcp isrpc=FALSE wait=FALSE exec=/libexec/amanda/amandad -auth=bsdtcp user=amandabackup default bind_addr= default bind_fail_max=-1 default bind_fail_interval=-1 default max_con_rate=-1 default max_copies=-1 default con_rate_offline=-1 default failrate_cnt=40 default failrate_interval=60 default inherit_env=TRUE default tcp_trace=FALSE default tcp_wrappers=FALSE Can you help me figure out what unbelievably basic thing I missed? Thanks -- - This e-mail is strictly confidential and may be privileged. It is intended solely for the addressee. If you are not the intended recipient, any copying, distribution or any other use of this message is prohibited and may be unlawful. In such case, please notify the sender Immediately and destroy this e-mail. -- -- --- This e-mail is strictly confidential and may be privileged. It is intended solely for the addressee. If you are not the intended recipient, any copying, distribution or any other use of this message is prohibited and may be unlawful. In such case, please notify the sender Immediately and destroy this e-mail. -- Cheers, Gene There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) Prizes are for children. -- Charles Ives, upon being given, but refusing, the Pulitzer prize --- This e-mail is strictly confidential and may be privileged. It is intended solely for the addressee. If you are not the intended recipient, any copying, distribution or any other use of this message is prohibited and may be unlawful. In such case, please notify the sender Immediately and destroy this e-mail.
Re: support for tape library sun sl24 or sun sl48
Hi,
does any has experiences with amanda and sun(storagetek) sl24 or better
sl48 with 2 lto4 tape drives?
the tape drives are normal lto4 tape drive from HP.
Or can I simply take the configuration from the Arcvault 48 - HP LTO4-800
tape?
best regards,
Uwe
2009/5/18 Paul Bijnens paul.bijn...@xplanation.com
On 2009-05-18 16:28, Uwe Bartels wrote:
Hi,
does anybody know if the tape library sun(storagetek) sl24 or
sun(storagetek) sl48 with 2 lto4 tape drives are working?
If so. how are the general parameters, which i'm missing in the Tape Type
List http://wiki.zmanda.com/index.php/Tapetype%20definitions .
http://wiki.zmanda.com/index.php/Tapetype_definitions#LTO4
Dell PowerVault LTO4-120 - LTO4-800 tape
define tapetype LTO4 {
comment Dell LTO4 800Gb - Compression Off
length 802816 mbytes
filemark 0 kbytes
speed 52616 kps
}
Arcvault 48 - HP LTO4-800 tape
define tapetype HPLTO4 {
comment HP LTO4 800gb - Compression Off
length 772096 mbytes
filemark 0 kbytes
speed 31368 kps
}
Re: restore over multiple tape
Do you think I have to split as much as possible the big diskset into multiple little diskset for amanda to be able to restore as fast as possible without having to scan a complete librairy ? Franck Dustin J. Mitchell a écrit : On Mon, May 18, 2009 at 11:41 AM, Franck GANACHAUD franck.ganach...@altran.com wrote: The question behind is, does amanda have to restore the five tapes, concat the dump and tar xzf over the result? Yes -- it does exactly that. There's talk of how to fix that using the Application API, but it's still a long way off. Beyond the sheer volume of work to implement it, I think the major challenge will be handling and storing the metadata describing the location of a particular tar file without using so much overhead as to render it unusable. Dustin
Re: Amanda must be run as user amandabackup when using bsdtcp authentication
Done further tests, still no explanation. Amandahosts on the client is: BACKUPHOST.bbp.ch amandabackup amdump BACKUPHOST amandabackup amdump inetadm -l svc:/network/amanda/tcp on the client returns: SCOPENAME=VALUE name=amanda endpoint_type=stream proto=tcp isrpc=FALSE wait=FALSE exec=/libexec/amanda/amandad -auth=bsdtcp amdump user=amandabackup default bind_addr= default bind_fail_max=-1 default bind_fail_interval=-1 default max_con_rate=-1 default max_copies=-1 default con_rate_offline=-1 default failrate_cnt=40 default failrate_interval=60 default inherit_env=TRUE default tcp_trace=FALSE default tcp_wrappers=FALSE the log directory on the client only has the following: r...@backupclient:/tmp/amanda/amandad# cat amandad.20090519111556.debug 1242724556.328466: amandad: pid 18933 ruid 0 euid 0 version 2.6.1: start at Tue May 19 11:15:56 2009 1242724556.339271: amandad: security_getdriver(name=bsdtcp) returns ff31c788 1242724556.339369: amandad: critical (fatal): Amanda must be run as user 'amandabackup' when using 'bsdtcp' authentication I can't even see what user it's TRYING to use, only that it should be running as amandabackup. All relevant config files tell me that it IS. Any way to get more descriptive logs? I tried debug_amandad on the amanda-client.conf, but that had no effect please help Abilio --- This e-mail is strictly confidential and may be privileged. It is intended solely for the addressee. If you are not the intended recipient, any copying, distribution or any other use of this message is prohibited and may be unlawful. In such case, please notify the sender Immediately and destroy this e-mail.
Re: Amanda must be run as user amandabackup when using bsdtcp authentication
Abilio Carvalho wrote: the log directory on the client only has the following: r...@backupclient:/tmp/amanda/amandad# cat amandad.20090519111556.debug 1242724556.328466: amandad: pid 18933 ruid 0 euid 0 version 2.6.1: start at Tue May 19 11:15:56 2009 ruid 0 euid 0 That's root user Do you have an amandabackup user on the client Check inet log Jean-Louis 1242724556.339271: amandad: security_getdriver(name=bsdtcp) returns ff31c788 1242724556.339369: amandad: critical (fatal): Amanda must be run as user 'amandabackup' when using 'bsdtcp' authentication I can't even see what user it's TRYING to use, only that it should be running as amandabackup. All relevant config files tell me that it IS. Any way to get more descriptive logs? I tried debug_amandad on the amanda-client.conf, but that had no effect please help Abilio --- This e-mail is strictly confidential and may be privileged. It is intended solely for the addressee. If you are not the intended recipient, any copying, distribution or any other use of this message is prohibited and may be unlawful. In such case, please notify the sender Immediately and destroy this e-mail.
Re: Amanda must be run as user amandabackup when using bsdtcp authentication
Yes, the user amandabackup exists, as you can see it owns all the amanda-related files. I've checked nsswitch.conf and it's checking files before nisplus on passwd, so that's not it. I'm unsure what you mean by inetd log, but from what I've searched it's enabling tcp_trace and tcp_wrappers on the amanda service and check the syslog for any inetd related entries. Nothing shows up, including on a tail -f syslog while I try to connect from the server with amcheck. Can you be more specific about which log to check/use if what I did was not it? Thank you for the response, though. I'm going slightly insane here Abilio On May 19, 2009, at 1:37 PM, Jean-Louis Martineau wrote: Abilio Carvalho wrote: the log directory on the client only has the following: r...@backupclient:/tmp/amanda/amandad# cat amandad. 20090519111556.debug 1242724556.328466: amandad: pid 18933 ruid 0 euid 0 version 2.6.1: start at Tue May 19 11:15:56 2009 ruid 0 euid 0 That's root user Do you have an amandabackup user on the client Check inet log Jean-Louis 1242724556.339271: amandad: security_getdriver(name=bsdtcp) returns ff31c788 1242724556.339369: amandad: critical (fatal): Amanda must be run as user 'amandabackup' when using 'bsdtcp' authentication I can't even see what user it's TRYING to use, only that it should be running as amandabackup. All relevant config files tell me that it IS. Any way to get more descriptive logs? I tried debug_amandad on the amanda-client.conf, but that had no effect please help Abilio --- This e-mail is strictly confidential and may be privileged. It is intended solely for the addressee. If you are not the intended recipient, any copying, distribution or any other use of this message is prohibited and may be unlawful. In such case, please notify the sender Immediately and destroy this e-mail. --- This e-mail is strictly confidential and may be privileged. It is intended solely for the addressee. If you are not the intended recipient, any copying, distribution or any other use of this message is prohibited and may be unlawful. In such case, please notify the sender Immediately and destroy this e-mail.
Re: Amanda must be run as user amandabackup when using bsdtcp authentication
follow-up: I was wrong, it wasn't syslog, it was messages. There I now see a couple lines like: May 19 13:58:23 galadhrim inetd[24015]: [ID 317013 daemon.notice] amanda[27116] from 172.22.0.23 44223 May 19 13:58:31 galadhrim inetd[24015]: [ID 317013 daemon.notice] amanda[27214] from 172.22.0.23 703 May 19 13:59:12 galadhrim inetd[24015]: [ID 317013 daemon.notice] amanda[27619] from 172.22.0.23 703 On May 19, 2009, at 1:37 PM, Jean-Louis Martineau wrote: Abilio Carvalho wrote: the log directory on the client only has the following: r...@backupclient:/tmp/amanda/amandad# cat amandad. 20090519111556.debug 1242724556.328466: amandad: pid 18933 ruid 0 euid 0 version 2.6.1: start at Tue May 19 11:15:56 2009 ruid 0 euid 0 That's root user Do you have an amandabackup user on the client Check inet log Jean-Louis 1242724556.339271: amandad: security_getdriver(name=bsdtcp) returns ff31c788 1242724556.339369: amandad: critical (fatal): Amanda must be run as user 'amandabackup' when using 'bsdtcp' authentication I can't even see what user it's TRYING to use, only that it should be running as amandabackup. All relevant config files tell me that it IS. Any way to get more descriptive logs? I tried debug_amandad on the amanda-client.conf, but that had no effect please help Abilio --- This e-mail is strictly confidential and may be privileged. It is intended solely for the addressee. If you are not the intended recipient, any copying, distribution or any other use of this message is prohibited and may be unlawful. In such case, please notify the sender Immediately and destroy this e-mail. --- This e-mail is strictly confidential and may be privileged. It is intended solely for the addressee. If you are not the intended recipient, any copying, distribution or any other use of this message is prohibited and may be unlawful. In such case, please notify the sender Immediately and destroy this e-mail.
exclude lists
I have defined an exclude list in a dumptype using exclude list /etc/amanda/DailySet1/exclude-list with entries like $ cat /etc/amanda/DailySet1/exclude-list ./dumps ./opt/dell/srvadmin/shared/.ipc I have a couple of questions about the entries. Based on the documentation I've read and the tests I've run, the leading '.' is required which means these are relative paths to the device where these directories live. First, am I correct in thinking the '.' are required? If so, how can Amanda be told to exclude, for example, /dumps on sda1 but still backup /dumps on sda2 other than defining different dumps types with their own exclude list? Thanks. -- Brandon
Re: exclude lists
m == martin...@zmanda.com writes: m The '.' is required, all excludes are relative to the dle you back up. m Brandon Metcalf wrote: m I have defined an exclude list in a dumptype using m mexclude list /etc/amanda/DailySet1/exclude-list m m with entries like m m$ cat /etc/amanda/DailySet1/exclude-list m./dumps m./opt/dell/srvadmin/shared/.ipc m m I have a couple of questions about the entries. Based on the m documentation I've read and the tests I've run, the leading '.' is m required which means these are relative paths to the device where m these directories live. m m First, am I correct in thinking the '.' are required? If so, how can m Amanda be told to exclude, for example, /dumps on sda1 but still m backup /dumps on sda2 other than defining different dumps types with m their own exclude list? m m You can't. Seems like a nice feature would be to allow the DLE to be specified in the exclude list. -- Brandon
Re: Amanda must be run as user amandabackup when using bsdtcp authentication
owner is amandabackup:disk I can log in to the account just fine, I don't think any more logging is possible though I'll check. I checked the manifest for the service and it confirms that it is SUPPOSED to start as amandabackup. If I do what you say, and log into amandabackup and run that, I get the following on /tmp/amanda/amandad/amandad.TIMESTAMP.debug: 1242737635.958239: amandad: pid 9504 ruid 6028 euid 6028 version 2.6.1: start at Tue May 19 14:53:55 2009 1242737635.989035: amandad: security_getdriver(name=bsdtcp) returns ff31c788 1242737635.992943: amandad: version 2.6.1 1242737635.992955: amandad: build: VERSION=Amanda-2.6.1 1242737635.992961: amandad:BUILT_DATE=Mon May 18 12:33:06 CEST 2009 1242737635.992967: amandad:BUILT_MACH=sparc-sun- solaris2.10 BUILT_REV=1609 1242737635.992973: amandad:BUILT_BRANCH=amanda-261 CC=/ opt/SUNWspro/bin/cc 1242737635.992979: amandad: paths: bindir=/bin sbindir=/sbin libexecdir=/libexec 1242737635.992984: amandad:amlibexecdir=/libexec/amanda mandir=/share/man 1242737635.992990: amandad:AMANDA_TMPDIR=/tmp/amanda AMANDA_DBGDIR=/tmp/amanda 1242737635.992995: amandad:CONFIG_DIR=/etc/amanda DEV_PREFIX=/dev/dsk/ 1242737635.993000: amandad:RDEV_PREFIX=/dev/rdsk/ DUMP=/ usr/sbin/ufsdump 1242737635.993005: amandad:RESTORE=/usr/sbin/ufsrestore VDUMP=UNDEF VRESTORE=UNDEF 1242737635.993011: amandad:XFSDUMP=UNDEF XFSRESTORE=UNDEF VXDUMP=UNDEF VXRESTORE=UNDEF 1242737635.993016: amandad:SAMBA_CLIENT=/usr/sfw/bin/ smbclient 1242737635.993021: amandad:GNUTAR=/usr/sfw/bin/gtar COMPRESS_PATH=/usr/bin/gzip 1242737635.993026: amandad:UNCOMPRESS_PATH=/usr/bin/gzip LPRCMD=/usr/bin/lp 1242737635.993032: amandad: MAILER=UNDEF listed_incr_dir=/ var/amanda/gnutar-lists 1242737635.993037: amandad: defs: DEFAULT_SERVER=galadhrim DEFAULT_CONFIG=DailySet1 1242737635.993042: amandad:DEFAULT_TAPE_SERVER=galadhrim DEFAULT_TAPE_DEVICE= 1242737635.993047: amandad:HAVE_MMAP NEED_STRSTR HAVE_SYSVSHM AMFLOCK_POSIX AMFLOCK_LOCKF 1242737635.993053: amandad:AMFLOCK_LNLOCK SETPGRP_VOID AMANDA_DEBUG_DAYS=4 BSD_SECURITY 1242737635.993058: amandad:USE_AMANDAHOSTS CLIENT_LOGIN=amandabackup CHECK_USERID 1242737635.993063: amandad:HAVE_GZIP COMPRESS_SUFFIX=.gz COMPRESS_FAST_OPT=--fast 1242737635.993069: amandad:COMPRESS_BEST_OPT=--best UNCOMPRESS_OPT=-dc 1242737635.997381: amandad: getpeername returned: Socket operation on non-socket 1242737635.997434: amandad: pid 9504 finish time Tue May 19 14:53:55 2009 so it does seem like as inetd problem and not amanda. I just have no clue as to how that's possible On May 19, 2009, at 2:45 PM, Jean-Louis Martineau wrote: Who is the owner of /tmp/amanda/amandad/amandad.20090519111556.debug Can you use the amandabackup account? Can you log to that account? Can you enabled more logging in inetd? It is an inetd misconfiguration if amandad is run as root. Log as amandabackup and run '/libexec/amanda/amandad -auth=bsdtcp amdump' Jean-Louis Abilio Carvalho wrote: follow-up: I was wrong, it wasn't syslog, it was messages. There I now see a couple lines like: May 19 13:58:23 galadhrim inetd[24015]: [ID 317013 daemon.notice] amanda[27116] from 172.22.0.23 44223 May 19 13:58:31 galadhrim inetd[24015]: [ID 317013 daemon.notice] amanda[27214] from 172.22.0.23 703 May 19 13:59:12 galadhrim inetd[24015]: [ID 317013 daemon.notice] amanda[27619] from 172.22.0.23 703 On May 19, 2009, at 1:37 PM, Jean-Louis Martineau wrote: Abilio Carvalho wrote: the log directory on the client only has the following: r...@backupclient:/tmp/amanda/amandad# cat amandad. 20090519111556.debug 1242724556.328466: amandad: pid 18933 ruid 0 euid 0 version 2.6.1: start at Tue May 19 11:15:56 2009 ruid 0 euid 0 That's root user Do you have an amandabackup user on the client Check inet log Jean-Louis 1242724556.339271: amandad: security_getdriver(name=bsdtcp) returns ff31c788 1242724556.339369: amandad: critical (fatal): Amanda must be run as user 'amandabackup' when using 'bsdtcp' authentication I can't even see what user it's TRYING to use, only that it should be running as amandabackup. All relevant config files tell me that it IS. Any way to get more descriptive logs? I tried debug_amandad on the amanda-client.conf, but that had no effect please help Abilio --- This e-mail is strictly confidential and may be privileged. It is intended solely for the addressee. If you are not the intended recipient, any copying, distribution or any other use of this message is prohibited and may be unlawful. In such case, please notify the
Re: exclude lists
Brandon Metcalf wrote: m First, am I correct in thinking the '.' are required? If so, how can m Amanda be told to exclude, for example, /dumps on sda1 but still m backup /dumps on sda2 other than defining different dumps types with m their own exclude list? m m You can't. Seems like a nice feature would be to allow the DLE to be specified in the exclude list. The 'exclude list' can be a relative path to the dle.
Re: exclude lists
The '.' is required, all excludes are relative to the dle you back up. Brandon Metcalf wrote: I have defined an exclude list in a dumptype using exclude list /etc/amanda/DailySet1/exclude-list with entries like $ cat /etc/amanda/DailySet1/exclude-list ./dumps ./opt/dell/srvadmin/shared/.ipc I have a couple of questions about the entries. Based on the documentation I've read and the tests I've run, the leading '.' is required which means these are relative paths to the device where these directories live. First, am I correct in thinking the '.' are required? If so, how can Amanda be told to exclude, for example, /dumps on sda1 but still backup /dumps on sda2 other than defining different dumps types with their own exclude list? You can't. Jean-Louis
Re: exclude lists
m == martin...@zmanda.com writes: m Brandon Metcalf wrote: m m First, am I correct in thinking the '.' are required? If so, how can m m Amanda be told to exclude, for example, /dumps on sda1 but still m m backup /dumps on sda2 other than defining different dumps types with m m their own exclude list? m m m m You can't. m m m Seems like a nice feature would be to allow the DLE to be specified in m the exclude list. m m The 'exclude list' can be a relative path to the dle. So, you're saying I can specify one dumptype with exclude list ./amanda/DailySet1/exclude-list or is it exclude list amanda/DailySet1/exclude-list and have this file exist on each DLE?
Re: exclude lists
Brandon Metcalf wrote: m == martin...@zmanda.com writes: m Brandon Metcalf wrote: m m First, am I correct in thinking the '.' are required? If so, how can m m Amanda be told to exclude, for example, /dumps on sda1 but still m m backup /dumps on sda2 other than defining different dumps types with m m their own exclude list? m m m m You can't. m m m Seems like a nice feature would be to allow the DLE to be specified in m the exclude list. m m The 'exclude list' can be a relative path to the dle. So, you're saying I can specify one dumptype with exclude list ./amanda/DailySet1/exclude-list or is it exclude list amanda/DailySet1/exclude-list Both works. and have this file exist on each DLE? Yes. Jean-Louis
Re: exclude lists
On 2009-05-19 15:35, Brandon Metcalf wrote: m == martin...@zmanda.com writes: m m m Seems like a nice feature would be to allow the DLE to be specified in m the exclude list. m m The 'exclude list' can be a relative path to the dle. So, you're saying I can specify one dumptype with exclude list ./amanda/DailySet1/exclude-list or is it exclude list amanda/DailySet1/exclude-list and have this file exist on each DLE? Specify it as: exclude list optional append .exclude-list And have a file (optionally) in the directory of each DLE, e.g. /.exclude-list (only for the root DLE) /var/.exclude-list (only for the /var DLE) /space/.exclude-list (only for the /space DLE) Have a look in the man page for the exact meaning of optional and append. -- Paul Bijnens, Xplanation Technology ServicesTel +32 16 397.525 Interleuvenlaan 86, B-3001 Leuven, BELGIUM Fax +32 16 397.552 *** * I think I've got the hang of it now: exit, ^D, ^C, ^\, ^Z, ^Q, ^^, * * quit, ZZ, :q, :q!, M-Z, ^X^C, logoff, logout, close, bye, /bye, ~., * * stop, end, ^]c, +++ ATH, disconnect, halt, abort, hangup, KJOB, * * ^X^X, :D::D, kill -9 1, kill -1 $$, shutdown, init 0, Alt-F4, * * Alt-f-e, Ctrl-Alt-Del, Alt-SysRq-reisub, Stop-A, AltGr-NumLock, ... * * ... Are you sure? ... YES ... Phew ... I'm out * ***
Re: restore over multiple tape
On Tue, May 19, 2009 at 3:36 AM, Franck GANACHAUD franck.ganach...@altran.com wrote: Do you think I have to split as much as possible the big diskset into multiple little diskset for amanda to be able to restore as fast as possible without having to scan a complete librairy ? Yes, that's the best way to keep restores quick, and also to keep your backup size approximately the same from night to night. Dustin -- Open Source Storage Engineer http://www.zmanda.com
Re: restore over multiple tape
Splitting up your DLE is what I would recommend for a variety of reasons. I'm working with someone now who is configuring the backup of a 3TB raid array to LTO4. Initially they were saying that it needed to be one large DLE. Finally, they agreed to break it up into a bunch of DLE's. They now have it running fairly smoothly. How you do that depends on how the data on the array is organized. But the end result is that it smooths out a lot of things. The backup load is distributed more evenly over the dump cycle, and your recoveries are easier, among other things. Also, I don't recall if you said what kind of tapes or how large the DLE is. All of that comes into play as you design how your backups are configured. --- Chris Hoogendyk - O__ Systems Administrator c/ /'_ --- Biology Geology Departments (*) \(*) -- 140 Morrill Science Center ~~ - University of Massachusetts, Amherst hoogen...@bio.umass.edu --- Erdös 4 Franck GANACHAUD wrote: Do you think I have to split as much as possible the big diskset into multiple little diskset for amanda to be able to restore as fast as possible without having to scan a complete librairy ? Franck Dustin J. Mitchell a écrit : On Mon, May 18, 2009 at 11:41 AM, Franck GANACHAUD franck.ganach...@altran.com wrote: The question behind is, does amanda have to restore the five tapes, concat the dump and tar xzf over the result? Yes -- it does exactly that. There's talk of how to fix that using the Application API, but it's still a long way off. Beyond the sheer volume of work to implement it, I think the major challenge will be handling and storing the metadata describing the location of a particular tar file without using so much overhead as to render it unusable.
Re: support for tape library sun sl24 or sun sl48
I use a lot of Sun equipment, but I haven't splurged on Sun tape drives
(they haven't come up on the education deals for one thing). However, as
you say, the tape drive itself is a standard lto4 from HP. The old
internal DAT drives on some of my Sun servers are also standard HP.
You could use one of the tapetypes from the wiki, but I would be
inclined (as Paul suggested) to run amtapetype. It will take a long
time, but it will spit out a configuration specific to your server, and
you will see how your server handles the tape drive. And, actually, it
would take less time than this thread has been running. ;-)
Then compare your configuration to the published specifications for the
drive (see, e.g.
http://en.wikipedia.org/wiki/Linear_Tape-Open#Generations).
Theoretically, you should get somewhere up around 120MB/s. If you end up
with a speed down around 31MB/s as the one configuration someone posted
on the wiki, then you probably need to evaluate your backup server,
because it's not keeping up with the tape, and the tape is probably
shoe-shining.
---
Chris Hoogendyk
-
O__ Systems Administrator
c/ /'_ --- Biology Geology Departments
(*) \(*) -- 140 Morrill Science Center
~~ - University of Massachusetts, Amherst
hoogen...@bio.umass.edu
---
Erdös 4
Uwe Bartels wrote:
Hi,
does any has experiences with amanda and sun(storagetek) sl24 or
better sl48 with 2 lto4 tape drives?
the tape drives are normal lto4 tape drive from HP.
Or can I simply take the configuration from the Arcvault 48 - HP
LTO4-800 tape?
best regards,
Uwe
2009/5/18 Paul Bijnens paul.bijn...@xplanation.com
mailto:paul.bijn...@xplanation.com
On 2009-05-18 16:28, Uwe Bartels wrote:
Hi,
does anybody know if the tape library sun(storagetek) sl24 or
sun(storagetek) sl48 with 2 lto4 tape drives are working?
If so. how are the general parameters, which i'm missing in
the Tape Type List
http://wiki.zmanda.com/index.php/Tapetype%20definitions .
http://wiki.zmanda.com/index.php/Tapetype_definitions#LTO4
Dell PowerVault LTO4-120 - LTO4-800 tape
define tapetype LTO4 {
comment Dell LTO4 800Gb - Compression Off
length 802816 mbytes
filemark 0 kbytes
speed 52616 kps
}
Arcvault 48 - HP LTO4-800 tape
define tapetype HPLTO4 {
comment HP LTO4 800gb - Compression Off
length 772096 mbytes
filemark 0 kbytes
speed 31368 kps
}
Re: exclude lists
P == paul.bijn...@xplanation.com writes: P On 2009-05-19 15:35, Brandon Metcalf wrote: P m == martin...@zmanda.com writes: P P m P m P m Seems like a nice feature would be to allow the DLE to be specified in P m the exclude list. P m P P m The 'exclude list' can be a relative path to the dle. P P P So, you're saying I can specify one dumptype with P Pexclude list ./amanda/DailySet1/exclude-list P P or is it P Pexclude list amanda/DailySet1/exclude-list P P and have this file exist on each DLE? P Specify it as: P exclude list optional append .exclude-list P And have a file (optionally) in the directory of each DLE, P e.g. /.exclude-list (only for the root DLE) P/var/.exclude-list (only for the /var DLE) P/space/.exclude-list (only for the /space DLE) P Have a look in the man page for the exact meaning of optional and append. Thanks for the feedback from everyone. -- Brandon
Re: restore over multiple tape
I didn't specify these. Original diskset is 250Gb to save to DLT4 35GB tapes using a 8 slots autoloader. I'm going to split this diskset going down one level in the filesystem which will give me a little less than 150 diskset. I just have to think about a mechanism to upgrade the diskset list automaticaly. Fra nck Chris Hoogendyk a écrit : Splitting up your DLE is what I would recommend for a variety of reasons. I'm working with someone now who is configuring the backup of a 3TB raid array to LTO4. Initially they were saying that it needed to be one large DLE. Finally, they agreed to break it up into a bunch of DLE's. They now have it running fairly smoothly. How you do that depends on how the data on the array is organized. But the end result is that it smooths out a lot of things. The backup load is distributed more evenly over the dump cycle, and your recoveries are easier, among other things. Also, I don't recall if you said what kind of tapes or how large the DLE is. All of that comes into play as you design how your backups are configured. --- Chris Hoogendyk - O__ Systems Administrator c/ /'_ --- Biology Geology Departments (*) \(*) -- 140 Morrill Science Center ~~ - University of Massachusetts, Amherst hoogen...@bio.umass.edu --- Erdös 4 Franck GANACHAUD wrote: Do you think I have to split as much as possible the big diskset into multiple little diskset for amanda to be able to restore as fast as possible without having to scan a complete librairy ? Franck Dustin J. Mitchell a écrit : On Mon, May 18, 2009 at 11:41 AM, Franck GANACHAUD franck.ganach...@altran.com wrote: The question behind is, does amanda have to restore the five tapes, concat the dump and tar xzf over the result? Yes -- it does exactly that. There's talk of how to fix that using the Application API, but it's still a long way off. Beyond the sheer volume of work to implement it, I think the major challenge will be handling and storing the metadata describing the location of a particular tar file without using so much overhead as to render it unusable.
Re: restore over multiple tape
On 2009-05-19 16:52, Franck GANACHAUD wrote: I didn't specify these. Original diskset is 250Gb to save to DLT4 35GB tapes using a 8 slots autoloader. I'm going to split this diskset going down one level in the filesystem which will give me a little less than 150 diskset. I just have to think about a mechanism to upgrade the diskset list automaticaly. Try to do it like this: http://wiki.zmanda.com/index.php/How_To:Split_DLEs_With_Exclude_Lists And your last problem is solved (and probably your first as well reducing 150 disksets to a little less). -- Paul Bijnens, Xplanation Technology ServicesTel +32 16 397.525 Interleuvenlaan 86, B-3001 Leuven, BELGIUM Fax +32 16 397.552 *** * I think I've got the hang of it now: exit, ^D, ^C, ^\, ^Z, ^Q, ^^, * * quit, ZZ, :q, :q!, M-Z, ^X^C, logoff, logout, close, bye, /bye, ~., * * stop, end, ^]c, +++ ATH, disconnect, halt, abort, hangup, KJOB, * * ^X^X, :D::D, kill -9 1, kill -1 $$, shutdown, init 0, Alt-F4, * * Alt-f-e, Ctrl-Alt-Del, Alt-SysRq-reisub, Stop-A, AltGr-NumLock, ... * * ... Are you sure? ... YES ... Phew ... I'm out * ***
FSF AFTER FILEMARK patch
I have Amanda 2.6.1p1. Darin Perusich mentioned a patch FSF_AFTER_FILEMARK that needs to be added for Solaris hosts. Where or how do I get this patch or a patched source. Thanks Robert _ Robert P. McGraw, Jr. Manager, Computer SystemEMAIL: rmcg...@purdue.edu Purdue UniversityROOM: MATH-807 Department of Mathematics PHONE: (765) 494-6055 150 N. University Street West Lafayette, IN 47907-2067
Re: FSF AFTER FILEMARK patch
On Tue, May 19, 2009 at 12:33 PM, McGraw, Robert P rmcg...@purdue.edu wrote: I have Amanda 2.6.1p1. Darin Perusich mentioned a patch FSF_AFTER_FILEMARK that needs to be added for Solaris hosts. Where or how do I get this patch or a patched source. http://github.com/zmanda/amanda/commit/2cb92fbc5f7f1ad452b9be44670b02d5bd33d194 http://github.com/zmanda/amanda/commit/2cb92fbc5f7f1ad452b9be44670b02d5bd33d194.patch Dustin -- Open Source Storage Engineer http://www.zmanda.com
Re: FSF AFTER FILEMARK patch
On Tuesday 19 May 2009, McGraw, Robert P wrote: FSF_AFTER_FILEMARK According to the ChangeLog for the 2.6.2 snapshot I'm running, that was added on 4-21. Whether its in 2.6.1p1 I do not know. For space reasons I rarely keep more than about 10 of the previous snapshots here. Did you get your src's from zmanda.com? The right hand column is the ChangeLog incremental, and that was also added into the 2.6.1p1 snapshot as of amanda-2.6.1p1-20090421.tar.gz, but there are even newer versions there. See http://www.zmanda.com/community-builds.php for a full list. -- Cheers, Gene There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) Poverty begins at home.
2.6.1 client with 2.4.3 server?
Hi, Is there any gross imcompatability that would prevent a 2.6.1p1 client from being backed up by a 2.4.3b3 server? I've got it to the point where they are at least talking with each other, using auth bsd. amcheck -c is happy. estimates worked ok. But amstatus is showing this: client-a:/a0 driver: [parse of reply message failed] (10:34:30) client-a:/var 0 driver: [parse of reply message failed] (10:41:15) client-a:/var/log 0 31020k wait for dumping driver: (aborted:[request timeout]) hmm... here's something interesting in the sendbackup.debug file: 1242744076.458012: sendbackup: pid 14788 ruid 501 euid 501 version 2.6.1p1: start a t Tue May 19 10:41:16 2009 1242744076.458089: sendbackup: Version 2.6.1p1 1242744076.458650: sendbackup: sendbackup req: GNUTAR /var 0 1970:1:1:0:0:0 OPTI ONS |;bsd-auth;index; 1242744076.458736: sendbackup: Parsed request as: program `GNUTAR' 1242744076.458749: sendbackup: disk `/var' 1242744076.458760: sendbackup: device `/var' 1242744076.458770: sendbackup: level 0 1242744076.458781: sendbackup: since 1970:1:1:0:0:0 1242744076.458791: sendbackup: options `|;bsd-auth;index;' 1242744076.458998: sendbackup: start: client-a:/var lev 0 1242744076.459129: sendbackup: doing level 0 dump as listed-incremental to '/var/li b/amanda/gnutar-lists/client-a_var_0.new' 1242744076.461334: sendbackup: Started index creator: /bin/tar -tf - 2/dev/null | sed -e 's/^\.//' 1242744076.461537: sendbackup: pipespawnv: stdoutfd is 50 1242744076.461947: sendbackup: Spawning /usr/libexec/amanda/runtar runtar NOCONFIG /bin/tar --create --file - --directory /var --one-file-system --listed-incremental /var/lib/amanda/gnutar-lists/client-a_var_0.new --sparse --ignore-failed-read --to tals . in pipeline 1242744076.463151: sendbackup: gnutar: /usr/libexec/amanda/runtar: pid 14792 1242744076.463205: sendbackup: Started backup 1242744166.493587: sendbackup: critical (fatal): index tee cannot write [Broken pip e] /usr/lib64/amanda/libamanda-2.6.1p1.so[0x35834215b2] /lib64/libglib-2.0.so.0(g_logv+0x26f)[0x3af5c34d5f] /lib64/libglib-2.0.so.0(g_log+0x83)[0x3af5c34f33] /usr/libexec/amanda/sendbackup(start_index+0x290)[0x4037f0] /usr/libexec/amanda/sendbackup[0x4075f0] /usr/libexec/amanda/sendbackup(main+0x10a4)[0x405834] /lib64/libc.so.6(__libc_start_main+0xf4)[0x3fe1c1d8b4] /usr/libexec/amanda/sendbackup[0x403139] So it looks like a problem sending the index data. I've set index_server to the correct hostname in /etc/amanda-client.conf. Will this properly override the settings configured at compile time? This client is installed from the redhat rpm, so it has no local compile-time configuration. The /etc/amanda-client.conf looks like this: # # amanda.conf - sample Amanda client configuration file. # # This file normally goes in /etc/amanda/amanda-client.conf. # conf test # your config name index_server amanda-server# your amindexd server tape_server amanda-server# your amidxtaped server tapedev tape:/dev/nst1 # your tape device # if not set, Use configure or ask server. # if set to empty string , ask server # amrecover will use the changer if set to the value # of 'amrecover_changer' in the server amanda.conf. # auth- authentication scheme to use between server and client. # Valid values are bsd, bsdudp, bsdtcp, krb5, local, # rsh and ssh. # Default: [auth bsdtcp] auth bsd ssh_keys # your ssh keys file if you use ssh auth Anyone see anything obvious we're overlooking? (Yeah, besides needing to upgrade the server!) :-) -Mitch
Re: 2.6.1 client with 2.4.3 server?
I try to keep them compatible, but I don't test with release before 2.4.5. index_server is used only by amrecover. Can you post the amandad.*.debug file from the client? Jean-Louis Mitch Collinsworth wrote: Hi, Is there any gross imcompatability that would prevent a 2.6.1p1 client from being backed up by a 2.4.3b3 server? I've got it to the point where they are at least talking with each other, using auth bsd. amcheck -c is happy. estimates worked ok. But amstatus is showing this: client-a:/a0 driver: [parse of reply message failed] (10:34:30) client-a:/var 0 driver: [parse of reply message failed] (10:41:15) client-a:/var/log 0 31020k wait for dumping driver: (aborted:[request timeout]) hmm... here's something interesting in the sendbackup.debug file: 1242744076.458012: sendbackup: pid 14788 ruid 501 euid 501 version 2.6.1p1: start a t Tue May 19 10:41:16 2009 1242744076.458089: sendbackup: Version 2.6.1p1 1242744076.458650: sendbackup: sendbackup req: GNUTAR /var 0 1970:1:1:0:0:0 OPTI ONS |;bsd-auth;index; 1242744076.458736: sendbackup: Parsed request as: program `GNUTAR' 1242744076.458749: sendbackup: disk `/var' 1242744076.458760: sendbackup: device `/var' 1242744076.458770: sendbackup: level 0 1242744076.458781: sendbackup: since 1970:1:1:0:0:0 1242744076.458791: sendbackup: options `|;bsd-auth;index;' 1242744076.458998: sendbackup: start: client-a:/var lev 0 1242744076.459129: sendbackup: doing level 0 dump as listed-incremental to '/var/li b/amanda/gnutar-lists/client-a_var_0.new' 1242744076.461334: sendbackup: Started index creator: /bin/tar -tf - 2/dev/null | sed -e 's/^\.//' 1242744076.461537: sendbackup: pipespawnv: stdoutfd is 50 1242744076.461947: sendbackup: Spawning /usr/libexec/amanda/runtar runtar NOCONFIG /bin/tar --create --file - --directory /var --one-file-system --listed-incremental /var/lib/amanda/gnutar-lists/client-a_var_0.new --sparse --ignore-failed-read --to tals . in pipeline 1242744076.463151: sendbackup: gnutar: /usr/libexec/amanda/runtar: pid 14792 1242744076.463205: sendbackup: Started backup 1242744166.493587: sendbackup: critical (fatal): index tee cannot write [Broken pip e] /usr/lib64/amanda/libamanda-2.6.1p1.so[0x35834215b2] /lib64/libglib-2.0.so.0(g_logv+0x26f)[0x3af5c34d5f] /lib64/libglib-2.0.so.0(g_log+0x83)[0x3af5c34f33] /usr/libexec/amanda/sendbackup(start_index+0x290)[0x4037f0] /usr/libexec/amanda/sendbackup[0x4075f0] /usr/libexec/amanda/sendbackup(main+0x10a4)[0x405834] /lib64/libc.so.6(__libc_start_main+0xf4)[0x3fe1c1d8b4] /usr/libexec/amanda/sendbackup[0x403139] So it looks like a problem sending the index data. I've set index_server to the correct hostname in /etc/amanda-client.conf. Will this properly override the settings configured at compile time? This client is installed from the redhat rpm, so it has no local compile-time configuration. The /etc/amanda-client.conf looks like this: # # amanda.conf - sample Amanda client configuration file. # # This file normally goes in /etc/amanda/amanda-client.conf. # conf test # your config name index_server amanda-server# your amindexd server tape_server amanda-server# your amidxtaped server tapedev tape:/dev/nst1 # your tape device # if not set, Use configure or ask server. # if set to empty string , ask server # amrecover will use the changer if set to the value # of 'amrecover_changer' in the server amanda.conf. # auth- authentication scheme to use between server and client. # Valid values are bsd, bsdudp, bsdtcp, krb5, local, # rsh and ssh. # Default: [auth bsdtcp] auth bsd ssh_keys # your ssh keys file if you use ssh auth Anyone see anything obvious we're overlooking? (Yeah, besides needing to upgrade the server!) :-) -Mitch
Re: Amanda must be run as user amandabackup when using bsdtcp authentication
At 3:01 PM +0200 5/19/09, Abilio Carvalho wrote: owner is amandabackup:disk I can log in to the account just fine, I don't think any more logging is possible though I'll check. I checked the manifest for the service and it confirms that it is SUPPOSED to start as amandabackup. If I do what you say, and log into amandabackup and run that, I get the following on /tmp/amanda/amandad/amandad.TIMESTAMP.debug: 1242737635.958239: amandad: pid 9504 ruid 6028 euid 6028 version 2.6.1: start at Tue May 19 14:53:55 2009 1242737635.989035: amandad: security_getdriver(name=bsdtcp) returns ff31c788 1242737635.992943: amandad: version 2.6.1 1242737635.992955: amandad: build: VERSION=Amanda-2.6.1 1242737635.992961: amandad:BUILT_DATE=Mon May 18 12:33:06 CEST 2009 1242737635.992967: amandad:BUILT_MACH=sparc-sun- solaris2.10 BUILT_REV=1609 1242737635.992973: amandad:BUILT_BRANCH=amanda-261 CC=/ opt/SUNWspro/bin/cc 1242737635.992979: amandad: paths: bindir=/bin sbindir=/sbin libexecdir=/libexec 1242737635.992984: amandad:amlibexecdir=/libexec/amanda mandir=/share/man 1242737635.992990: amandad:AMANDA_TMPDIR=/tmp/amanda AMANDA_DBGDIR=/tmp/amanda 1242737635.992995: amandad:CONFIG_DIR=/etc/amanda DEV_PREFIX=/dev/dsk/ 1242737635.993000: amandad:RDEV_PREFIX=/dev/rdsk/ DUMP=/ usr/sbin/ufsdump 1242737635.993005: amandad:RESTORE=/usr/sbin/ufsrestore VDUMP=UNDEF VRESTORE=UNDEF 1242737635.993011: amandad:XFSDUMP=UNDEF XFSRESTORE=UNDEF VXDUMP=UNDEF VXRESTORE=UNDEF 1242737635.993016: amandad:SAMBA_CLIENT=/usr/sfw/bin/ smbclient 1242737635.993021: amandad:GNUTAR=/usr/sfw/bin/gtar COMPRESS_PATH=/usr/bin/gzip 1242737635.993026: amandad:UNCOMPRESS_PATH=/usr/bin/gzip LPRCMD=/usr/bin/lp 1242737635.993032: amandad: MAILER=UNDEF listed_incr_dir=/ var/amanda/gnutar-lists 1242737635.993037: amandad: defs: DEFAULT_SERVER=galadhrim DEFAULT_CONFIG=DailySet1 1242737635.993042: amandad:DEFAULT_TAPE_SERVER=galadhrim DEFAULT_TAPE_DEVICE= 1242737635.993047: amandad:HAVE_MMAP NEED_STRSTR HAVE_SYSVSHM AMFLOCK_POSIX AMFLOCK_LOCKF 1242737635.993053: amandad:AMFLOCK_LNLOCK SETPGRP_VOID AMANDA_DEBUG_DAYS=4 BSD_SECURITY 1242737635.993058: amandad:USE_AMANDAHOSTS CLIENT_LOGIN=amandabackup CHECK_USERID 1242737635.993063: amandad:HAVE_GZIP COMPRESS_SUFFIX=.gz COMPRESS_FAST_OPT=--fast 1242737635.993069: amandad:COMPRESS_BEST_OPT=--best UNCOMPRESS_OPT=-dc 1242737635.997381: amandad: getpeername returned: Socket operation on non-socket 1242737635.997434: amandad: pid 9504 finish time Tue May 19 14:53:55 2009 so it does seem like as inetd problem and not amanda. I just have no clue as to how that's possible These are my instructs (to myself) for Linux machines -- but they may spark a thought in your situation: the client needs lines like this add these lines to /etc/services amanda 10080/udp # Dump server control amidxtape 10083/tcp # Amanda tape indexing amandaidx 10082/tcp # Amanda recovery program add these lines to /etc/inetd.conf and then kill -HUP inetd process (2 lines --- mine may wrap) amanda dgram udp wait amandabackup /usr/local/libexec/amanda/amandad amandad amidxtape stream tcp nowait amandabackup /usr/local/libexec/amanda/amidxtaped amidxtaped On May 19, 2009, at 2:45 PM, Jean-Louis Martineau wrote: Who is the owner of /tmp/amanda/amandad/amandad.20090519111556.debug Can you use the amandabackup account? Can you log to that account? Can you enabled more logging in inetd? It is an inetd misconfiguration if amandad is run as root. Log as amandabackup and run '/libexec/amanda/amandad -auth=bsdtcp amdump' Jean-Louis Abilio Carvalho wrote: follow-up: I was wrong, it wasn't syslog, it was messages. There I now see a couple lines like: May 19 13:58:23 galadhrim inetd[24015]: [ID 317013 daemon.notice] amanda[27116] from 172.22.0.23 44223 May 19 13:58:31 galadhrim inetd[24015]: [ID 317013 daemon.notice] amanda[27214] from 172.22.0.23 703 May 19 13:59:12 galadhrim inetd[24015]: [ID 317013 daemon.notice] amanda[27619] from 172.22.0.23 703 On May 19, 2009, at 1:37 PM, Jean-Louis Martineau wrote: Abilio Carvalho wrote: the log directory on the client only has the following: r...@backupclient:/tmp/amanda/amandad# cat amandad. 20090519111556.debug 1242724556.328466: amandad: pid 18933 ruid 0 euid 0 version 2.6.1: start at Tue May 19 11:15:56 2009 ruid 0 euid 0 That's root user Do you have an amandabackup user on the client Check inet log Jean-Louis 1242724556.339271: amandad: security_getdriver(name=bsdtcp) returns ff31c788 1242724556.339369: amandad: critical (fatal): Amanda must be run as user 'amandabackup' when using 'bsdtcp' authentication I can't even see what user it's
Re: 2.6.1 client with 2.4.3 server?
On Tue, 19 May 2009, Jean-Louis Martineau wrote:
I try to keep them compatible, but I don't test with release before 2.4.5.
index_server is used only by amrecover.
Can you post the amandad.*.debug file from the client?
Jean-Louis
Yup, here's a sample below.
-Mitch
1242745188.258722: amandad: pid 14871 ruid 501 euid 501 version 2.6.1p1: start
at Tue May 19 10:59:48 2009
1242745188.259342: amandad: security_getdriver(name=bsd) returns 0x358364e920
1242745188.259373: amandad: version 2.6.1p1
1242745188.259383: amandad: build: VERSION=Amanda-2.6.1p1
1242745188.259393: amandad:BUILT_DATE=Fri Apr 10 16:12:07 PDT 2009
1242745188.259402: amandad:BUILT_MACH=x86_64-unknown-linux-gnu
BUILT_REV=1860
1242745188.259410: amandad:BUILT_BRANCH=amanda-261 CC=gcc
1242745188.259419: amandad: paths: bindir=/usr/bin sbindir=/usr/sbin
1242745188.259428: amandad:libexecdir=/usr/libexec
1242745188.259436: amandad:amlibexecdir=/usr/libexec/amanda
mandir=/usr/share/man
1242745188.259445: amandad:AMANDA_TMPDIR=/tmp/amanda
1242745188.259453: amandad:AMANDA_DBGDIR=/var/log/amanda
CONFIG_DIR=/etc/amanda
1242745188.259462: amandad:DEV_PREFIX=/dev/ RDEV_PREFIX=/dev/r
1242745188.259470: amandad:DUMP=/sbin/dump
RESTORE=/sbin/restore VDUMP=UNDEF
1242745188.259479: amandad:VRESTORE=UNDEF XFSDUMP=UNDEF
XFSRESTORE=UNDEF VXDUMP=UNDEF
1242745188.259489: amandad:VXRESTORE=UNDEF
SAMBA_CLIENT=/usr/bin/smbclient
1242745188.259497: amandad:GNUTAR=/bin/tar
COMPRESS_PATH=/usr/bin/gzip
1242745188.259506: amandad:UNCOMPRESS_PATH=/usr/bin/gzip
LPRCMD=/usr/bin/lpr
1242745188.259515: amandad: MAILER=UNDEF
listed_incr_dir=/var/lib/amanda/gnutar-lists
1242745188.259523: amandad: defs: DEFAULT_SERVER=localhost
DEFAULT_CONFIG=DailySet1
1242745188.259532: amandad:DEFAULT_TAPE_SERVER=localhost
DEFAULT_TAPE_DEVICE=
1242745188.259540: amandad:HAVE_MMAP NEED_STRSTR HAVE_SYSVSHM
AMFLOCK_POSIX AMFLOCK_FLOCK
1242745188.259549: amandad:AMFLOCK_LOCKF AMFLOCK_LNLOCK
SETPGRP_VOID ASSERTIONS
1242745188.259557: amandad:AMANDA_DEBUG_DAYS=4 BSD_SECURITY
USE_AMANDAHOSTS
1242745188.259566: amandad:CLIENT_LOGIN=amandabackup CHECK_USERID
HAVE_GZIP
1242745188.259574: amandad:COMPRESS_SUFFIX=.gz
COMPRESS_FAST_OPT=--fast
1242745188.259582: amandad:COMPRESS_BEST_OPT=--best
UNCOMPRESS_OPT=-dc
1242745188.259683: amandad: dgram_recv(dgram=0x3583659788, timeout=0,
fromaddr=0x3583669780)
1242745188.259718: amandad: (sockaddr_in *)0x3583669780 = { 2, 769, 11.22.33.44
}
1242745188.259753: amandad: security_handleinit(handle=0xbcf5a30,
driver=0x358364e920 (BSD))
1242745188.262340: amandad: accept recv REQ pkt:
SERVICE sendbackup
OPTIONS hostname=client-a;
GNUTAR / 0 1970:1:1:0:0:0 OPTIONS |;bsd-auth;index;
1242745188.262390: amandad: creating new service: sendbackup
OPTIONS hostname=client-a;
GNUTAR / 0 1970:1:1:0:0:0 OPTIONS |;bsd-auth;index;
1242745188.264233: amandad: sending ACK pkt:
1242745188.264340: amandad: dgram_send_addr(addr=0xbcf5a70, dgram=0x3583659788)
1242745188.264360: amandad: (sockaddr_in *)0xbcf5a70 = { 2, 769, 11.22.33.44 }
1242745188.264374: amandad: dgram_send_addr: 0x3583659788-socket = 0
1242745188.270256: amandad: security_streaminit(stream=0xbd06c60,
driver=0x358364e920 (BSD))
1242745188.270320: amandad: stream_server opening socket with family 2
(requested family was 2)
1242745188.270362: amandad: try_socksize: send buffer size is 65536
1242745188.270378: amandad: try_socksize: receive buffer size is 65536
1242745188.277672: amandad: bind_portrange2: Try port 11039: Available -
Success
1242745188.277744: amandad: stream_server: waiting for connection: 0.0.0.0.11039
1242745188.277769: amandad: security_streaminit(stream=0xbd0f140,
driver=0x358364e920 (BSD))
1242745188.277789: amandad: stream_server opening socket with family 2
(requested family was 2)
1242745188.277817: amandad: try_socksize: send buffer size is 65536
1242745188.277831: amandad: try_socksize: receive buffer size is 65536
1242745188.285066: amandad: bind_portrange2: Try port 11039: Available -
Address already in use
1242745188.292295: amandad: bind_portrange2: Try port 11040: Available -
Success
1242745188.292368: amandad: stream_server: waiting for connection: 0.0.0.0.11040
1242745188.292392: amandad: security_streaminit(stream=0xbd171c0,
driver=0x358364e920 (BSD))
1242745188.292412: amandad: stream_server opening socket with family 2
(requested family was 2)
1242745188.292438: amandad: try_socksize: send buffer size is 65536
1242745188.292452: amandad: try_socksize: receive buffer size is 65536
1242745188.299718: amandad: bind_portrange2: Try port 11039: Available -
Address already in use
1242745188.302654: amandad: bind_portrange2: Try port 11040: Available -
Address already in
Re: Amanda must be run as user amandabackup when using bsdtcp authentication
Thanks those were all things I'd tried already. I've managed to fix it though. For some reason, completely purging the service from everywhere and recreating it from the exact same manifest did the trick, where before that I'd tried changing the user parameter on the service without destroying it, without success. Thanks everyone for the help Abilio On May 19, 2009, at 9:28 PM, Deb Baddorf wrote: At 3:01 PM +0200 5/19/09, Abilio Carvalho wrote: owner is amandabackup:disk I can log in to the account just fine, I don't think any more logging is possible though I'll check. I checked the manifest for the service and it confirms that it is SUPPOSED to start as amandabackup. If I do what you say, and log into amandabackup and run that, I get the following on /tmp/amanda/amandad/amandad.TIMESTAMP.debug: 1242737635.958239: amandad: pid 9504 ruid 6028 euid 6028 version 2.6.1: start at Tue May 19 14:53:55 2009 1242737635.989035: amandad: security_getdriver(name=bsdtcp) returns ff31c788 1242737635.992943: amandad: version 2.6.1 1242737635.992955: amandad: build: VERSION=Amanda-2.6.1 1242737635.992961: amandad:BUILT_DATE=Mon May 18 12:33:06 CEST 2009 1242737635.992967: amandad:BUILT_MACH=sparc-sun- solaris2.10 BUILT_REV=1609 1242737635.992973: amandad:BUILT_BRANCH=amanda-261 CC=/ opt/SUNWspro/bin/cc 1242737635.992979: amandad: paths: bindir=/bin sbindir=/ sbin libexecdir=/libexec 1242737635.992984: amandad:amlibexecdir=/libexec/ amanda mandir=/share/man 1242737635.992990: amandad:AMANDA_TMPDIR=/tmp/amanda AMANDA_DBGDIR=/tmp/amanda 1242737635.992995: amandad:CONFIG_DIR=/etc/amanda DEV_PREFIX=/dev/dsk/ 1242737635.993000: amandad:RDEV_PREFIX=/dev/rdsk/ DUMP=/ usr/sbin/ufsdump 1242737635.993005: amandad:RESTORE=/usr/sbin/ ufsrestore VDUMP=UNDEF VRESTORE=UNDEF 1242737635.993011: amandad:XFSDUMP=UNDEF XFSRESTORE=UNDEF VXDUMP=UNDEF VXRESTORE=UNDEF 1242737635.993016: amandad:SAMBA_CLIENT=/usr/sfw/bin/ smbclient 1242737635.993021: amandad:GNUTAR=/usr/sfw/bin/gtar COMPRESS_PATH=/usr/bin/gzip 1242737635.993026: amandad:UNCOMPRESS_PATH=/usr/bin/ gzip LPRCMD=/usr/bin/lp 1242737635.993032: amandad: MAILER=UNDEF listed_incr_dir=/ var/amanda/gnutar-lists 1242737635.993037: amandad: defs: DEFAULT_SERVER=galadhrim DEFAULT_CONFIG=DailySet1 1242737635.993042: amandad: DEFAULT_TAPE_SERVER=galadhrim DEFAULT_TAPE_DEVICE= 1242737635.993047: amandad:HAVE_MMAP NEED_STRSTR HAVE_SYSVSHM AMFLOCK_POSIX AMFLOCK_LOCKF 1242737635.993053: amandad:AMFLOCK_LNLOCK SETPGRP_VOID AMANDA_DEBUG_DAYS=4 BSD_SECURITY 1242737635.993058: amandad:USE_AMANDAHOSTS CLIENT_LOGIN=amandabackup CHECK_USERID 1242737635.993063: amandad:HAVE_GZIP COMPRESS_SUFFIX=.gz COMPRESS_FAST_OPT=--fast 1242737635.993069: amandad:COMPRESS_BEST_OPT=--best UNCOMPRESS_OPT=-dc 1242737635.997381: amandad: getpeername returned: Socket operation on non-socket 1242737635.997434: amandad: pid 9504 finish time Tue May 19 14:53:55 2009 so it does seem like as inetd problem and not amanda. I just have no clue as to how that's possible These are my instructs (to myself) for Linux machines -- but they may spark a thought in your situation: the client needs lines like this add these lines to /etc/services amanda 10080/udp # Dump server control amidxtape 10083/tcp # Amanda tape indexing amandaidx 10082/tcp # Amanda recovery program add these lines to /etc/inetd.conf and then kill -HUP inetd process (2 lines --- mine may wrap) amanda dgram udp wait amandabackup /usr/local/libexec/amanda/ amandad amandad amidxtape stream tcp nowait amandabackup /usr/local/libexec/amanda/ amidxtaped amidxtaped On May 19, 2009, at 2:45 PM, Jean-Louis Martineau wrote: Who is the owner of /tmp/amanda/amandad/amandad.20090519111556.debug Can you use the amandabackup account? Can you log to that account? Can you enabled more logging in inetd? It is an inetd misconfiguration if amandad is run as root. Log as amandabackup and run '/libexec/amanda/amandad -auth=bsdtcp amdump' Jean-Louis Abilio Carvalho wrote: follow-up: I was wrong, it wasn't syslog, it was messages. There I now see a couple lines like: May 19 13:58:23 galadhrim inetd[24015]: [ID 317013 daemon.notice] amanda[27116] from 172.22.0.23 44223 May 19 13:58:31 galadhrim inetd[24015]: [ID 317013 daemon.notice] amanda[27214] from 172.22.0.23 703 May 19 13:59:12 galadhrim inetd[24015]: [ID 317013 daemon.notice] amanda[27619] from 172.22.0.23 703 On May 19, 2009, at 1:37 PM, Jean-Louis Martineau wrote: Abilio Carvalho wrote: the log directory on the client only has the following:
Re: 2.6.1 client with 2.4.3 server?
amanda client 2.6.1p1 is compatible with server 2.4.3b4 and up. But it
is not with 2.4.3b3 and previous.
Try the attached patch.
Jean-Louis
Mitch Collinsworth wrote:
Hi,
Is there any gross imcompatability that would prevent a 2.6.1p1 client
from being backed up by a 2.4.3b3 server?
I've got it to the point where they are at least talking with each
other, using auth bsd.
amcheck -c is happy.
estimates worked ok.
But amstatus is showing this:
client-a:/a0 driver: [parse of reply message failed] (10:34:30)
client-a:/var 0 driver: [parse of reply message failed] (10:41:15)
client-a:/var/log 0 31020k wait for dumping driver:
(aborted:[request timeout])
hmm... here's something interesting in the sendbackup.debug file:
1242744076.458012: sendbackup: pid 14788 ruid 501 euid 501 version
2.6.1p1: start a
t Tue May 19 10:41:16 2009
1242744076.458089: sendbackup: Version 2.6.1p1
1242744076.458650: sendbackup: sendbackup req: GNUTAR /var 0
1970:1:1:0:0:0 OPTI
ONS |;bsd-auth;index;
1242744076.458736: sendbackup: Parsed request as: program `GNUTAR'
1242744076.458749: sendbackup: disk `/var'
1242744076.458760: sendbackup: device `/var'
1242744076.458770: sendbackup: level 0
1242744076.458781: sendbackup: since
1970:1:1:0:0:0
1242744076.458791: sendbackup: options
`|;bsd-auth;index;'
1242744076.458998: sendbackup: start: client-a:/var lev 0
1242744076.459129: sendbackup: doing level 0 dump as
listed-incremental to '/var/li
b/amanda/gnutar-lists/client-a_var_0.new'
1242744076.461334: sendbackup: Started index creator: /bin/tar -tf
- 2/dev/null |
sed -e 's/^\.//'
1242744076.461537: sendbackup: pipespawnv: stdoutfd is 50
1242744076.461947: sendbackup: Spawning /usr/libexec/amanda/runtar
runtar NOCONFIG
/bin/tar --create --file - --directory /var --one-file-system
--listed-incremental
/var/lib/amanda/gnutar-lists/client-a_var_0.new --sparse
--ignore-failed-read --to
tals . in pipeline
1242744076.463151: sendbackup: gnutar: /usr/libexec/amanda/runtar:
pid 14792
1242744076.463205: sendbackup: Started backup
1242744166.493587: sendbackup: critical (fatal): index tee cannot
write [Broken pip
e]
/usr/lib64/amanda/libamanda-2.6.1p1.so[0x35834215b2]
/lib64/libglib-2.0.so.0(g_logv+0x26f)[0x3af5c34d5f]
/lib64/libglib-2.0.so.0(g_log+0x83)[0x3af5c34f33]
/usr/libexec/amanda/sendbackup(start_index+0x290)[0x4037f0]
/usr/libexec/amanda/sendbackup[0x4075f0]
/usr/libexec/amanda/sendbackup(main+0x10a4)[0x405834]
/lib64/libc.so.6(__libc_start_main+0xf4)[0x3fe1c1d8b4]
/usr/libexec/amanda/sendbackup[0x403139]
So it looks like a problem sending the index data. I've set index_server
to the correct hostname in /etc/amanda-client.conf. Will this properly
override the settings configured at compile time? This client is
installed
from the redhat rpm, so it has no local compile-time configuration.
The /etc/amanda-client.conf looks like this:
#
# amanda.conf - sample Amanda client configuration file.
#
# This file normally goes in /etc/amanda/amanda-client.conf.
#
conf test # your config name
index_server amanda-server# your amindexd server
tape_server amanda-server# your amidxtaped server
tapedev tape:/dev/nst1 # your tape device
# if not set, Use configure or ask server.
# if set to empty string , ask server
# amrecover will use the changer if set to the
value
# of 'amrecover_changer' in the server
amanda.conf.
# auth- authentication scheme to use between server and
client.
# Valid values are bsd, bsdudp, bsdtcp,
krb5, local,
# rsh and ssh.
# Default: [auth bsdtcp]
auth bsd
ssh_keys # your ssh keys file if you use ssh
auth
Anyone see anything obvious we're overlooking? (Yeah, besides needing to
upgrade the server!) :-)
-Mitch
Index: client-src/sendbackup.c
===
--- client-src/sendbackup.c (revision 17487)
+++ client-src/sendbackup.c (working copy)
@@ -436,6 +436,10 @@
if(am_has_feature(g_options-features, fe_rep_options_hostname)) {
g_printf(hostname=%s;, g_options-hostname);
}
+if (!am_has_feature(g_options-features, fe_rep_options_features)
+ !am_has_feature(g_options-features, fe_rep_options_hostname)) {
+ g_printf(;);
+}
g_printf(\n);
fflush(stdout);
if (freopen(/dev/null, w, stdout) == NULL) {
Re: Amanda must be run as user amandabackup when using bsdtcp authentication
On Tuesday 19 May 2009, Abilio Carvalho wrote: the prefix with no argument is how the config.log interprets prefix='', which I did to install amanda in the default directories rather than inside a specific subdir. Again, like frank's attempt I have another machine with the same config options and that one works fine. I'll take your word for that. Thanks for the reply to clarify. I would assume that would equal default /usr/local if the option wasn't even used. Since I build from tarballs here, running the lastest snapshot, I always spec the dir by using the same build script that I've used for years. #!/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 echo user amanda, 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-gnu-ld \ --prefix=/usr/local \ --with-debugging=/tmp/amanda-dbg/ \ --with-tape-server=coyote \ --with-bsdtcp-security --with-amandahosts \ --with-configdir=/usr/local/etc/amanda \ --with-config=Daily \ --with-gnutar=/bin/tar echo sleeping 5 seconds for reading configures warnings echo a make as amanda will continue after... sleep 5 make - I recently wrapped that up in a new script that does it all with one invocation, but the ./configure subscript stanza abover hasn't changed since Feb 10th, when a drive failed and I had to reinstall F10 and recover. I guess amrecover didn't preserve the date. :( However that script above hasn't been edited for years. I believe the last time was when I switched to bsdauth. -- Cheers, Gene There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) You know, Callahan's is a peaceable bar, but if you ask that dog what his favorite formatter is, and he says roff! roff!, well, I'll just have to...
