Browsersync on a Digitalocean Droplet (with Processwire + gulp)

[phil_s]

Hi guys,

I have replicated my local gulp workflow on a digitalocean droplet,
and I can't seem to get browsersync to work. Has anybody tried this before and can chime in? 

My PW install is at http://clients.domain.com/clientname/
In there, my folder setup looks like this, so gulp runs from the /templates folder:

clients
+ public
  + clientname
    + site
      + templates
        + node_modules
        + gulpfile.js
        + package.json
        + src/
        + assets/

 

I tried all kinds of shenanigans including leaving out any proxy settings,
setting a proxy, different port and fiddling with the scriptPath options...

gulp.task('browser-sync', function(){
  browserSync.init({
	scriptPath: function (path, port, options) {
		return options.getIn(['urls', 'external']) + path;
	}
  });
});

// or this:
gulp.task('browser-sync', function(){
  browserSync.init({
		host: 'XX.XX.XX.XX',
        open: 'external',
        proxy: 'clients.domain.com/clientname/'
  });
});

Gulp and browsersync is running fine it seems, only the integration is tricky: I get timeouts or 404s with the auto generated snippet (apparently the relevant files are created dynamically on runtime, but I can't access or see them at the default paths) 

I'm probably missing something very obvious, can't be this hard, can it?

 

- - -

EDIT:
Could this simply be a firewall issue?

- entering the IP @ Browsersync's default port (3000) doesn't load anything
- I used serverpilot to configure the machine so the firewall is set up with very few ports open, and obviously 3000/3001 is not one of them.

I guess I'm off to find out if opening one of these ports is a good idea or not

- - -

EDIT 2: When running netstat -peanut I can see that the relevant ports are actually listening, so this is not a firewall issue after after all?

tcp6       0      0 :::3002                 :::*                    LISTEN      1000       184931      17882/gulp      
tcp6       0      0 :::3003                 :::*                    LISTEN      1000       184942      17882/gulp  

 

[Francesco Bortolussi]

Hi.

If you have ssh access to the server:

1.- Try telnet from local console: like

telnet 127.0.0.1:3000

If locally you get some response from the service, then is a firewall problem(It block'c communication to the outside).

 

2.- Look at the protocol, maybe is only open for tcp6 connections and firewall block's tcp4 connections

If you're using Linux try:

# iptables -L -n | grep :3000

It should give you a list of rules in INPUT, OUTPUT that filter all packets for that port.

Look at the first line:

"Chain INPUT (policy ACCEPT)"

If it says ACCEPT, all connection's are by default allowed.
If it says DROP the policy is to deny all incoming connections.

Hope this could help.

 

[phil_s]

Quote

3 hours ago, Francesco Bortolussi said:

1.- Try telnet from local console: like

telnet 127.0.0.1:3000

If locally you get some response from the service, then is a firewall problem(It block'c communication to the outside).

This works indeed! (telnet localhost 3000 connects..)

 

3 hours ago, Francesco Bortolussi said:

2.- Look at the protocol, maybe is only open for tcp6 connections and firewall block's tcp4 connections

If you're using Linux try:

# iptables -L -n | grep :3000

 

Hum.. # iptables -L -n works, but there is no listing for a port 3000. So it should not be blocked?
I also tried: curl -s localhost:3000 >/dev/null && echo Connected. || echo Fail. which results in "connected"

Thanks Francesco!

[Francesco Bortolussi]

Hi.

If there's no iptable rule for port 3000 is because is not blocked (or allowed in case of a DROP policy).

Check iptables INPUT and OUTPUT chain's policy to see if they are in ACCEPT or DROP. If is ACCEPT forget about firewall that's not the problem.

 

The result's of your positive connection via telnet could be  because the address 127.0.0.1 is mapped to ::1 ip v6 address. (In the /etc/hosts file). And as you wrote in your initial post, there is a socket listening in tcp6 local address.

Check that the browsersync service is listening in ip v4 protocol (you should see tcp instead of tcp6).

Check with:

 

# netstat -putan | grep 3000

 

You should see: tcp as protocol (not tcp6) and the Real IP as address (The one you use to connect from yout PC to the server).

If you not see this, check browsersync config and be shure you are using the right address.

 

Have a nice day.

[Doug G]

What os are you using?  If you have a recent centos/redhat/fedora droplet check firewalld to see if ports are open.
 

firewall-cmd --list-ports

(and --list-services) to check what ports are open.