Discussions
Categories
Groups
Community Home
Categories
INTERNAL ENABLEMENT
POPULAR
PUBLIC CLOUD
PRIVATE CLOUD
Quick Links
MY LINKS
HELPFUL TIPS
Back to website
Home
Web CMS (TeamSite)
Base: failed creating socket, got null.
pr0fess0r
Hi
I'm getting the error "Base: failed creating socket, got null" when trying to fire off a deployment, and I'm, wondering if this indicates that the port I'm using for OD (1701) is blocked.
We have formatted and rebuilt our teamSite server (which was running 4.5.2) and installed TS 5.5.2 and OD 5.5.1 SP-2
I have three destination servers, one outside our firewall and two inside. During setup our network guys opened port 1701 to the external server, and I can deploy to it fine. Whenever I try to deploy to either of the internal servers (configured exactly the same way) I get the error list, ie
ENG: 2002-11-03 14:54:40 NZDT GMT+13:00 Thread-112 Connecting to host=<SNIP> port=1701
ENG: 2002-11-03 14:55:33 NZDT GMT+13:00 Thread-112 ***ERROR - Job ID=m40Deployment=prod2
Base: failed creating socket, got null.
The network guys tell me all the ports should be open between all the servers on the same network. I tried the trick of using telnet <external server> 1701 and got a blank screen, but when I try telnet <internal server> 1701 I get an error about not being able to connect.
Should I pursue the fact the port 1701 isnt open? Or perhaps it's open for UDP and not TCP (or vice versa, which does OD use?) The previous installation of OD was able to deploy to these boxes.
Could anything else be causing this error? I've tried using IP addresses instead of host names in the various config files to no avail, any advice would be greatly appreciated
Lucas Young
Fencepost.com
Find more posts tagged with
Comments
Adam Stoller
Do you still have OpenDeploy 4.5.2 server processes running on the receivers?
1701 was the default port for 4.5.2. to listen on for deployments.
20014 is the default port for 5.x Receivers to listen on for deployments.
There is nothing that says you cannot use 1701 with 5.x - however, you cannot use a port that is being listened to by some other software (in this case, most likely an older version of OpenDeploy).
We usually recommend that as you phase over from using 4.x to 5.x OpenDeploy that you use a different port than you've been using for 4.x so that you can keep both running in parallel until you're satisfied that 5.x is working - then you can discontinue using the old port (and plug that hole back up in the firewall).
However - if you have gotten rid of the OpenDeploy software on your source / Base server - then there is no reason to keep the servers running on the receivers and you can continue using 1701.
Sorry if I rambled on a bit there - but hopefully this will help you clear up the problem.
--fish
(Interwoven Information Guy)
pr0fess0r
Hi
Yes, we did uninstall the previous version, but it doesnt seem to matter what port I use.
What's wierd is that the logs say the listener is up and running on port 1701, but if I try to telnet it I get a connection refused (but with the external server that is working, I can telnet that and get a blank screen, a sign that something is listening)
It seems like it says it's listening when it actually isnt...
Adam Stoller
Next shot in the dark ...
Does the receiver have multiple network cards / ip addresses ?
It's possible that the Receiver has bound to one IP address and you are [unintentionally] trying to connect to it through a different IP address.
If you have multiple IP's for the Receiver - I recommend setting the localNode in odrcvr.xml file to the specific IP you wish to use for connections and not just a "hostname" value - and likewise you may have to do the same thing in your odnodes.xml file on the Base Server side to make sure you are talking to the right IP.
--fish
(Interwoven Information Guy)
pr0fess0r
Yay!
It worked!!
I worship you *grovels*
many thanks
PaulW
FYI. I have also had this same error occur when I mistakenly had the wrong username in the deploy.cfg file.
GodBlessMe
Could you please post the solution to this problem? We are also facing the same problem.
Thanks
pr0fess0r
Sure, check Ghoti's response - we had two network cards on our machine and OpenDeploy was bound to the wrong one
cheers
Bowker
We had a similar issue. Turned out the firewall was doing an address translation.