Re: Amrecover connection refused - again!
On Mon, Jun 03, 2002 at 04:16:11PM -0500, Rebecca Pakish wrote: > You're right, that worked. > > Joshua, I should have tried that sooner when you suggested it. But I'm > racking my notes trying to remember why I changed that to yes in the first > place. I know I just used this configuration to recover a file a couple of > months ago and the wait=yes was in place then!! Lee Fellows earlier wrote: > I know of no server using tcp that the superserver waits upon for > connection completion. I'm going to tuck this one away in some hidden recess of my brain. Hopefully recoverable :) Does anyone know of any exceptions? -- Jon H. LaBadie [EMAIL PROTECTED] JG Computing 4455 Province Line Road(609) 252-0159 Princeton, NJ 08540-4322 (609) 683-7220 (fax)
RE: Amrecover connection refused - again!
You're right, that worked. Joshua, I should have tried that sooner when you suggested it. But I'm racking my notes trying to remember why I changed that to yes in the first place. I know I just used this configuration to recover a file a couple of months ago and the wait=yes was in place then!! Thanks, all for helping. Sorry I wasted everyone's time with such an easy fix. rap
RE: Amrecover connection refused - again!
When you change the configuration to nowait ( wait = no ) for amandaidx, you should see this problem end. On Mon, 2002-06-03 at 15:59, Rebecca Pakish wrote: > Summation: > amandaidx is looping and looping and looping until xinetd can't take it any > more and kills it. > > After a fresh restart of xinetd, nmap reveals: > [root@slaw amanda]# nmap slaw.unterlaw.com > > Starting nmap V. 2.54BETA22 ( www.insecure.org/nmap/ ) > Interesting ports on slaw.unterlaw.com (10.1.7.23): > (The 1537 ports scanned but not shown below are in state: closed) > Port State Service > 22/tcp openssh > 111/tcpopensunrpc > 224/tcpopenunknown > 10082/tcp openamandaidx > 10083/tcp openamidxtape > > Look at that happy little amandaidx service just waiting to be used!!! :-) > > But if I try to use it (i.e. amrecover uadaily), /var/log/messages says: > Jun 3 14:42:28 slaw xinetd[1802]: warning: can't get client address: > Transport endpoint is not connected > Jun 3 14:42:28 slaw xinetd[1803]: warning: can't get client address: > Transport endpoint is not connected > Jun 3 14:42:28 slaw xinetd[1804]: warning: can't get client address: > Transport endpoint is not connected > Jun 3 14:42:28 slaw xinetd[1805]: warning: can't get client address: > Transport endpoint is not connected > Jun 3 14:42:28 slaw xinetd[1806]: warning: can't get client address: > Transport endpoint is not connected > Jun 3 14:42:28 slaw xinetd[1807]: warning: can't get client address: > Transport endpoint is not connected > Jun 3 14:42:28 slaw xinetd[1808]: warning: can't get client address: > Transport endpoint is not connected > Jun 3 14:42:28 slaw xinetd[1809]: warning: can't get client address: > Transport endpoint is not connected > Jun 3 14:42:28 slaw xinetd[1810]: warning: can't get client address: > Transport endpoint is not connected > Jun 3 14:42:28 slaw xinetd[1811]: warning: can't get client address: > Transport endpoint is not connected > Jun 3 14:42:28 slaw xinetd[1792]: amandaidx service was deactivated because > of looping > > And I have 8 little amindexd*debug files for each of these little looping > processes that say: > amindexd: debug 1 pid 1861 ruid 502 euid 502 start time Mon Jun 3 14:44:35 > 2002 > amindexd: version 2.4.2p2 > > Ew > >
RE: Amrecover connection refused - again!
Try changing this and restarting xinetd. See if the problem continues.
- service amandaidx
- {
- protocol= tcp
- socket_type = stream
- wait= yes
- user= amanda
- group = disk
- groups = yes
- server = /usr/local/libexec/amindexd
- }
to
- service amandaidx
- {
- protocol= tcp
- socket_type = stream
- wait= no
- user= amanda
- group = disk
- groups = yes
- server = /usr/local/libexec/amindexd
- }
I know of no server using tcp that the superserver waits upon for
connection completion.
On Mon, 2002-06-03 at 15:49, Rebecca Pakish wrote:
> >Try this. Do '/etc/init.d/xinetd restart'. Then, look in
> >/var/log/messages for the messages from xinetd, ending with a line like
> >this:
>
> [root@slaw amanda]# service xinetd restart
> Stopping xinetd: [ OK ]
> Starting xinetd: [ OK ]
> [root@slaw amanda]# tail -n 5 /var/log/messages
> Jun 3 14:38:57 slaw xinetd[1792]: time disabled, removing
> Jun 3 14:38:57 slaw xinetd[1792]: ftp disabled, removing
> Jun 3 14:38:58 slaw xinetd[1792]: xinetd Version 2.3.3 started with libwrap
> options compiled in.
> Jun 3 14:38:58 slaw xinetd[1792]: Started working: 4 available services
> Jun 3 14:39:00 slaw xinetd: xinetd startup succeeded
>
> >Look for any error messages, and check to see if that number matches the
> >number of xinetd based services listed as "on" by 'chkconfig --list'.
>
> No error messages, I count 4 xinetd services "on" and 4 available services
> in /var/log/messages (above)
>
> >That's not so interesting. What we're looking for is amindexd*debug.
> >That file just tells us that amrecover fails, which we knew already. :)
>
> Of course it's not interesting...I opened the wrong &*#@($! file!! :-) But
> this isn't getting to me, really...ugh
> amindexd*debug looks more like this:
>
> amindexd: debug 1 pid 1601 ruid 502 euid 502 start time Mon Jun 3 13:54:37
> 2002
> amindexd: version 2.4.2p2
> getpeername: Socket operation on non-socket
> amindexd: pid 1601 finish time Mon Jun 3 13:54:37 2002
>
> Is that interesting?
>
> >That looks like a service that is looping and getting shut off for a
> >while. Hmmm
>
> After I restart xinetd and try to amrecover, I first get:
> [root@slaw amanda]# amrecover uadaily
> AMRECOVER Version 2.4.2p2. Contacting server on slaw.unterlaw.com ...
> amrecover: Error reading line from server: Connection reset by peer
>
> /var/log/messages says this:
> un 3 14:42:28 slaw xinetd[1802]: warning: can't get client address:
> Transport endpoint is not connected
> Jun 3 14:42:28 slaw xinetd[1803]: warning: can't get client address:
> Transport endpoint is not connected
> Jun 3 14:42:28 slaw xinetd[1804]: warning: can't get client address:
> Transport endpoint is not connected
> Jun 3 14:42:28 slaw xinetd[1805]: warning: can't get client address:
> Transport endpoint is not connected
> Jun 3 14:42:28 slaw xinetd[1806]: warning: can't get client address:
> Transport endpoint is not connected
> Jun 3 14:42:28 slaw xinetd[1807]: warning: can't get client address:
> Transport endpoint is not connected
> Jun 3 14:42:28 slaw xinetd[1808]: warning: can't get client address:
> Transport endpoint is not connected
> Jun 3 14:42:28 slaw xinetd[1809]: warning: can't get client address:
> Transport endpoint is not connected
> Jun 3 14:42:28 slaw xinetd[1810]: warning: can't get client address:
> Transport endpoint is not connected
> Jun 3 14:42:28 slaw xinetd[1811]: warning: can't get client address:
> Transport endpoint is not connected
> Jun 3 14:42:28 slaw xinetd[1792]: amandaidx service was deactivated because
> of looping
>
> So your looping theory is correct, sir.
>
> But why am I looping? (I'm getting to be like a 5 year old. The more
> questions you answer, the more questions I have?!)
>
>
>
> --
> Joshua Baker-LePain
> Department of Biomedical Engineering
> Duke University
>
RE: Amrecover connection refused - again!
Summation: amandaidx is looping and looping and looping until xinetd can't take it any more and kills it. After a fresh restart of xinetd, nmap reveals: [root@slaw amanda]# nmap slaw.unterlaw.com Starting nmap V. 2.54BETA22 ( www.insecure.org/nmap/ ) Interesting ports on slaw.unterlaw.com (10.1.7.23): (The 1537 ports scanned but not shown below are in state: closed) Port State Service 22/tcp openssh 111/tcpopensunrpc 224/tcpopenunknown 10082/tcp openamandaidx 10083/tcp openamidxtape Look at that happy little amandaidx service just waiting to be used!!! :-) But if I try to use it (i.e. amrecover uadaily), /var/log/messages says: Jun 3 14:42:28 slaw xinetd[1802]: warning: can't get client address: Transport endpoint is not connected Jun 3 14:42:28 slaw xinetd[1803]: warning: can't get client address: Transport endpoint is not connected Jun 3 14:42:28 slaw xinetd[1804]: warning: can't get client address: Transport endpoint is not connected Jun 3 14:42:28 slaw xinetd[1805]: warning: can't get client address: Transport endpoint is not connected Jun 3 14:42:28 slaw xinetd[1806]: warning: can't get client address: Transport endpoint is not connected Jun 3 14:42:28 slaw xinetd[1807]: warning: can't get client address: Transport endpoint is not connected Jun 3 14:42:28 slaw xinetd[1808]: warning: can't get client address: Transport endpoint is not connected Jun 3 14:42:28 slaw xinetd[1809]: warning: can't get client address: Transport endpoint is not connected Jun 3 14:42:28 slaw xinetd[1810]: warning: can't get client address: Transport endpoint is not connected Jun 3 14:42:28 slaw xinetd[1811]: warning: can't get client address: Transport endpoint is not connected Jun 3 14:42:28 slaw xinetd[1792]: amandaidx service was deactivated because of looping And I have 8 little amindexd*debug files for each of these little looping processes that say: amindexd: debug 1 pid 1861 ruid 502 euid 502 start time Mon Jun 3 14:44:35 2002 amindexd: version 2.4.2p2 Ew
RE: Amrecover connection refused - again!
On Mon, 3 Jun 2002, Rebecca Pakish wrote: - >Do you have nmap ? Try: - > - ># nmap -sT -p 10082 chena - - [root@slaw etc]# nmap -sT -p 10082 slaw.unterlaw.com - - Starting nmap V. 2.54BETA22 ( www.insecure.org/nmap/ ) - The 1 scanned port on slaw.unterlaw.com (10.1.7.23) is: closed - - Nmap run completed -- 1 IP address (1 host up) scanned in 1 second - - That doesn't look happy...further investigation revealed: - - [root@slaw etc]# nmap -v slaw.unterlaw.com - - Starting nmap V. 2.54BETA22 ( www.insecure.org/nmap/ ) - No tcp,udp, or ICMP scantype specified, assuming vanilla tcp connect() scan. - Use -sP if you really don't want to portscan (and just want to see what - hosts are up). - Host slaw.unterlaw.com (10.1.7.23) appears to be up ... good. - Initiating Connect() Scan against slaw.unterlaw.com (10.1.7.23) - Adding TCP port 22 (state open). - Adding TCP port 224 (state open). - Adding TCP port 10083 (state open). - Adding TCP port 111 (state open). - The Connect() Scan took 1 second to scan 1542 ports. - Interesting ports on slaw.unterlaw.com (10.1.7.23): - (The 1538 ports scanned but not shown below are in state: closed) - Port State Service - 22/tcp openssh - 111/tcpopensunrpc - 224/tcpopenunknown - 10083/tcp openamidxtape - - - Where the heck is 10082/tcp amandaidx??? It looks like the 10082 port is really closed and xinetd is not even listening. (IIRC, if ipchains or iptables were blocking it you would get a state filtered but I am not an nmap expert) On the server, try as root: # netstat -atp | grep amandaidx If xinetd is listening you should see something like: tcp0 0 *:amandaidx *:* LISTEN 804/xinetd This assumes that amandaidx is in /etc/services. To be sure you can try it with the -n option: # sudo netstat -natp | grep 10082 tcp0 0 0.0.0.0:100820.0.0.0:* LISTEN 804/xinetd - >Try telneting to the port again. Then go to /tmp/amanda and locate - >the amindexd..debug file. Look in there for a hint. - >There are probably lots of these files so be sure to get the right - >one. (OR just delete all of them before telnetting :-) - - amrecover.bunchanumbers.debug: - amrecover: debug 1 pid 1602 ruid 0 euid 0 start time Mon Jun 3 13:56:07 - 2002 - amrecover: stream_client: connect(10082) failed: Connection refused - cannot connect to slaw.unterlaw.com: Connection refused - amrecover: pid 1602 finish time Mon Jun 3 13:56:07 2002 - ~ On the server side check for the amindexd..debug file. It will not be there if amindexd is not starting. -- -- Stephen Carville UNIX and Network Administrator DPSI (formerly Ace USA Flood Services) 310-342-3602 [EMAIL PROTECTED]
RE: Amrecover connection refused - again!
>Try this. Do '/etc/init.d/xinetd restart'. Then, look in >/var/log/messages for the messages from xinetd, ending with a line like >this: [root@slaw amanda]# service xinetd restart Stopping xinetd: [ OK ] Starting xinetd: [ OK ] [root@slaw amanda]# tail -n 5 /var/log/messages Jun 3 14:38:57 slaw xinetd[1792]: time disabled, removing Jun 3 14:38:57 slaw xinetd[1792]: ftp disabled, removing Jun 3 14:38:58 slaw xinetd[1792]: xinetd Version 2.3.3 started with libwrap options compiled in. Jun 3 14:38:58 slaw xinetd[1792]: Started working: 4 available services Jun 3 14:39:00 slaw xinetd: xinetd startup succeeded >Look for any error messages, and check to see if that number matches the >number of xinetd based services listed as "on" by 'chkconfig --list'. No error messages, I count 4 xinetd services "on" and 4 available services in /var/log/messages (above) >That's not so interesting. What we're looking for is amindexd*debug. >That file just tells us that amrecover fails, which we knew already. :) Of course it's not interesting...I opened the wrong &*#@($! file!! :-) But this isn't getting to me, really...ugh amindexd*debug looks more like this: amindexd: debug 1 pid 1601 ruid 502 euid 502 start time Mon Jun 3 13:54:37 2002 amindexd: version 2.4.2p2 getpeername: Socket operation on non-socket amindexd: pid 1601 finish time Mon Jun 3 13:54:37 2002 Is that interesting? >That looks like a service that is looping and getting shut off for a >while. Hmmm After I restart xinetd and try to amrecover, I first get: [root@slaw amanda]# amrecover uadaily AMRECOVER Version 2.4.2p2. Contacting server on slaw.unterlaw.com ... amrecover: Error reading line from server: Connection reset by peer /var/log/messages says this: un 3 14:42:28 slaw xinetd[1802]: warning: can't get client address: Transport endpoint is not connected Jun 3 14:42:28 slaw xinetd[1803]: warning: can't get client address: Transport endpoint is not connected Jun 3 14:42:28 slaw xinetd[1804]: warning: can't get client address: Transport endpoint is not connected Jun 3 14:42:28 slaw xinetd[1805]: warning: can't get client address: Transport endpoint is not connected Jun 3 14:42:28 slaw xinetd[1806]: warning: can't get client address: Transport endpoint is not connected Jun 3 14:42:28 slaw xinetd[1807]: warning: can't get client address: Transport endpoint is not connected Jun 3 14:42:28 slaw xinetd[1808]: warning: can't get client address: Transport endpoint is not connected Jun 3 14:42:28 slaw xinetd[1809]: warning: can't get client address: Transport endpoint is not connected Jun 3 14:42:28 slaw xinetd[1810]: warning: can't get client address: Transport endpoint is not connected Jun 3 14:42:28 slaw xinetd[1811]: warning: can't get client address: Transport endpoint is not connected Jun 3 14:42:28 slaw xinetd[1792]: amandaidx service was deactivated because of looping So your looping theory is correct, sir. But why am I looping? (I'm getting to be like a 5 year old. The more questions you answer, the more questions I have?!) -- Joshua Baker-LePain Department of Biomedical Engineering Duke University
RE: Amrecover connection refused - again!
On Mon, 3 Jun 2002 at 2:08pm, Rebecca Pakish wrote > Where the heck is 10082/tcp amandaidx??? Try this. Do '/etc/init.d/xinetd restart'. Then, look in /var/log/messages for the messages from xinetd, ending with a line like this: Jun 3 15:27:23 $HOST xinetd[29922]: Started working: 3 available services Look for any error messages, and check to see if that number matches the number of xinetd based services listed as "on" by 'chkconfig --list'. > >Try telneting to the port again. Then go to /tmp/amanda and locate > >the amindexd..debug file. Look in there for a hint. > >There are probably lots of these files so be sure to get the right > >one. (OR just delete all of them before telnetting :-) > > amrecover.bunchanumbers.debug: > amrecover: debug 1 pid 1602 ruid 0 euid 0 start time Mon Jun 3 13:56:07 > 2002 > amrecover: stream_client: connect(10082) failed: Connection refused > cannot connect to slaw.unterlaw.com: Connection refused > amrecover: pid 1602 finish time Mon Jun 3 13:56:07 2002 That's not so interesting. What we're looking for is amindexd*debug. That file just tells us that amrecover fails, which we knew already. :) > /var/log secure: > > Jun 3 13:52:22 slaw xinetd[843]: START: amidxtape pid=1595 from=10.1.7.23 > > is all that was in there from the last time I tried amrecover Hrrm. When I run amrecover, all I see on my server is amandaidx starting up. > I saw this in there from this morning: > Jun 3 09:51:58 slaw xinetd[843]: START: amandaidx pid=1134 from=0.0.0.0 > Jun 3 09:51:58 slaw xinetd[843]: START: amandaidx pid=1135 from=0.0.0.0 > Jun 3 09:51:58 slaw xinetd[843]: START: amandaidx pid=1136 from=0.0.0.0 > Jun 3 09:51:58 slaw xinetd[843]: START: amandaidx pid=1137 from=0.0.0.0 > Jun 3 09:51:58 slaw xinetd[843]: START: amandaidx pid=1138 from=0.0.0.0 > Jun 3 09:51:58 slaw xinetd[843]: START: amandaidx pid=1139 from=0.0.0.0 > Jun 3 09:51:58 slaw xinetd[843]: START: amandaidx pid=1140 from=0.0.0.0 > Jun 3 09:51:58 slaw xinetd[843]: START: amandaidx pid=1141 from=0.0.0.0 > Jun 3 09:51:58 slaw xinetd[843]: START: amandaidx pid=1142 from=0.0.0.0 > Jun 3 09:51:58 slaw xinetd[843]: START: amandaidx pid=1143 from=0.0.0.0 That looks like a service that is looping and getting shut off for a while. Hmmm -- Joshua Baker-LePain Department of Biomedical Engineering Duke University
RE: Amrecover connection refused - again!
>Do you have nmap ? Try: > ># nmap -sT -p 10082 chena [root@slaw etc]# nmap -sT -p 10082 slaw.unterlaw.com Starting nmap V. 2.54BETA22 ( www.insecure.org/nmap/ ) The 1 scanned port on slaw.unterlaw.com (10.1.7.23) is: closed Nmap run completed -- 1 IP address (1 host up) scanned in 1 second That doesn't look happy...further investigation revealed: [root@slaw etc]# nmap -v slaw.unterlaw.com Starting nmap V. 2.54BETA22 ( www.insecure.org/nmap/ ) No tcp,udp, or ICMP scantype specified, assuming vanilla tcp connect() scan. Use -sP if you really don't want to portscan (and just want to see what hosts are up). Host slaw.unterlaw.com (10.1.7.23) appears to be up ... good. Initiating Connect() Scan against slaw.unterlaw.com (10.1.7.23) Adding TCP port 22 (state open). Adding TCP port 224 (state open). Adding TCP port 10083 (state open). Adding TCP port 111 (state open). The Connect() Scan took 1 second to scan 1542 ports. Interesting ports on slaw.unterlaw.com (10.1.7.23): (The 1538 ports scanned but not shown below are in state: closed) Port State Service 22/tcp openssh 111/tcpopensunrpc 224/tcpopenunknown 10083/tcp openamidxtape Where the heck is 10082/tcp amandaidx??? >Do an ldd on /usr/local/libexec/amindexd. JIC. I get somerhing like >this on my Linux server: I get that, too. >Make sure that /usr/local/libexec/amindexd is executable and will >start up. as the amanda user try: > >$ /usr/local/libexec/amindexd > >You should see somethng like: > >amindexd: getpeername: Socket operation on non-socket Yes, I get this as well. >Try telneting to the port again. Then go to /tmp/amanda and locate >the amindexd..debug file. Look in there for a hint. >There are probably lots of these files so be sure to get the right >one. (OR just delete all of them before telnetting :-) amrecover.bunchanumbers.debug: amrecover: debug 1 pid 1602 ruid 0 euid 0 start time Mon Jun 3 13:56:07 2002 amrecover: stream_client: connect(10082) failed: Connection refused cannot connect to slaw.unterlaw.com: Connection refused amrecover: pid 1602 finish time Mon Jun 3 13:56:07 2002 ~ >If you are using Linux, look in /var/log/secure to see if xinetd is >erally starting amandidx is. /var/log secure: Jun 3 13:52:22 slaw xinetd[843]: START: amidxtape pid=1595 from=10.1.7.23 is all that was in there from the last time I tried amrecover I saw this in there from this morning: Jun 3 09:51:58 slaw xinetd[843]: START: amandaidx pid=1134 from=0.0.0.0 Jun 3 09:51:58 slaw xinetd[843]: START: amandaidx pid=1135 from=0.0.0.0 Jun 3 09:51:58 slaw xinetd[843]: START: amandaidx pid=1136 from=0.0.0.0 Jun 3 09:51:58 slaw xinetd[843]: START: amandaidx pid=1137 from=0.0.0.0 Jun 3 09:51:58 slaw xinetd[843]: START: amandaidx pid=1138 from=0.0.0.0 Jun 3 09:51:58 slaw xinetd[843]: START: amandaidx pid=1139 from=0.0.0.0 Jun 3 09:51:58 slaw xinetd[843]: START: amandaidx pid=1140 from=0.0.0.0 Jun 3 09:51:58 slaw xinetd[843]: START: amandaidx pid=1141 from=0.0.0.0 Jun 3 09:51:58 slaw xinetd[843]: START: amandaidx pid=1142 from=0.0.0.0 Jun 3 09:51:58 slaw xinetd[843]: START: amandaidx pid=1143 from=0.0.0.0 >Can't think of anything else off hand.
RE: Amrecover connection refused - again!
On Mon, 3 Jun 2002, Rebecca Pakish wrote:
- >Can you telnet to each of thes ports?
-
- >$ telent amandaix (use 'quit' to exit)
-
- [root@slaw etc]# telnet slaw.unterlaw.com amandaidx
- Trying 10.1.7.23...
- telnet: connect to address 10.1.7.23: Connection refused
This is definitly a problem. That connection should not be refused.
This may require the 'shotgun' approach.
Do you have nmap ? Try:
# nmap -sT -p 10082 chena
Just to make sure it is not filtered. Probably not the problem tho...
Do an ldd on /usr/local/libexec/amindexd. JIC. I get somerhing like
this on my Linux server:
$ ldd /usr/local/libexec/amindexd
libm.so.6 => /lib/i686/libm.so.6 (0x4001e000)
libreadline.so.4 => /usr/lib/libreadline.so.4 (0x40041000)
libtermcap.so.2 => /lib/libtermcap.so.2 (0x40067000)
libnsl.so.1 => /lib/libnsl.so.1 (0x4006b000)
libc.so.6 => /lib/i686/libc.so.6 (0x40081000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x4000)
Make sure that /usr/local/libexec/amindexd is executable and will
start up. as the amanda user try:
$ /usr/local/libexec/amindexd
You should see somethng like:
amindexd: getpeername: Socket operation on non-socket
This just tests that amindexd will start up.
Try telneting to the port again. Then go to /tmp/amanda and locate
the amindexd..debug file. Look in there for a hint.
There are probably lots of these files so be sure to get the right
one. (OR just delete all of them before telnetting :-)
If you are using Linux, look in /var/log/secure to see if xinetd is
erally starting amandidx is.
Can't think of anything else off hand.
- >$ telnet amidxtape ('quit' or CR to exit)
- [root@slaw etc]# telnet slaw.unterlaw.com amidxtape
- Trying 10.1.7.23...
- Connected to slaw.unterlaw.com.
- Escape character is '^]'.
-
- >If not, reload xinetd and check the messages file for any errors.
- >Also make sure that ipchains or iptables is not filtering the port.
-
- I don't see where they are...
-
--
-- Stephen Carville
UNIX and Network Administrator
DPSI (formerly Ace USA Flood Services)
310-342-3602
[EMAIL PROTECTED]
Re: Amrecover connection refused - again!
On Mon, Jun 03, 2002 at 10:15:34AM -0500, Rebecca Pakish wrote: > >Can you telnet to each of thes ports? > > >$ telent amandaix (use 'quit' to exit) > > [root@slaw etc]# telnet slaw.unterlaw.com amandaidx > Trying 10.1.7.23... > telnet: connect to address 10.1.7.23: Connection refused > Not stating the obvious I hope, but this should not be: jon: telnet localhost amandaidx Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. 220 butch AMANDA index server (2.4.2) ready. This is the starting dialog I get. At least you can now focus on amandaidx. -- Jon H. LaBadie [EMAIL PROTECTED] JG Computing 4455 Province Line Road(609) 252-0159 Princeton, NJ 08540-4322 (609) 683-7220 (fax)
RE: Amrecover connection refused - again!
>>If not, reload xinetd and check the messages file for any errors. >>Also make sure that ipchains or iptables is not filtering the port. >I don't see where they are... That was very unclear of me...I meant I don't see where they are filtering the port. (There I go having half the conversation in my head again!) I ipconfig and iptables scripts default their configs to /etc/sysconfig/ipchains and /etc/sysconfig/iptables respectively. I am not filtering this port in these files.
RE: Amrecover connection refused - again!
>I'm not so sure. I have a similar setup -- all three in one file -- >and chkconfig reports the same thing to me. However, amrecover works >fine for me. I've been using the "one-file method" for some time now and it's always worked for me, as well. That's what's so confusing about this...it's all of a sudden. I haven't changed a thing!!!
RE: Amrecover connection refused - again!
On Mon, 3 Jun 2002, Joshua Baker-LePain wrote:
- On Mon, 3 Jun 2002 at 9:38am, Rebecca Pakish wrote
-
- > xinetd based services:
- > chargen-udp:off
- > chargen:off
- > daytime-udp:off
- > daytime:off
- > echo-udp: off
- > echo: off
- > time-udp: off
- > time: off
- > amanda: on
- > sgi_fam:on
- > finger: off
- > rexec: off
- > rlogin: off
- > rsh:off
- > ntalk: off
- > talk: off
- > telnet: off
- > wu-ftpd:off
- > rsync: off
-
- There's your problem -- the service isn't running. Maybe an xinetd
- upgrade changed the functionality such that the three services in one
- file method doesn't work any longer. In any case, break your
- /etc/xinetd.d/amanda file into three files -- amanda, amandaidx, and
- amidxtape -- and restart xinetd. All three services should then show up
- in the above output.
I'm not so sure. I have a similar setup -- all three in one file --
and chkconfig reports the same thing to me. However, amrecover works
fine for me.
- > Nothing in /etc/hosts.deny...would ipchains really benefit me? I'm blocking
- > everything at the firewall, so I don't fell I need to worry about 'who' is
- > using my services...
-
- Well, I'm paranoid, so I always set up both ipchains and
- hosts.{allow,deny} fairly tightly. Of course, I'm also in academentia,
- where every host (just about) is connected to the Big Bad Internet.
-
-
--
-- Stephen Carville
UNIX and Network Administrator
DPSI (formerly Ace USA Flood Services)
310-342-3602
[EMAIL PROTECTED]
RE: Amrecover connection refused - again!
>Can you telnet to each of thes ports?
>$ telent amandaix (use 'quit' to exit)
[root@slaw etc]# telnet slaw.unterlaw.com amandaidx
Trying 10.1.7.23...
telnet: connect to address 10.1.7.23: Connection refused
>$ telnet amidxtape ('quit' or CR to exit)
[root@slaw etc]# telnet slaw.unterlaw.com amidxtape
Trying 10.1.7.23...
Connected to slaw.unterlaw.com.
Escape character is '^]'.
>If not, reload xinetd and check the messages file for any errors.
>Also make sure that ipchains or iptables is not filtering the port.
I don't see where they are...
RE: Amrecover connection refused - again!
>There's your problem -- the service isn't running. Maybe an xinetd
>upgrade changed the functionality such that the three services in one
>file method doesn't work any longer. In any case, break your
>/etc/xinetd.d/amanda file into three files -- amanda, amandaidx, and
>amidxtape -- and restart xinetd. All three services should then show up
>in the above output.
I did that and no change...
[root@slaw root]# amrecover uadaily
AMRECOVER Version 2.4.2p2. Contacting server on slaw.unterlaw.com ...
amrecover: Error reading line from server: Connection reset by peer
[root@slaw root]# amrecover uadaily
AMRECOVER Version 2.4.2p2. Contacting server on slaw.unterlaw.com ...
amrecover: cannot connect to slaw.unterlaw.com: Connection refused
[root@slaw root]#
I can, however, see amandaidx and amidxtape when I chkconfig...
xinetd based services:
chargen-udp:off
chargen:off
daytime-udp:off
daytime:off
echo-udp: off
echo: off
time-udp: off
time: off
amanda: on
sgi_fam:on
finger: off
rexec: off
rlogin: off
rsh:off
ntalk: off
talk: off
telnet: off
wu-ftpd:off
rsync: off
amandaidx: on
amidxtape: on
>Well, I'm paranoid, so I always set up both ipchains and
>hosts.{allow,deny} fairly tightly. Of course, I'm also in academentia,
>where every host (just about) is connected to the Big Bad Internet.
Ah...I see. I probably should be more paranoid...but we tightly
configured our big bad checkpoint firewall, so I think we're okay.
RE: Amrecover connection refused - again!
On Mon, 3 Jun 2002 at 9:38am, Rebecca Pakish wrote
> xinetd based services:
> chargen-udp:off
> chargen:off
> daytime-udp:off
> daytime:off
> echo-udp: off
> echo: off
> time-udp: off
> time: off
> amanda: on
> sgi_fam:on
> finger: off
> rexec: off
> rlogin: off
> rsh:off
> ntalk: off
> talk: off
> telnet: off
> wu-ftpd:off
> rsync: off
There's your problem -- the service isn't running. Maybe an xinetd
upgrade changed the functionality such that the three services in one
file method doesn't work any longer. In any case, break your
/etc/xinetd.d/amanda file into three files -- amanda, amandaidx, and
amidxtape -- and restart xinetd. All three services should then show up
in the above output.
> Nothing in /etc/hosts.deny...would ipchains really benefit me? I'm blocking
> everything at the firewall, so I don't fell I need to worry about 'who' is
> using my services...
Well, I'm paranoid, so I always set up both ipchains and
hosts.{allow,deny} fairly tightly. Of course, I'm also in academentia,
where every host (just about) is connected to the Big Bad Internet.
--
Joshua Baker-LePain
Department of Biomedical Engineering
Duke University
RE: Amrecover connection refused - again!
>I've got wait=no there, but I don't know that that is your issue. There's a reason I have wait=yes, but for the life of me I can't remember what it is. >What's the output of 'chkconfig --list'? [root@slaw etc]# chkconfig --list keytable0:off 1:on2:on3:on4:on5:on6:off atd 0:off 1:off 2:off 3:on4:on5:on6:off kdcrotate 0:off 1:off 2:off 3:off 4:off 5:off 6:off syslog 0:off 1:off 2:on3:on4:on5:on6:off gpm 0:off 1:off 2:on3:on4:on5:on6:off kudzu 0:off 1:off 2:off 3:on4:on5:on6:off sendmail0:off 1:off 2:on3:on4:on5:on6:off netfs 0:off 1:off 2:off 3:on4:on5:on6:off network 0:off 1:off 2:on3:on4:on5:on6:off random 0:off 1:off 2:on3:on4:on5:on6:off rawdevices 0:off 1:off 2:off 3:on4:on5:on6:off apmd0:off 1:off 2:on3:on4:on5:on6:off ipchains0:off 1:off 2:on3:on4:on5:on6:off iptables0:off 1:off 2:on3:on4:on5:on6:off crond 0:off 1:off 2:on3:on4:on5:on6:off anacron 0:off 1:off 2:on3:on4:on5:on6:off lpd 0:off 1:off 2:on3:on4:on5:on6:off xfs 0:off 1:off 2:on3:on4:on5:on6:off ntpd0:off 1:off 2:off 3:off 4:off 5:off 6:off portmap 0:off 1:off 2:off 3:on4:on5:on6:off xinetd 0:off 1:off 2:off 3:on4:on5:on6:off autofs 0:off 1:off 2:off 3:on4:on5:on6:off nfs 0:off 1:off 2:off 3:off 4:off 5:off 6:off nfslock 0:off 1:off 2:off 3:on4:on5:on6:off nscd0:off 1:off 2:off 3:off 4:off 5:off 6:off identd 0:off 1:off 2:off 3:off 4:off 5:off 6:off radvd 0:off 1:off 2:off 3:off 4:off 5:off 6:off rwhod 0:off 1:off 2:off 3:off 4:off 5:off 6:off snmpd 0:off 1:off 2:off 3:off 4:off 5:off 6:off rhnsd 0:off 1:off 2:off 3:off 4:off 5:off 6:off ypbind 0:off 1:off 2:off 3:off 4:off 5:off 6:off isdn0:off 1:off 2:on3:on4:on5:on6:off sshd0:off 1:off 2:on3:on4:on5:on6:off rstatd 0:off 1:off 2:off 3:off 4:off 5:off 6:off rusersd 0:off 1:off 2:off 3:off 4:off 5:off 6:off rwalld 0:off 1:off 2:off 3:off 4:off 5:off 6:off vncserver 0:off 1:off 2:off 3:off 4:off 5:off 6:off yppasswdd 0:off 1:off 2:off 3:off 4:off 5:off 6:off ypserv 0:off 1:off 2:off 3:off 4:off 5:off 6:off ypxfrd 0:off 1:off 2:off 3:off 4:off 5:off 6:off wine0:off 1:off 2:on3:on4:on5:on6:off mserver 0:off 1:off 2:off 3:on4:on5:on6:off xinetd based services: chargen-udp:off chargen:off daytime-udp:off daytime:off echo-udp: off echo: off time-udp: off time: off amanda: on sgi_fam:on finger: off rexec: off rlogin: off rsh:off ntalk: off talk: off telnet: off wu-ftpd:off rsync: off >Do you have anything in /etc/hosts.deny? If not, I really hope you have >ipchains set up... Nothing in /etc/hosts.deny...would ipchains really benefit me? I'm blocking everything at the firewall, so I don't fell I need to worry about 'who' is using my services...
Re: Amrecover connection refused - again!
Joshua Baker-LePain wrote: > On Mon, 3 Jun 2002 at 8:39am, Rebecca Pakish wrote > > >>[root@ants root]# amrecover uadaily >>AMRECOVER Version 2.4.2p2. Contacting server on slaw.unterlaw.com ... >>amrecover: cannot connect to slaw.unterlaw.com: Connection refused >> >>***amrecover debut says: >>amrecover: debug 1 pid 8047 ruid 0 euid 0 start time Mon Jun 3 08:21:40 >>2002 >>amrecover: stream_client: connect(10082) failed: Connection refused >>cannot connect to slaw.unterlaw.com: Connection refused >>amrecover: pid 8047 finish time Mon Jun 3 08:21:40 2002 >> >>In previous posts they said something about 10082 port not running. I >>haven't changed a thing on my /etc/xinetd.d/amanda file. I did recently >>change tape drives, but that shouldn't have anything to do with it, should >>it??? I restarted xinetd just in case and it gave no errors on restart. >> > > That's not the file you're looking for. I believe it's > /etc/xinetd.d/amandaidx that allows amrecover to work remotely. You'll > also need to make sure that the service is allowed in /etc/hosts.allow > (it's amindexd) on slaw from ants. > Also check your firewall settings on the linux box. ipchains running? -- = Jonathan Murray Computer and Information Services Woods Hole Oceanographic Institution http://www.whoi.edu Woods Hole, MA 02543-1541 voice: (508) 289-2877 fax: (508) 457-2174 e-mail: [EMAIL PROTECTED] =
RE: Amrecover connection refused - again!
Can you telnet to each of thes ports?
$ telent amandaix (use 'quit' to exit)
$ telnet amidxtape ('quit' or CR to exit)
If not, reload xinetd and check the messages file for any errors.
Also make sure that ipchains or iptables is not filtering the port.
On Mon, 3 Jun 2002, Rebecca Pakish wrote:
- >That's not the file you're looking for. I believe it's
- >/etc/xinetd.d/amandaidx that allows amrecover to work remotely.
-
- I don't have that file...I have a file /etc/xinetd.d/amanda that looks like
- this...
- service amanda
- {
- protocol= udp
- socket_type = dgram
- wait= yes
- user= amanda
- group = disk
- groups = yes
- server = /usr/local/libexec/amandad
- }
-
- service amandaidx
- {
- protocol= tcp
- socket_type = stream
- wait= yes
- user= amanda
- group = disk
- groups = yes
- server = /usr/local/libexec/amindexd
- }
-
- service amidxtape
- {
- protocol= tcp
- socket_type = stream
- wait= no
- user= amanda
- group = disk
- groups = yes
- server = /usr/local/libexec/amidxtaped
-
- I get the same error when I try to run amrecover on the amanda server, as
- well, so it's not a remote issue.
-
- >You'll also need to make sure that the service is allowed in
- /etc/hosts.allow
- >(it's amindexd) on slaw from ants.
-
- I currently don't have anything in /etc/hosts.allow, but I never have, and
- I've run amrecover before. (?) What do I need to add, just a line that says
- amindexd?
-
- rap
-
-
--
-- Stephen Carville
UNIX and Network Administrator
DPSI (formerly Ace USA Flood Services)
310-342-3602
[EMAIL PROTECTED]
RE: Amrecover connection refused - again!
On Mon, 3 Jun 2002 at 9:02am, Rebecca Pakish wrote
> >That's not the file you're looking for. I believe it's
> >/etc/xinetd.d/amandaidx that allows amrecover to work remotely.
>
> I don't have that file...I have a file /etc/xinetd.d/amanda that looks like
> this...
Ah, yes, that should work (I think). xinetd still confuses me.
> service amandaidx
> {
> protocol= tcp
> socket_type = stream
> wait= yes
I've got wait=no there, but I don't know that that is your issue.
> I get the same error when I try to run amrecover on the amanda server, as
> well, so it's not a remote issue.
What's the output of 'chkconfig --list'?
> >You'll also need to make sure that the service is allowed in
> /etc/hosts.allow
> >(it's amindexd) on slaw from ants.
>
> I currently don't have anything in /etc/hosts.allow, but I never have, and
> I've run amrecover before. (?) What do I need to add, just a line that says
> amindexd?
Do you have anything in /etc/hosts.deny? If not, I really hope you have
ipchains set up...
--
Joshua Baker-LePain
Department of Biomedical Engineering
Duke University
RE: Amrecover connection refused - again!
>That's not the file you're looking for. I believe it's
>/etc/xinetd.d/amandaidx that allows amrecover to work remotely.
I don't have that file...I have a file /etc/xinetd.d/amanda that looks like
this...
service amanda
{
protocol= udp
socket_type = dgram
wait= yes
user= amanda
group = disk
groups = yes
server = /usr/local/libexec/amandad
}
service amandaidx
{
protocol= tcp
socket_type = stream
wait= yes
user= amanda
group = disk
groups = yes
server = /usr/local/libexec/amindexd
}
service amidxtape
{
protocol= tcp
socket_type = stream
wait= no
user= amanda
group = disk
groups = yes
server = /usr/local/libexec/amidxtaped
I get the same error when I try to run amrecover on the amanda server, as
well, so it's not a remote issue.
>You'll also need to make sure that the service is allowed in
/etc/hosts.allow
>(it's amindexd) on slaw from ants.
I currently don't have anything in /etc/hosts.allow, but I never have, and
I've run amrecover before. (?) What do I need to add, just a line that says
amindexd?
rap
Re: Amrecover connection refused - again!
On Mon, 3 Jun 2002 at 8:39am, Rebecca Pakish wrote > [root@ants root]# amrecover uadaily > AMRECOVER Version 2.4.2p2. Contacting server on slaw.unterlaw.com ... > amrecover: cannot connect to slaw.unterlaw.com: Connection refused > > ***amrecover debut says: > amrecover: debug 1 pid 8047 ruid 0 euid 0 start time Mon Jun 3 08:21:40 > 2002 > amrecover: stream_client: connect(10082) failed: Connection refused > cannot connect to slaw.unterlaw.com: Connection refused > amrecover: pid 8047 finish time Mon Jun 3 08:21:40 2002 > > In previous posts they said something about 10082 port not running. I > haven't changed a thing on my /etc/xinetd.d/amanda file. I did recently > change tape drives, but that shouldn't have anything to do with it, should > it??? I restarted xinetd just in case and it gave no errors on restart. That's not the file you're looking for. I believe it's /etc/xinetd.d/amandaidx that allows amrecover to work remotely. You'll also need to make sure that the service is allowed in /etc/hosts.allow (it's amindexd) on slaw from ants. -- Joshua Baker-LePain Department of Biomedical Engineering Duke University
Amrecover connection refused - again!
Hello all, I know this topic was just covered, but the answers really don't seem to be helping me. I've been running amanda for almost a year now, and have been indexing and successfully recovering individual files. All of a sudden I'm getting this error: [root@ants root]# amrecover uadaily AMRECOVER Version 2.4.2p2. Contacting server on slaw.unterlaw.com ... amrecover: cannot connect to slaw.unterlaw.com: Connection refused ***amrecover debut says: amrecover: debug 1 pid 8047 ruid 0 euid 0 start time Mon Jun 3 08:21:40 2002 amrecover: stream_client: connect(10082) failed: Connection refused cannot connect to slaw.unterlaw.com: Connection refused amrecover: pid 8047 finish time Mon Jun 3 08:21:40 2002 In previous posts they said something about 10082 port not running. I haven't changed a thing on my /etc/xinetd.d/amanda file. I did recently change tape drives, but that shouldn't have anything to do with it, should it??? I restarted xinetd just in case and it gave no errors on restart. Oh! Amanda 2.4.2p2 on RH7.2... Any suggestions would be appreciated. Thanks, rap Rebecca A. Pakish Systems Administrator Unterberg & Associates, P.C. (219) 736-5579 ext. 184
