Cannot get grunt-php to launch browser and connect - gruntjs

When I use grunt-contrib-connect in the Gruntfile.js for my HTML files, and the task is called, the browser launches and connects with LiveReload without issue.
I am now trying to do the same with PHP files so I am using grunt-php. The author states that grunt-php is "pretty much a drop-in replacement for grunt-contrib-connect".
I have copied the options for grunt-contrib-connect to the grunt-php task, and added keepalive and open, but the browser does not get launched and no connection is made. The terminal however shows:
Running "php:livereload" (php) task
PHP 5.4.17 Development Server started at Mon Nov 11 15:56:04 2013
Listening on http://localhost:9000
Document root is /Users/fisu/Sites/generator-site-playground/dev
My task looks like:
php: {
options: {
keepalive: true,
open: true,
port: 9000,
livereload: 35729,
hostname: 'localhost',
base: 'dev'
},
livereload: {
options: {
open: 'http://localhost:9000',
base: 'dev'
}
}
}
I have tried different hostnames, but still the browser will not launch and connect. Am I missing an option?

It's not just you. The problem seems to be with this method: https://github.com/sindresorhus/grunt-php/blob/master/tasks/php.js#L51-L59 - open() never seems to get called because it's waiting for a HTTP 200 which it won't get unless a browser hits the server and requests something. At least that seems to be the case on my machine, I don't know how well tested that method is or anything. A temporary fix could be to move that call out of that method; go into the node_modules/grunt-php/tasks/ directory and edit the file like so:
(l49) // check when the server is ready. tried doing it by listening
// to the child process `data` event, but it's not triggered...
checkServer('http://' + host, function () {
if (!this.flags.keepalive && !options.keepalive) {
cb();
}
}.bind(this));
// open the browser straight away
if (options.open) {
open('http://' + host);
}
I've also filed an issue. https://github.com/sindresorhus/grunt-php/issues/14

Related

Why does Meteor Up (MUP) fail on authentication?

