0

We are running a continuous integration server with the following software:

  • Windows Server 2012 (AWS EC2 Instance)
  • TeamCity 9.0.3
  • Youtrack 6.0
  • Collabnet Subversion Edge 4.0.14-4110.144
  • Octopus Deploy 2.6.5.1010

All software is up-to-date version wise. Appropriate firewall exceptions are in place.

When we installed Octopus, we are able to access the Web Portal site on the default localhost url. However, when we add a new binding (http://od.ourservername.com:9107) in Octopus Manager to allow for external access we are not able to access the Web Portal externally. All other services on the machine are accessible externally.

The log files (OctopusServer.txt) show the following entries:

2015-04-21 21:16:10.9977 1 INFO Service started
2015-04-21 21:16:44.3727 1 INFO Web force SSL: False
2015-04-21 21:16:45.4509 1 INFO Web listen prefixes: http://od.ourservername.com:9107/
2015-04-21 21:16:46.6696 1 INFO Service stopped
2015-04-21 21:16:46.8415 1 INFO Waiting for service to start. Current status: StartPending
2015-04-21 21:16:47.8570 1 INFO Waiting for service to start. Current status: Running
2015-04-21 21:16:48.6071 5 INFO Browse your Octopus server at: http://localhost:9107/
2015-04-21 21:16:48.8727 1 INFO Service started
2015-04-21 21:16:56.8727 5 INFO You can browse the RavenDB server at: http://localhost:10931/
2015-04-21 21:17:00.6227 5 INFO The database is up to date.
2015-04-21 21:17:01.8883 5 INFO Distribution service listening on: 10943
2015-04-21 21:17:02.1852 5 INFO Web server is ready to process requests

The OctopusServer.config file contains the following keys:

<set key="Octopus.WebPortal.ForceSsl">false</set>
<set key="Octopus.WebPortal.ListenPrefixes">http://od.ourservername.com:9107/</set>

A call to netstat -a returns (in part):

TCP 0.0.0.0:9100 OurServer:0 LISTENING
TCP 0.0.0.0:9107 OurServer:0 LISTENING
TCP 0.0.0.0:9119 OurServer:0 LISTENING
TCP 0.0.0.0:9142 OurServer:0 LISTENING

The following Octopus Deploy issue on GitHub is perhaps the closest info we could find. But we are not using a reverse proxy. https://github.com/OctopusDeploy/Issues/issues/437

We have tried uninstall/reinstall. Rebooting. Various combinations of protocol and port.

Any ideas?

1

2 Answers 2

0

This message suggests somewhere in your octopus config(s) 'localhost' should be changed to '0.0.0.0' to instruct the server to listen for messages from other machines as well, not only from localhost:

2015-04-21 21:16:48.6071 5 INFO Browse your Octopus server at: http://localhost:9107/

5
  • Isn't that what the Web listen prefixes log message is saying? Browse your Octopus server at http://od.ourservername.com:9107/ in addition to the default http://localhost:9107/?
    – Rich C
    Jun 1, 2015 at 18:24
  • Hm, not sure if the 'Web listen prefixes' port is also for the browsing the Octopus server - why would they have a different message format? To me that 'localhost' is suspect as it's intended only for the local machine (which is somehow inline with the complaint about access from other machines). Jun 1, 2015 at 22:14
  • In the Octopus Manager the Web Bindings Wizard has a step called Web Portal Bindings with a description that reads, "The web portal is the primary way that users interact with Octopus. We use an embedded web server ... which will listen on the bindings below." Following that description are the two bindings for our Octopus instance (http://od.ourservername.com:9107/ and http://localhost:9107/). In the settings file the Octopus.WebPortal.ListenPrefixes key lists the same two bindings.
    – Rich C
    Jun 2, 2015 at 18:47
  • Does modifying the one with 'localhost' into '0.0.0.0' make a difference? Jun 2, 2015 at 19:00
  • No. It has nothing to do with localhost.
    – Rich C
    Jun 2, 2015 at 20:00
0

Reading this post in Octopus Deploy Support made us go back over all of our port/address/permissions everywhere (again). The hole is correctly punched in the external firewall, but after checking Windows Firewall we found that the external port had not been opened up for inbound traffic. After adding the inbound rule, the external url specified in the Web Portal Bindings (and in Octopus.WebPortal.ListenPrefixes) began to work as expected.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .