brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sjcorbett <...@git.apache.org>
Subject [GitHub] incubator-brooklyn pull request: Ports @aledsage's Troubleshooting...
Date Thu, 09 Jul 2015 14:31:04 GMT
Github user sjcorbett commented on a diff in the pull request:

    https://github.com/apache/incubator-brooklyn/pull/741#discussion_r34260924
  
    --- Diff: docs/guide/dev/tips/troubleshooting-connectivity.md ---
    @@ -0,0 +1,141 @@
    +---
    +layout: website-normal
    +title: Troubleshooting Server Connectivity Issues in the Cloud
    +toc: /guide/toc.json
    +---
    +
    +A common problem when setting up an application in the cloud is getting the basic connectivity
right - how
    +do I get my service (e.g. a TCP host:port) publicly accessible over the internet.
    +
    +This varies a lot - e.g. is the VM public or in a private network, is the service only
accessible through
    +a load balancer, should the service be globally reachable or only to a particular CIDR.
    +
    +This blog post gives some general tips for debugging connectivity issues, which are applicable
to a 
    +range of different service types. Choose those that are appropriate for your use-case.
    +
    +## VM reachable
    +If the VM is supposed to be accessible directly (e.g. from the public internet, or if
in a private network
    +then from a jump host)...
    +
    +### ping
    +Can you `ping` the VM from the machine you are trying to reach it from.
    +
    +However, ping is over ICMP. If the VM is unreachable, it could be that the firewall forbids
ICMP but still
    +lets TCP traffic through).
    +
    +### telnet to TCP port
    +You can check if a given TCP port is reachable and listening using `telnet <host>
<port>`, such as
    +`telnet www.google.com 80`, which gives output like:
    +
    +```
    +    Trying 31.55.163.219...
    +    Connected to www.google.com.
    +    Escape character is '^]'.
    +```
    +
    +If this is very slow to respond, it can be caused by a firewall blocking access. If it
is fast, it could
    +be that the server is just not listening on that port.
    +
    +### DNS and routing
    +If using a hostname rather than IP, then is it resolving to a sensible IP?
    +
    +Is the route to the server sensible? (e.g. one can hit problems with proxy servers in
a corporate
    +network, or ISPs returning a default result for unknown hosts).
    +
    +The following commands can be useful:
    +
    +* `host` is a DNS lookup utility. e.g. `host www.google.com`.
    +* `dig` stands for “domain information groper”. e.g. `dig www.google.com`.
    +* `traceroute` prints the route that packets take to a network host. e.g. `traceroute
www.google.com`.
    +
    +## Service is listening
    +
    +### Service responds
    +Try connecting to the service from the VM iteslf. For example, `curl http://localhost:8080`
for a
    +web-service.
    +
    +On dev/test VMs, don’t be afraid to install the utilities you need such as `curl`,
`telnet`, `nc`,
    +etc. Cloud VMs often have a very cut-down set of packages installed. For example, execute
    +`sudo apt-get update; sudo apt-get install -y curl` or `sudo yum install -y curl`.
    +
    +### Listening on port
    +Check that the service is listening on the port, and on the correct NIC(s).
    +
    +Execute `netstat -antp` (or on OS X `netstat -antp TCP`) to list the TCP ports in use
(or use
    +`-anup` for UDP). You should expect to see the something like the output below for a
service.
    +
    +```
    +Proto Recv-Q Send-Q Local Address               Foreign Address             State   
   PID/Program name   
    +tcp        0      0 :::8080                     :::*                        LISTEN  
   8276/java           
    +```
    +
    +In this case a Java process with pid 8276 is listening on port 8080. The local address
`:::8080`
    +format means all NICs (in IPv6 address format). You may also see `0.0.0.0:8080` for IPv4
format.
    +If it says 127.0.0.1:8080 then your service will most likely not be reachable externally.
    +
    +Use `ip addr show` (or the obsolete `ifconfig -a`) to see the network interfaces on your
server.
    +
    +For `netstat`, run with `sudo` to see the pid for all listed ports.
    +
    +## Firewalls
    +On Linux, check if `iptables` is preventing the remote connection. On Windows, check
the Windows Firewall.
    +
    +If it is acceptable (e.g. it is not a server in production), try turning off the firewall
temporarily,
    +and testing connectivity again. Remember to re-enable it afterwards! On CentOS, this
is `sudo service
    +iptables stop`. On Ubuntu, use `sudo ufw disable`. On Windows, go to `Start` -> `Control
Panel` ->
    +`Windows Firewall`, and use the “Turn off Windows Firewall”.
    --- End diff --
    
    the "Turn off windows Firewall" what?


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---

Mime
View raw message