port not secure problem
Our tape server is on a private network behind a firewall and one of our client systems is outside the firewall on a public IP address. Both server and client have a fresh install of 2.4.2p2 configured with: --with-portrange=2064,2066 --with-udpportrange=850,851 The firewall, which is on an OpenBSD box, allows and keeps state on all outbound traffic. It allows inbound udp traffic from the client on ports 850-851 and redirects these packets to the tape server using the same port numbers. When I run amcheck an error message states that there is a problem with the client because 'port 10020 (e.g.) is not secure.' I've read the FAQ section describing how amanda uses ports during a backup session, and I've also read several messages in the mail archives that relate to the error message I'm seeing, but I haven't been able to determine how to get rid of this error. To configure the client and server I relied in part upon this portion of a message by John Jackson on June 29 of this year: ** At the moment, you must set --with-portrange (the TCP ports) to values greater than or equal to 1024. You must set --with-udpportrange (the UDP ports) to values less than 1024. In addition, you'll need to set up your firewall/NAT to let both ranges of ports through as is. However, there is a bug in 2.4.2p2 that will cause amrecover to fail in the above setup. I'm working on a fix for that. ** Has the bug been squashed? And what else might I try in order to get rid of the port not secure error on this client when I run amcheck? Thanks. -Ben Bullock
Re: amdump won't terminate, dumps only to holding disk
On Tuesday 17 April 2001 12:19, you wrote: But I can write tar archives to the tape drive as well as dd and dump to it too. But you can't do that as fast as Amanda with intermittent file mark ioctl's mixed in. The dd test is just a first estimate at what Amanda does. If taper is stuck and you can't kill it, that's a kernel driver issue. Amanda does absolutely **nothing** unusual in terms of system calls. It's a pure user level application doing simple read's and write's with a few well defined ioctl's (write file mark) sprinkled in. Your kernel driver has hung for some reason and while Amanda may have triggered that problem, it is not the cause, and the fix will have to be in the driver, not Amanda. Yes indeed. After posting to an OpenBSD list, I was directed to this URL: http://www.monkey.org/openbsd/archive/ports/0102/msg00194.html This solved my problem and I'm now able to do backups using my OpenBSD system. Thanks to everyone who responded for their assistance. -Ben Bullock
Re: amdump won't terminate, dumps only to holding disk
On Monday 16 April 2001 23:55, you wrote: ... obsd.athome:wd1a 0 28128k writing to tape obsd.athome:wd1d 0 92416k dump done, wait for writing to tape If it says it's writing to tape, and the tape leds aren't flashing, I suppose the driver that runs the tape drive is broken. Unless it's some cable problem, lack of termination, etc. But I can write tar archives to the tape drive as well as dd and dump to it too. -Ben Bullock
Re: amdump won't terminate, dumps only to holding disk
On Monday 16 April 2001 13:58, John R. Jackson wrote: ... ... That implies taper is hung trying to deal with the tape device, which in turn would indicate to me a hardware or kernel driver problem, especially if you cannot kill it. What do you see if you "grep '^taper:' amdump.1"? Was taper able to read the label and verify it was what it wanted and then write a new label? Yes on both counts. Do you see any FILE-WRITE commands from driver to taper? Yes, but for only one of the two partitions I'm trying to back up. Any DONE reports from taper back to driver? No. What kind of tape drive are you using? Tandberg TDC 4100 w/Adaptec 2940 SCSI adapter. Tapes are 3M-6525, for which I created a tape definition using tapetype. What happens if you force the issue and manually unload the drive? Does that wake anything up? No. You might try doing a bunch of dd's to the drive with a 32 KByte block size and varying file sizes to see what happens. Make sure you use the no-rewind device name (and a scratch tape :-). No problems encountered while doing this. Files sizes varied from a few hundred bytes to about 100MB. ... ... More interesting would be to run "where" and see the stack traceback. I've attached gdb output for all processes except the one taper process that I can't kill; gdb hangs on that one. -Ben Bullock obsd:~# gdb dumper 15329 GNU gdb 4.16.1 This GDB was configured as "i386-unknown-openbsd2.7"... Attaching to process 15329 0x400e6193 in ?? () (gdb) bt #0 0x400e6193 in ?? () #1 0x400d3de2 in ?? () #2 0x400ad28a in ?? () #3 0xac00 in ?? () #4 0x2702 in ?? () #5 0x1d41 in ?? () #6 0x109c in ?? () (gdb) quit The program is running. Quit anyway (and detach it)? (y or n) y Detaching from program: process 15329 obsd:~# gdb dumper 15329 river 10789 GNU gdb 4.16.1 This GDB was configured as "i386-unknown-openbsd2.7"... Attaching to process 10789 0x400d08c3 in ?? () (gdb) bt #0 0x400d08c3 in ?? () #1 0x109c in ?? () (gdb) quit The program is running. Quit anyway (and detach it)? (y or n) y Detaching from program: process 10789 obsd:~# gdb driver 10789 taper 26137 GNU gdb 4.16.1 This GDB was configured as "i386-unknown-openbsd2.7"... Attaching to process 26137 0x400eb193 in ?? () (gdb) bt #0 0x400eb193 in ?? () #1 0x2b09 in ?? () #2 0x2329 in ?? () #3 0x1b1b in ?? () #4 0x109c in ?? () (gdb) quit The program is running. Quit anyway (and detach it)? (y or n) y Detaching from program: process 26137 obsd:~# gdb taper 26137 dumper 6473 GNU gdb 4.16.1 This GDB was configured as "i386-unknown-openbsd2.7"... Attaching to process 6473 0x400e6193 in ?? () (gdb) bt #0 0x400e6193 in ?? () #1 0x400d3de2 in ?? () #2 0x400ad28a in ?? () #3 0xac00 in ?? () #4 0x2702 in ?? () #5 0x1d41 in ?? () #6 0x109c in ?? () (gdb) q The program is running. Quit anyway (and detach it)? (y or n) y Detaching from program: process 6473 obsd:~# gdb dumper 6473 31972 GNU gdb 4.16.1 Copyright 1996 Free Software Foundation, Inc. This GDB was configured as "i386-unknown-openbsd2.7"... Attaching to process 31972 0x400e6193 in ?? () (gdb) bt #0 0x400e6193 in ?? () #1 0x400d3de2 in ?? () #2 0x400ad28a in ?? () #3 0xac00 in ?? () #4 0x2702 in ?? () #5 0x1d41 in ?? () #6 0x109c in ?? () (gdb) q The program is running. Quit anyway (and detach it)? (y or n) y Detaching from program: process 31972 obsd:~# gdb dumper 31972 1074 GNU gdb 4.16.1 This GDB was configured as "i386-unknown-openbsd2.7"... Attaching to process 1074 0x400e6193 in ?? () (gdb) bt #0 0x400e6193 in ?? () #1 0x400d3de2 in ?? () #2 0x400ad28a in ?? () #3 0xac00 in ?? () #4 0x2702 in ?? () #5 0x1d41 in ?? () #6 0x109c in ?? () (gdb) q The program is running. Quit anyway (and detach it)? (y or n) y Detaching from program: process 1074
Re: amdump won't terminate, dumps only to holding disk
On Monday 16 April 2001 15:58, you wrote: On Apr 16, 2001, Ben Bullock [EMAIL PROTECTED] wrote: Any ideas what is going on amstatus? obsd# su operator -c '/usr/local/sbin/amstatus DailySet1' Using /usr/adm/amanda/DailySet1/amdump obsd.athome:wd1a 0 28128k writing to tape obsd.athome:wd1d 0 92416k dump done, wait for writing to tape SUMMARY part real estimated size size partition : 2 estimated : 2 120333k failed : 0 0k wait for dumping: 0 0k dumping to tape : 0 0k dumping : 00k0k dumped : 2 120544k 120333k wait for writing: 192416k92216k writing to tape : 128128k28117k failed to tape : 00k0k taped : 00k0k 4 dumpers idle : not-idle taper writing, tapeq: 0 network free kps: 2000 holding space : 288992
amdump won't terminate, dumps only to holding disk
I'm just beginning to use amanda on my home network as a learning excercise and have encountered a problem that I can't solve. I'm attempting to back up a couple of partitions (neither of which is on the same drive where the holding disk is located) on my OpenBSD-2.7 box, which right now is both amanda server and client. amanda version is 2.4.1p1 installed from the ports collection. First, I run: # su operator -c '/usr/local/sbin/amcheck DailySet1' and no errors are reported. Next, I run: # su operator -c '/usr/local/sbin/amdump DailySet1' and amanda writes data to the holding disk, creates a tapelist file, an amdump logfile, indexes, etc. But there is virtually no tape drive activity other than a few seconds of 'shoe-shining' at the very start, which leads me to believe that nothing is being written to the tape. 'top' shows 1 driver, 4 dumper and 2 taper processes, all idle. After several hours nothing has changed. I can manually kill all of these processes except one taper process. When I attach to any of these processes with gdb and do 'info program' I see that it has stopped with signal SIGSTOP. After running: # su operator -c '/usr/local/sbin/amcleanup' I see a logfile, amdump.1. But # 'mt -f /dev/nrst0 status' reports that the tape device is busy. Any ideas what is going on and how I might get amdump to do the right thing? Thanks, -Ben Bullock
