nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Weird connectivity problem

Tbag

Hi,

I think I've got a stumper for ya...

Base: OD 6.0.1.0.0 Build 41860 Interwoven 20041018 on Windows Server 2003, standard edition.

Target: OD Version 6.0.1.0.0 Build 41860 Interwoven 20041018 on RedHat Enterprise Linux 4 (Nahant Update 2)

Problem:
Trying a super-simple deployment from Base to Target results in this error on the base. Absolutely nothing is reported on the receiver (not even a peep).
Base: Exceeded all 3 retries to get a connection with the target OpenDeploy host.
Failed creating socket.

Theory 1: SSL was mis-configured
I got rid of all traces of SSL configurations on both Base and Target and restarted; no luck

Theory 2: A firewall mis-configuration
I stopped OD on the Target and ran an FTP server on port 20014 instead and it works fine.

Theory 3: Red Hat 4 isn't really supported
I'm running this identical OD version on another RH 4 server and it works. I thought maybe it was a /usr/lib .so problem, but I doubt it...I've basically mirrored the working version's .so files and symlinks on this non-working Target and still no joy.

Theory 4: I've got fat finger and I've overlooked some super-simple configuration problem
I've poured over these configs 5 times and can't see anything wrong. (Attaching them for your ridicule and amusement)

Theory 5: DNS/IP screw up
I've adjusted the odnodes.xml on both Base and Target to use IPs instead of machinenames and no combination works.

Side Note about telnet:
From the base, I've tried a DOS prompt "telnet target 20014" and I get "Connecting To target...Could not open connection to the host, on port 20014:"

Normally, that's a huge red flag that there's a network problem between the two boxes, but then harken back to "Theory 2" (above) and note that FTP works.

Any thoughts?
TIA,
Tom

Find more posts tagged with

Comments

Tbag

Base's odbase.xml

Tbag

Target's odrcvr.xml and odnodes.xml file (joined in one file for brevity of posting)

FieldMappingData_NumFormatting.zip

Adam Stoller

Theory 2: A firewall mis-configuration
I stopped OD on the Target and ran an FTP server on port 20014 instead and it works fine.

The theory is fine - the test of the theory is questionable.

You should leave the OD Receiver running - and from your Base Server host - try to telnet to the target receiver's port 20014

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com

Tbag

Yeah...but the point of the "telnet test" is to determine whether or not machine A can talk to machine B over a network on a specific port, right? So it shouldn't really matter if you use FTP or telnet or netmap or whatever, right?

I don't know that much about firewalls, but it's highly unlikely that a firewall is configured to only allow (port, protocol) combinations, right? My concept of a firewall is that it allows ports, and whatever protocol your server responds to on that port is irrelevant.

I *did* try the telnet test (see my original post; at the bottom) and it didn't work...what does this imply?

jbonifaci

If you can't telnet to the target server from the base server on port 20014 (or whatever part you configured od to listen on), it usually means either OpenDeploy is not up and running on the target server or that port is still blocked.

~Jeff

Tbag

Yeah, and this is what's so perplexing about it....

On the target, if I run "netstat -an | grep 20014", I see that the port is listening. The iwodservergetstatus returns the expected "Yep, I'm up" message. The "ps -ef" shows that there's only 1 OD reciever process running. The odrcvr.xml file shows that it is set to listen on 20014.

And yet, no connectivity.

If I shut down OD and start up an FTP server that gets bound to 20014, I can connect.

It's almost like the combination of (OD, 20014) is the problem. Grrr....

Adam Stoller

I can think of several possibilities.
1. Something else (other than OD) is listening on port 20014 on the target receiver
2. OD is bound to a different IP address than the one you're actually trying to connect to
3. There's a firewall between the servers and the firewall is doing NAT and you need to use the firewall's IP address instead of the receiver's address (and the receiver needs to use the firewall's IP address for allowedHost)

There may be some other options - but those are the ones that come to mind.

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com

Tbag

Hmmm....good leads, Fish. I'll post what I find.

Thanks!

Tbag

Well sonofabitch...

The problem ended up being DNS related, I guess. The target reciever was on a recently built machine and in the odrcvr.xml file, my "localNode host='blah.x.com'"
was actually binding to 127.0.0.1:20014, even though the od.log on the target said "bound to babbittdev.x.com:20014"

When I changed the target's odrcvr.xml file to say "localNode host='192.168.1.15'" it worked.

I wonder if I switch it back to the machinename in couple weeks if it'll work.

Thanks for the help everyone.

Adam Stoller

You probably need to check the /etc/hosts file on the Receiver - there might be an entry in there that binds the hostname to the loopback IP. Removing that entry and restarting the OD server (rebooting the whole machine might be better) would probably fix things.

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com