Category Archives: Uncategorized

Execution failed due to configuration error: API Gateway does not have permission to assume the provided role

When setting up a custom lambda authorizer in Amazon Web Service’s API Gateway you have the option to specify a role. If you run into permissions problem with this it is often due to a misconfigured “Trust Relationship” with the role it is assuming. You will see an error:

Execution failed due to configuration error: API Gateway does not have permission to assume the provided role
Execution failed due to configuration error: Authorizer error

To fix this go to the role in your IAM and select the “Trust Relationships” tab. From here edit the policy and for the Principal Service add in “” as seen below. This will grant the API Gateway the ability to assume roles to run your function in addition to the existing lambda permission.

"Version": "2012-10-17",
"Statement": [
"Effect": "Allow",
"Principal": {
"Service": ["",""]
"Action": "sts:AssumeRole"

Deploying first SailsJS node.js app to DigitalOcean using Dokku on Mac

Here’s a (very) quick and dirty overview of the steps. Follow everything below in order and you should have your node.js app (optionally running SailsJS) deployed on a dokku server on DigitalOcean within a few minutes.

Useful Links:
* Dokku –
* MariaDB plugin –

Set your SSH key into DigitalOcean if you haven’t already
* cat ~/.ssh/ | pbcopy
* Paste this key into digitalocean control panel.

Create Droplet

* Select 1GB
* San Fran
* Dokku
* Select your existing SSH key.
* Virtio + backups (maybe virt network if need to connect)

Set up Dokku

* Visit in your browser: http://YOUR-SERVER-IP/
* Submit, optionally setting the app URL to use subdomains. Most settings should default to correct at this point.

Initialize the app access dokku

* cat ~/.ssh/ | ssh [email protected] "sudo sshcommand acl-add dokku YOUR-APP-NAME"
** Note that if instead of YOUR-APP-NAME you put a full domain it will use that as the URL instead of setting up a subdomain. Eg instead of dustinbolton-api

Configuring local app

Initialize the local repo if you have not already
* git init && git add -A && git commit -m "Initial commit"

Assign production (or staging) destination:
* git remote add production [email protected]:YOUR-APP-NAME

Create file to tell server what to run on deployment:
* touch Procfile && open Procfile
* Add the following into this new file & save:
* web: sails lift
** For non-sails framework, instead of “sails lift” this would be “node app.js”.

Deploy & launch the app

* git push -u production master

If you need to manually re-run the app or see the output of the run attempt (such as to troubleshoot):
* ssh [email protected]
cd /home/dokku/YOUR-APP-NAME
dokku run YOUR-APP-NAME sails lift
(or instead of “sails lift”, “node app.js”)

Adapted from the guide at:

MariaDB (mysql drop-in alternative) plugin:

cd /var/lib/dokku/plugins
git clone mariadb
#git clone user-env-compile
dokku plugins-install

Create Database Instance

dokku mariadb:create YOUR-APP-NAME
* This creates the mariadb instance and links it to your app automatically since the name matches. The database name is “db” by default.

You can use the credentials displayed or access them via environmental variables such by: process.env.DB_USER

Setting Custom Environment Variables

Database environment variables should automatically exist but I have seen them drop off. I have not found the cause yet and have decided to manually set the one(s) I need for the time being.
dokku config:set YOUR-APP-NAME DATABASE_URL=whateverhere

If you ever need to restart your app. Only change “YOUR-APP-NAME”:

docker restart `cat /home/dokku/YOUR-APP-NAME/CONTAINER`

Error: ER_NO_DB_ERROR: No database selected

For me this was caused by using the adapter type of ‘sails-mysql’ as the value when setting up the adapter instead of my custom name I made for it matching the definition later in the adapters.js file.

Logic error in mySQL ORM.
{ [Error: ER_NO_DB_ERROR: No database selected] code: ‘ER_NO_DB_ERROR’, index: 0 }
error: Hook failed to load: orm (Error: ER_NO_DB_ERROR: No database selected)

FuelPHP unexpectedly returns Arr instead of data accessing REST controller with no format specified

When working with the REST Controller in FuelPHP and accessing it from your browser you see “Arr” when a format is not specified in the URL instead of the expected data in your default format. This is because of a setting in the rest.php config file (fuel/core/config/rest.php OR /fuel/app/config/rest.php).


<pre>’ignore_http_accept’ => false,</pre>


<pre>’ignore_http_accept’ => true,</pre>


This is faster and will make your default the default format as expected.  If the client needs the data in another format they can specify it in the URL.

WordPress + Xampp on Mac Update Permissions Problem

If you are running WordPress on OS X using XAMPP for local development then you likely have tried to upload core or a plugin and encountered the following error while prompted for FTP Connect Information:

To perform the requested action, WordPress needs to access your web server.

This is because by default XAMPP runs as the user `nobody` on Mac and this causes some permissions issues. Additionally WordPress prior to upgrading writes a file to the system and then checks to see which user wrote the file. If this file does not match the user running PHP it will refuse to upgrade, even if write permissions existed. chmod 777 is not sufficient to get past this; you must have the correct user as well. I don’t know why they did this and if there’s a technical reason for it, but it’s annoying.

The solution: Edit your httpd.conf to run as your username for the user and staff for the group.

Open httpd.conf in TextEdit:

sudo open -e /Applications/XAMPP/xamppfiles/etc/httpd.conf


User nobody
Group nogroup


User your_mac_username
Group staff

Restart Xampp and this should correct the problem; you can verify it worked by running in a .php file.

If you still encounter issues you can check a couple of other things. First verify ownership (most likely problem):

sudo chown -R your_mac_username:staff /path_to_webroot/www/

Next confirm permissions (you can change 777 if you need higher security):

sudo chmod -R 777 /path_to_webroot/www/

Email notification to all thread commenters on reply in WordPress P2 theme

The following code added to the bottom of P2’s functions.php will allow P2 to send email notifications to all other responders in a comments thread.

// PluginBuddy Email Notification Patch for P2
// by Dustin Bolton on September 10, 2010.
add_action( 'comment_post', 'email_notification' );
function email_notification( $comment_id ) {
	$emails = array();
	$comment = get_comment( $comment_id, ARRAY_A );
	// Get emails of all responders.
	$comments = get_comments( 'post_id=' . $comment['comment_post_ID'] );
	foreach( $comments as $this_comment ) {
		if ( $this_comment->comment_author_email != $comment['comment_author_email'] ) { // Only add emails that are not this comment poster.
			array_push( $emails, $this_comment->comment_author_email );
	$emails = array_unique( $emails ); // Strip all duplicate email addresses.
	// Get email address of thread starter to strip them from receiving replies since that is automatic in P2.
	$original_post = get_post( $comment['comment_post_ID'], ARRAY_A );
	$original_poster = get_userdata( $original_post['post_author'] );
	$emails = array_diff( $emails, array( $original_poster->user_email ) ); // Remove from array.
	// Send emails.
	foreach( $emails as $this_email ) {
		wp_mail( $this_email, 'P2 thread updated!', "There has been an update to a thread you posted in by " . $comment['comment_author'] . " on " . $comment['comment_date'] . ":\n\n" . $comment['comment_content'] );
// End PluginBuddy Email Notification Patch.


Comment posted by macemoneta over at Slashdot: “The problem for many people is the incongruity between how they were raised and reality. People are generally raised to believe that people are good, that there are norms of behavior, there is justice in the world, authority figures can be trusted, things happen for reason and are overseen by an omnipotent deity. As we grow up, we learn that these are simply convenient lies that define our society.

When presented with conflicting visual evidence, we can be shocked and damaged – our world view is broken. Some go into denial (classifying the content as depravity), and some go into depression (recognizing that society is simply a veneer). Education and experience over time tends to break these falsehoods more gently, incrementally.”

Disable post revisions in WordPress 3.0

I recently had a customer that had ~70,000 revisions on posts on his WordPress site. This caused his database to skyrocket to 400mb+. I discovered the cause of these revisions to be the plugin FeedWordpress. FeedWordPress was triggering WordPress to create massive amounts of revisions. Because of this the plugin I wrote, BackupBuddy, could not back up his site without running into PHP timeout issues. In this post is the solution I used to resolve this problem.

In the root directory of your WordPress installation, open wp-config.php in a text editor and insert the following line on a new line somewhere between the top ( looks like ) lines of the file:

define('WP_POST_REVISIONS', false);

Running the following SQL (change wp_ to your prefix) in phpmyadmin will clear out all revisions:

DELETE a,b,c
FROM wp_posts a
LEFT JOIN wp_term_relationships b ON (a.ID = b.object_id)
LEFT JOIN wp_postmeta c ON (a.ID = c.post_id)
WHERE a.post_type = 'revision';

Finally, run the following SQL query to optimize (clean up) your posts table: