Digital Ocean + Workflow app: Check Status

Digital Ocean + Workflow app: Check Status

Below is a workflow I put together to have the Workflow app check the status of specific Digital Ocean droplet.

Why would I need to do this? Occasionally I build Tensforflow models. With a 2GB RAM instance, I can do some data validation and tests on a small amount of data. When I need to do full throttle testing and training, I need to resize the droplet to a 16GB RAM droplet. Usually, I’ll kickoff the resize walking to my car on the way home. Then I start the test and train steps when I get home. When done, I shrink it all back. There are five workflows for this cycle:

  1. See if specified droplet is active (this post)
  2. Power off specified droplet (future post)
  3. Power on specified droplet (future post)
  4. Resize droplet to 16GM RAM size (future post)
  5. Resize droplet to 2GB RAM size (future post)

A few caveats. First, I’m not sharing this through the official Workflow gallery simply because it could be improved significantly, but it does what I need it to do well enough. Second, I prefer to build workflows that do one task and just one task. It’s a Unix thing (ignoring the ‘well’ part, though).

Some familiarity of creating workflows will help following these steps.

Step 1: Create a new ‘Today Widget’ workflow.

Step 2: Get or generate your Digital Ocean API key.

Step 3: Get your droplet id. The easiest way would be to pull it from the dashboard when looking at your droplet. So go on your dashboard, click on the droplet, look at the URL. It should be something like https://cloud.digitalocean.com/droplets/<droplet id>/graphs.

Step 4: Add the fields and set the variables as shown above.

  • Note: Set the URL variable to https://api.digitalocean.com/v2/droplet.

Step 5: Continue adding fields and setting variables as shown in the screenshot above.

Step 6: Continue adding fields and setting variables.

What you see when you run with workflow from the ‘Today Widget’ is below.

Alexa Skill Error: The remote endpoint could not be called, or the response it returned was invalid.

Alexa Skill Error: The remote endpoint could not be called, or the response it returned was invalid.

If you have tried building an Alexa Skill, you might have gotten the error “The remote endpoint could not be called, or the response it returned was invalid.”

For me, the error was related to uploading a zip file with the index.js and its node_modules libraries to the Lambda service. No matter what zip file I would upload, I’d get the following error:


{
"errorMessage": "Cannot find module '/var/task/index'",
"errorType": "Error",
"stackTrace": [
"Function.Module._load (module.js:276:25)",
"Module.require (module.js:353:17)",
"require (internal/module.js:12:17)"
]
}

It turns out when Amazon means zipping, they are expecting a different zip file structure than the one created by the default Mac OS X action of right click and compress the directory. When a Mac compresses a folder, the output is a folder with the files in it. Amazon wants it without that root folder.

Assume you have a source folder called TestSkill with index.js in it. Then you do a right click and Compress “TestSkill” on it. If you run this:

nali-iMacs-iMac:Downloads nali$ zipinfo TestSkill.zip | grep index.js |more

you’ll see this:

16-Dec-30 15:42 TestSkill/index.js

Pretty much what Amazon does not want. Instead, go into the folder and type this:

zip -r foobar.zip package.json *.js node_modules

You want the ‘-r’ so folders in node_modules get added to the zip file as well. Then let’s run the following command to look into the zip file:

nali-iMacs-iMac:Downloads nali$ zipinfo foobar.zip | grep index.js |more

Here is what you should see:

16-Dec-30 15:42 index.js

That is the structure Amazon wants.

Let’s turn this into an npm command. In your package.json, add a script:


{
"name": "foobar",
"version": "1.0.0",
"description": "",
"main": "index.js",
"scripts": {
"zip": "zip -r foobar.zip package.json *.js node_modules"
}
}

When in the folder, running ‘npm run zip’ will create a foobar.zip that can be successfully uploaded to Amazon’s Lambda service and the error “The remote endpoint could not be called, or the response it returned was invalid.” should go away.

Galaxy Nexus + Straight Talk + AT&T + MMS APN Settings

If you are using a Galaxy Nexus on Straight Talk with a AT&T provisioned SIM card and having issues with sending and receiving MMS, here are the APN settings that should work for you.

The Galaxy Nexus that I bought through Google Play had a Cingular APN already on it. Delete it. Or at least write down the settings just in case everything breaks on you. And then delete it.

Add a new APN with exactly these entries:

  • Name: straight talk (or whatever you want it to be)
  • APN: att.mvno
  • Proxy: proxy.mvno.tracfone.com
  • Port: 80
  • Username: Not set
  • Password: Not set
  • Server: Not set
  • MMSC: http://mmsc.cingular.com
  • MMS proxy: 66.209.11.33
  • MMS port: 80
  • MCC: 310
  • MNC: 410
  • Authentication type: Not set
  • APN type: Not set
  • APN protocol: IPv4
  • APN enable/disable: APN enabled
  • Bearer: Unspecified

That should be it.

Fixing Contact Form 7 Redirection Referrer Failure with IE

On a client WordPress site, we wanted to use Contact Form 7 to grab visitor information and redirect them to an inner page after submission. To make sure they filled out the submission form, the destination page checked the referrer to make sure they came from the form page. Now, there are other ways of doing this, like setting cookies, but this method was good enough for the client.

So this all worked in Chrome and Firefox, but not Internet Explorer.

Shocking.

The Contact Form 7 blog has instructions on how to redirect users to a different page after a successful submission. Under Additional Settings, simply do this:

on_sent_ok: “location=’http://www.fubar.com/thanks’;”

The on_sent_ok is a Javascript hook. Inside of scripts.js in the plugin, it eventually makes this call:

if (data.onSentOk) $.each(data.onSentOk, function(i, n) { eval(n) });

So “location=’http://www.fubar.com/thanks’;” gets evaluated by Javascript and the page redirects. Great.

On the destination page, we were checking the referrer to verify they were coming from the form, here is an example of how you could do it:

/* Set where they should be redirected to if user didn’t come from the form */$redirectString = “Location: “. get_site_url() . “/contactform”;

$referrer = $_SERVER[‘HTTP_REFERER’];

if ($referrer == NULL){ header($redirectString); exit();}else{ $domain = parse_url($referrer); $pos = strpos ($domain[“path”], “contactform”); if ($pos == false) { header($redirectString); exit(); }}

Now, your PHP should be cleaner, more error checking, check for XSS, don’t hard-code anything, etc, etc.

The problem was that the referrer would always be null when the visitor was using Internet Explorer. Referrer isn’t required to be set by the browser. Browsers won’t set it if you started out on a HTTPS site but click on a non-secure link.

And IE won’t set it on redirection, but it will set it if you click on a link. So if a fake a link click, IE will set the referrer.

Lets create a Javascript function to fake a link click. This code is stolen from Stack Overflow:

function goTo(url){ var a = document.createElement(“a”); if (a.click) { // HTML5 browsers and IE support click() on <a>, early FF does not. a.setAttribute(“href”, url); a.style.display = “none”; document.body.appendChild(a); a.click(); } else { // Early FF can, however, use this usual method // where IE cannot with secure links. window.location = url; }}

Ok. Remember, the Contact Form 7 redirection is a Javascript hook. So now we change the on_sent_ok to call the goTo function instead:

on_sent_ok: “goTo(‘http://www.fubar.com/thanks’);”

Bam. Done.