>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 open ssh 111/tcp open sunrpc 224/tcp open unknown 10083/tcp open amidxtape ---- 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.<bunchanumbers>.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: <snip> 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.
