I can can view the octopus deploy server via http://{my-ip-address}:8001/octopus from the machine my server is installed, I can even see it via http://localhost:8001/octopus.
However I want to view it on a machine other than the octopus deploy server, is this possible? I think it sounds like a firewall issue or something but I am not sure…
Any help is appreciated.
i ask this question because I cannot run a fake build script that will do the handshake with my octopus deploy server…
I’m also having this problem. Fresh install of Octopus Deploy server on Win Server 2008 R2; can access the administration web interface just fine via IE when RDP’d into the server. Attempting to connect to the server from my desktop I get nothing other than an eventual timeout.
Have configured the Windows Firewall with a blanket allow all inbound connections across every port, protocol, IP to this program (Octopus.Server.exe) and service (Octopus Server) but no luck. Have tried fiddling around with the bindings in the management app was well.
Hi James,
Thanks for getting in touch! Did you find this article in our documentation? http://docs.octopusdeploy.com/display/OD/Expose+the+Octopus+web+portal+over+HTTPS
It helps run through all the steps required to expose the portal over the web. If you are required to use any secondary IP addresses there are also steps needed to add these to http.sys as that is what Octopus uses. Let me know if this is the case.
Vanessa
Hi Vanessa,
Yes did come across that article, and have tried numerous different bindings.
Thing is, I’m not even trying to expose it over the web, just trying to access it from any other machine on our LAN (e.g. my development workstation). Cannot get to the web interface from any machine other than the server it is installed on. All bindings work fine from the server itself (as long as the machine name correctly resolves)
Which leads me to think there is some other machine level configuration required, despite having already put a generous firewall rule in place. I have TeamCity’s server process running on the same server and I am able to access it just fine (plus various IIS services as well). IIS is listening on port 80, TeamCity is listening on port 8888, I have tried Octopus on various combinations of 8880 and 8889.
I’m sure I’m missing something obvious!
Cheers,
James
Hi James,
This should be the last step if Octopus is the only thing using port 80. it needs to be configured in http.sys: http://www.diaryofaninja.com/blog/2010/09/14/how-to-stop-iis-binding-to-all-ip-addresses
Let me know if that helps.
Vanessa
Thanks for the quick response.
I want to keep IIS listening on port 80, it is Octopus I want to have listening on a non-standard port (e.g.8889). I have configured this in my bindings;
[cid:image001.png@01D12C4C.20F30870]
And from the desktop of the server itself, I can navigate to http://localhost:8889 or http://edgsvr01:8889 just fine;.
[cid:image002.png@01D12C4C.593FB8E0]
However if I try navigating to http://edgsvr01:8889 from my workstation on the same LAN (or if I replace edgsvr01 with its IP address) I get a timeout…
[cid:image003.png@01D12C4C.593FB8E0]
I have firewall rules set up on the server that permit connections to %ProgramFiles%\Octopus Deploy\Octopus\Octopus.Server.exe (and service) from any IP address, to any port, over any protocol.
Cheers,
James
Hi James,
Our instinct is the issue here is still firewall. (You could confirm by temporarily disabling the firewall and see if you can access it then.)
Could you open up the Inbound TCP on the Octopus port to any application.
We have never tried firewall rules while scoping in this way.
Vanessa
Yes, disabling the Windows Firewall got everything humming along.
Further investigation of my firewall rule demonstrated that attempting to restrict it by program (Octopus.Server.exe) or service (OctopusDeploy) in addition to port 8889 was the issue. Which makes sense now I think about it if HTTP.SYS is the real listener here (vs TeamCity which doesn’t use HTTP.SYS) Changing the firewall rule to just be by port and protocol resolved the issue.
Thanks!
James
Hi James,
Great! Glad we got there in the end.
Vanessa
