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; } } }

OD Error (firewall issue?)

tiroth

I am experiencing an error with a new OpenDeploy reciever. The base server is known working for other deployment targets.

The base and reciever software is OD 5.5.1 for NT.

The initial connection is made successfully:

ENG: 2002-11-12 08:02:34 EST GMT-05:00 Thread-40 Connecting to host=164.109.45.**** port=20014

ENG: 2002-11-12 08:02:35 EST GMT-05:00 Thread-40 After Connect RC = 0
ENG: 2002-11-12 08:02:35 EST GMT-05:00 Thread-40 Send version string to receiver, RC = 9
ENG: 2002-11-12 08:02:35 EST GMT-05:00 Thread-40 Send attributes to receiver, RC = 1
ENG: 2002-11-12 08:02:35 EST GMT-05:00 Thread-40 Read attributes from receiver.
ENG: 2002-11-12 08:02:35 EST GMT-05:00 Thread-40 sender-version=5.5.1 receiver-version=5.5.1
ENG: 2002-11-12 08:02:35 EST GMT-05:00 Thread-40 Sender is version master
ENG: 2002-11-12 08:02:35 EST GMT-05:00 Thread-40 Sender compatible with receiver: version same

The deployment chugs along for a bit and then errors out:

ERROR: Connection failed: Could not find matching OpenDeploy client for (164.109.45.****).

I have not been able to locate documentation about this error. The base server and reciever are both behind separate firewalls, with ports 9173 and 20014 opened for bidirectional traffic.

Any thoughts on the cause of this failure? Is this the result of the firewall changing the apparant IP of the base server?

Find more posts tagged with

Comments

Migrateduser

Make sure that the deployment config on the sending system specifies the firewall closest to the target as the "localNode". On the target system, specify the same firewall (closest to the target) as an allowed host in the receiver config file.

Also, you should not need port 9173 opened on the firewall, only the port through which data will be transmitted (20014).

Todd Scallan
Senior Product Manager
Interwoven
t: 408-530-7167
e: tscallan@interwoven.com

tiroth

I don't understand why this needs to be done if no translation is occurring.

Moreover, I'm a little confused by this. You state that the firewall closest to the target should be specified as the base servers' (odbase.xml) LocalNode. Why? This firewall will NEVER be seen when deploying to non-production servers, only when deploying to production.

Perhaps this will make the situation more clear:

Scenario A: publish to production
tsserver [192.168.0.2] -> firewall [??] -> routing -> firewall [??] -> webserver1 [192.168.1.2]

Scenario B: publish to QA
tsserver [192.168.0.2] -> webserver2 [192.168.1.3]

In both cases, no translation occurs, i.e. tsserver sees webservers as 192.168.1.2/.3 and webservers see tsserver as 192.168.0.2. The firewalls are transparent.

Edited by tiroth on 11/13/02 10:31 AM (server time).

Migrateduser

I was assuming the message...

ERROR: Connection failed: Could not find matching OpenDeploy client for (164.109.45.****).

...was due to the OD receiver not being able to authenticate the firewall attempting to connect (ie, not listed as an "allowed host").

Todd Scallan
Senior Product Manager
Interwoven
t: 408-530-7167
e: tscallan@interwoven.com

tiroth

No, 164.109.45.**** is in fact the opendeploy target which the server is currently talking to. Logs on the target side look the same: identical error. Any ideas?

Adam Stoller

There's some confusion here - the use of the firewall's IP address for localNode was to be used in the *deployment* configuration file (foo.xml) not the *server* configuration file (odbase.xml) - and to correspond it with an allowedHost setting in the Receivers' odrcvr.xml file.

You say there isn't any address translation being done, and that both servers can see each other for whom they are - were you using hostnames for localNode and allowedHost or IP addresses?

If you were using hostnames - try switching to IP addresses (192.168.0.2) just to see if that makes it work.

If it still doesn't work - try using the firewall's IP address - it can't hurt to try.

--fish
(Interwoven Senior Technical Consultant)

tiroth

For the benefit of others getting this error, it had nothing to do with the firewalls. Changing the hostname references on the reciever to IP addresses solved the problem.

If you have this problem, try this solution, because it worked for us despite the fact that we could resolve the hostnames successfully.