I am currently trying to deploy a Meteor project to an external server for the first time. The server is hosted by DigitalOcean, running ubuntu 16.04, and has an SSH key set up for password-free access.
The error I am getting from MUP is:
[159.203.165.13] - Setup Docker
events.js:165
throw er; // Unhandled 'error' event
^
Error: All configured authentication methods failed
at tryNextAuth (/usr/lib/node_modules/mup/node_modules/nodemiral/node_modules/ssh2/lib/client.js:290:17)
at SSH2Stream.onUSERAUTH_FAILURE (/usr/lib/node_modules/mup/node_modules/nodemiral/node_modules/ssh2/lib/client.js:469:5)
at SSH2Stream.emit (events.js:180:13)
at parsePacket (/usr/lib/node_modules/mup/node_modules/ssh2-streams/lib/ssh.js:3647:10)
at SSH2Stream._transform (/usr/lib/node_modules/mup/node_modules/ssh2-streams/lib/ssh.js:551:13)
at SSH2Stream.Transform._read (_stream_transform.js:185:10)
at SSH2Stream._read (/usr/lib/node_modules/mup/node_modules/ssh2-streams/lib/ssh.js:212:15)
at SSH2Stream.Transform._write (_stream_transform.js:173:12)
at doWrite (_stream_writable.js:410:12)
at writeOrBuffer (_stream_writable.js:396:5)
at SSH2Stream.Writable.write (_stream_writable.js:294:11)
at Socket.ondata (_stream_readable.js:651:20)
at Socket.emit (events.js:180:13)
at addChunk (_stream_readable.js:274:12)
at readableAddChunk (_stream_readable.js:261:11)
at Socket.Readable.push (_stream_readable.js:218:10)
Emitted 'error' event at:
at tryNextAuth (/usr/lib/node_modules/mup/node_modules/nodemiral/node_modules/ssh2/lib/client.js:292:12)
at SSH2Stream.onUSERAUTH_FAILURE (/usr/lib/node_modules/mup/node_modules/nodemiral/node_modules/ssh2/lib/client.js:469:5)
[... lines matching original stack trace ...]
at Socket.Readable.push (_stream_readable.js:218:10)
At this point I have tried several solutions involving the mup file as per other recommendations such as:
1) Adding in a password - Gives the exact same error as though the change didn't occur.
2) Adding in the same SSH key that I use for authentication to the server as per digital ocean - Says 'privateKey value does not contain a (valid) private key'. I have tried both the key that is used for authentication to the server and every other key I could find short of generating a new one just for Meteor's use.
3) Leaving both blank and allowing it to 'try' ssh-agent - pretends it doesn't know what ssh-agent is and throws an error saying the same thing as when I use a password.
I have looked through and followed the same instructions in the following article: http://meteortips.com/deployment-tutorial/digitalocean-part-1/
This article assumes that there are only two possible states. One being that an ssh key has NOT been used or set up so it needs to be generated. The second being that an ssh key exists and is set up exactly where they expect it. Unfortunately I seem to be in a different situation. I generated a key using putty prior to setting up the D.O server and created the droplet using that. After creation, the file did not exist. The only thing in the ~/.ssh/ directory was a single file named "authorized_keys" that held the key I would use to connect to the server. This file cannot be used, nor any file on the server in the other ssh key locations.I also tried copying over the file directly onto the server to no avail as well.
In some vain hope at finding a solution I also tried running these same commands in both the Meteor build bundle an the source code folder. Neither worked. I should mention that although this is the only article I still have open to try for a solution, I have tried every one I could find using MUP.
If anyone can point me in the right direction with this so I can stop flailing wildly in the dark I would be incredibly grateful.
Edit: As requested, below is the current mup.js file with removed credentials
module.exports = {
servers: {
one: {
// TODO: set host address, username, and authentication method
host: '111.111.111.11',
username: 'root',
// ssh-agent: '/home/Meteor/MeteorKey.pem'
pem: '~/.ssh/id_rsa.pub'
// password: 'password1'
// or neither for authenticate from ssh-agent
}
},
app: {
// TODO: change app name and path
name: 'app-name',
path: '../',
servers: {
one: {},
},
buildOptions: {
serverOnly: true,
},
env: {
// TODO: Change to your app's url
// If you are using ssl, it needs to start with https://
ROOT_URL: 'http://www.app-name.com',
MONGO_URL: 'mongodb://mongodb/meteor',
MONGO_OPLOG_URL: 'mongodb://mongodb/local',
},
docker: {
// change to 'abernix/meteord:base' if your app is using Meteor 1.4 - 1.5
image: 'abernix/meteord:node-8.4.0-base',
},
// Show progress bar while uploading bundle to server
// You might need to disable it on CI servers
enableUploadProgressBar: true
},
mongo: {
version: '3.4.1',
servers: {
one: {}
}
},
// (Optional)
// Use the proxy to setup ssl or to route requests to the correct
// app when there are several apps
// proxy: {
// domains: 'mywebsite.com,www.mywebsite.com',
The error message you are receiving:
Error: All configured authentication methods failed
Means that the SSH connection is failing. So the credentials you are using (pity you removed them from the config) are not working. Try using a command line ssh using these same credentials, and then trouble shoot that - once you can ssh into the server, then mup should be able to do it's work.
You can get more information out of ssh by specifying one or more -v parameters, eg:
ssh -v -v my_user#remote.com
and it will give you information about the authentication methods it is trying as it goes through them. This will help you narrow down the problem.

Mupx deployment with Meteor.js fails when "Installing Docker"

I have Ubuntu 14.04, developing on it and want to have a test server on the same computer. It is ran in Virtual Box.
So I followed all the steps on Github for Mupx setup and watched the video that Meteor.js guide told me to watch it. When I get to command:
mupx setup
it shows me the screen with the error:
nejc#nejc-vb:~/Meteor Projects/CSGO/CSGO-deploy$ mupx setup
Meteor Up: Production Quality Meteor Deployments
------------------------------------------------
Configuration file : mup.json
Settings file : settings.json
“ Checkout Kadira!
It's the best way to monitor performance of your app.
Visit: https://kadira.io/mup ”
Started TaskList: Setup (linux)
[my_public_IP] - Installing Docker
events.js:72
throw er; // Unhandled 'error' event
^
Error: Timed out while waiting for handshake
at null._onTimeout (/usr/local/lib/node_modules/mupx/node_modules/nodemiral/node_modules/ssh2/lib/client.js:138:17)
at Timer.listOnTimeout [as ontimeout] (timers.js:121:15)
My mup.json file looks like this:
{
// Server authentication info
"servers": [
{
"host": "my_public_IP",
"username": "nejc",
"password": "123456",
// or pem file (ssh based authentication)
// WARNING: Keys protected by a passphrase are not supported
//"pem": "~/.ssh/id_rsa"
// Also, for non-standard ssh port use this
//"sshOptions": { "port" : 49154 },
// server specific environment variables
"env": {}
}
],
// Install MongoDB on the server. Does not destroy the local MongoDB on future setups
"setupMongo": true,
// Application name (no spaces).
"appName": "CSGO",
// Location of app (local directory). This can reference '~' as the users home directory.
// i.e., "app": "~/Meteor Projects/CSGO",
// This is the same as the line below.
"app": "/home/nejc/Meteor Projects/CSGO",
// Configure environment
// ROOT_URL must be set to your correct domain (https or http)
"env": {
"PORT": 80,
"ROOT_URL": "http://my_public_IP"
},
// Meteor Up checks if the app comes online just after the deployment.
// Before mup checks that, it will wait for the number of seconds configured below.
"deployCheckWaitTime": 30,
// show a progress bar while uploading.
// Make it false when you deploy using a CI box.
"enableUploadProgressBar": true
}

Intern target QT webdriver on remote machine

I have installed intern on my local machine (192.168.1.50) and want to use the QT Browser webdriver on a remote machine (192.168.1.76). I've changed the intern.js and added the correct hostname as shown beneath:
tunnelOptions: {
hostname: '192.168.1.207:9517'
},
The qt browser is called as well:
environments: [
{ browserName: 'QTBrowser', version: '5.4' , platform: [ 'LINUX' ] }
],
Tunnel is set to NullTunnel.
When executing the tests, following error is shown
C:\intern-tutorial>intern-runner config=tests/intern.js Listening on 0.0.0.0:9000 Tunnel started Suite QTBrowser 5.4 on LINUX FAILED Error: [POST http://192.168.1.207:9517/wd/hub/session] connect ETIMEDOUT
192.168.1.207:4444 at Server.createSession at
at retry
at
at
runCallbacks
at at run
at
at
nextTickCallbackWith0Args at process._tickCallback
TOTAL: tested 0 platforms, 0/0 tests failed; fatal error occurred
Error: Run failed due to one or more suite errors at
emitLocalCoverage
at
finishSuite
at at
at
runCallbacks
at at run
at
at
nextTickCallbackWith0Args at process._tickCallback
I am able to access the remote webdriver myself via the browser using url http://192.168.1.76:9517/status
So the connection is correct, but intern does add the /wd/hub/session which actually isn't needed.
How can I get my intern from not doing this?
You can get past the 'wd/hub' issue by setting pathname on in the tunnel options:
tunnelOptions: {
pathname: '/',
hostname: '192.168.1.207',
port: 9517
}
However, there are currently a couple of incompatibilities between Intern and QtWebDriver. One is that QtWebDriver requires that headers use a specific capitalization scheme, like 'Content-Type'. However, the library Intern uses to handle its requests currently normalizes header names to lowercase. This should be fine, because headers are supposed to be case insensitive, but not everything follows the standard.
Another problem is that, unlike most other WebDriver implementations, QtWebDriver responds to a session creation call with a 303 response rather than a 200, and the redirect address is relative. While that should be fine, the version of the Leadfoot library used by Intern doesn't properly follow relative redirect addresses.
These issues should be fixed in a future version of Intern, but for the moment Intern doesn't work out-of-the-box with QtWebDriver.

Grunt connect or grunt serve?

I don't quite get the difference between the two. From the description, seems like both are for opening webserver.
If i used the grunt-serve plugin with the following configurations on my gruntfile.js
serve: {
options: {
port: 9000
}
}
I can open a webserver at the specified port, though i have to open the webserver manually at the browser (not sure how to make it open automatically on my default browser). The webserver is working fine, and can load JSON files without any problem.
However when i tried to do it with grunt connect plugin, with the following configurations
connect: {
server: {
options: {
port: 9000,
livereload: 35729,
hostname: 'localhost',
keepalive:true,
open:true
}
}
},
open: {
dev: {
url: 'http://localhost:<%= connect.server.options.port %>/index.html'
}
}
grunt.registerTask('serve', function (target) {
grunt.task.run([
'connect',
'open:dev'
]);
});
I could automatically opened a webserver at the specified port on my default browser, but the catch is, it couldn't load the JSON data like how grunt serve did.
I'd like to make the webserver works like Yeoman, where when running the command grunt serve, it would connect to the webserver and automatically open it on my default browser, and can load all my PHP/json files. Seems like grunt-serve plugin is the right plugin for this, but i'm sure grunt-connect can do the same thing as grunt-serve too.
according to https://github.com/gruntjs/grunt-contrib-connect the connect task makes the server available for a limited amount of time in order to run other tasks such as unit testing. Once the tasks are complete the server stops. As you have shown there is a keepalive option to prevent the server from stopping. Connect is also useful for connecting to resources on another domain such as a REST API. Typically this would be denied by the browser due to the same origin policy - see https://github.com/drewzboto/grunt-connect-proxy.
So for development I would use the standard pattern "grunt serve" and connect for testing and proxying to resources on another domain :-)

How to use grunt serve in Cloud9 IDE?

In my Gruntfile.js I have tried to do this:
connect: {
options: {
port: process.env.PORT,
hostname: process.env.IP,
livereload: 35729
}
}
I tried to run from Cloud 9 terminal and I get the following:
Running "serve" task
Running "concurrent:server" (concurrent) task
Running "connect:livereload" (connect) task Fatal error: Port 8080 is
already in use by another process.
Then I have changed my Gruntfile.js to the following:
connect: {
options: {
port: 9000,
hostname: process.env.IP,
livereload: 35729
}
}
From the terminal I get:
Running "serve" task
Running "concurrent:server" (concurrent) task
Running "connect:livereload" (connect) task Started connect web server
on http://0.0.0.0:9000
Running "watch" task Waiting...
But how do I access http://0.0.0.0:9000 from Cloud 9?
I have tried http://localhost:9000, http://127.0.0.1:9000, am I missing something here?
Apparently, you can actually get Livereload working on Cloud9 when using Apache as web-server, by proxying the websocket request to grunt-watch with "mod_proxy_wstunnel":
1) Add the following directive to /etc/apache2/mods-available/proxy_wstunnel.load
ProxyPass /livereload/ ws://127.0.0.1:35729/
2) Enable "mod_proxy_wstunnel" and it's dependency "mod_proxy"
ln -s /etc/apache2/mods-available/proxy_wstunnel.load /etc/apache2/mods-enabled/proxy_wstunnel.load
ln -s /etc/apache2/mods-available/proxy.load /etc/apache2/mods-enabled/proxy.load
3) Restart Apache
service apache2 restart
4) So far so good, now you must hardcode the websocket URL that Livereload will be using, by modifying the livereload.js script, in my particular case this was located at ~/myworkplace/grunt-contrib-watch/node_modules/tiny-lr/lib/public/livereload.js, you need to change the following line:
this._uri = "ws://" + this.options.host + ":" + this.options.port + "/livereload/";
to
this._uri = "ws://YOUR_WORK_PLACE.c9.io/livereload/";
5) Last but not least, you must reference the livereload.js script directly in your desired page, in my particular instance:
<script src="/ng-boilerplate/node_modules/grunt-contrib-watch/node_modules/tiny-lr/lib/public/livereload.js"></script>
Hope this might help someone and especially save some time :)
Update: On Cloud9, you can use ports 8080, 8081, and 8082 to make this work. For details and an example, you can look at Multiple Ports.
In Cloud9, port 8080 is the only externally accessible port, so please change 9000 to 8080.
The port is in use by another process, which should be stopped first. Use:
kill -9 $(lsof -i:8080 -t)
and restart grunt. That will work.
You can use any port, when it is used for local/loopback connections. From outside your workspace only one port is accessible (at this moment that is, C9 is considering multiple ports). I'm not too familiar with this livereload, sorry. It seems that grunt needs to spawn a browser as well? That will not run on C9.
But why would you not use the 'live preview' that Cloud9 provides?
Just open any html page, click Preview and select 'Live preview'.
All changes to css, html will be applied immediately in the preview frame.

Resources