Hosting

Invalid value for field resource.machineType in Google Compute Engine

Currently I am working on a light-weight PHP class which should help me to create, list and delete VM instances on Googles Compute Engine. While writing the class, I came across few issue I would like to share with you. In the following example I tried to create a micro instance, because didn’t need much computing power. As you probably know, here is how you can select the machine type via dashboard.

When I tried to create a micro instance via PHP API with the correct Machine Type I received the following error message.

Fatal error: Uncaught Google_Service_Exception: { "error": { "errors": [ { "domain": "global", "reason": "invalid", "message": "Invalid value for field 'resource.machineType': 'f1-micro'. The URL is malformed." } ], "code": 400, "message": "Invalid value for field 'resource.machineType': 'f1-micro'. The URL is malformed." } }

Fatal error: Uncaught Google_Service_Exception: { "error": { "errors": [ { "domain": "global", "reason": "invalid", "message": "Invalid value for field 'resource.machineType': 'f1-micro'. The URL is malformed." } ], "code": 400, "message": "Invalid value for field 'resource.machineType': 'f1-micro'. The URL is malformed." } }

Here is a part of a PHP file I am using for API connection tests.

<?php

// Load https://github.com/googleapis/google-api-php-client
require 'vendor/autoload.php';
...

// Authenticate
$client = new Google_Client();
...

// Connect to Compute Engine Service
$computeService = new Google_Service_Compute($client);
...

// Update placeholder values
$project = 'project-abc';
$zone = 'us-east1-b';
$instance = 'demo-project';
$machineType = 'f1-micro';

// Create instance inside project-abc
$instanceName = 'my-first-instance';
$newInstance = new Google_Service_Compute_Instance();
$newInstance->setName($instanceName);
$newInstance->setMachineType($machineType);

$response = $computeService->instances->insert($project, $zone, $instanceName);

<?php

// Load https://github.com/googleapis/google-api-php-client

require 'vendor/autoload.php';

...

// Authenticate

$client = new Google_Client();

...

// Connect to Compute Engine Service

$computeService = new Google_Service_Compute($client);

...

// Update placeholder values

$project = 'project-abc';

$zone = 'us-east1-b';

$instance = 'demo-project';

$machineType = 'f1-micro';

// Create instance inside project-abc

$instanceName = 'my-first-instance';

$newInstance = new Google_Service_Compute_Instance();

$newInstance->setName($instanceName);

$newInstance->setMachineType($machineType);

$response = $computeService->instances->insert($project, $zone, $instanceName);

As you can see, I set a string f1-micro which is obviously not valid. I double-checked the API guides and found this URL.

https://www.googleapis.com/compute/v1/projects/{project}/zones/{zone}/machineTypes/{machineType}

1	https://www.googleapis.com/compute/v1/projects/{project}/zones/{zone}/machineTypes/{machineType}

So I defined the value for the machine type as follows which has fixed the invalid value for field resource.machineType.

$machineType = sprintf('https://www.googleapis.com/compute/v1/projects/%s/zones/%s/machineTypes/%s', $project, $zone, $type);
$newInstance->setMachineType($machineType);

1 2	$machineType = sprintf('https://www.googleapis.com/compute/v1/projects/%s/zones/%s/machineTypes/%s', $project, $zone, $type); $newInstance->setMachineType($machineType);

AWS RDS – You Need (at least one of) The SUPER Privilege(s)

Today I had the opportunity to move a local Magento database to an Amazon RDS. Based on the well-documented article Creating a DB Instance Running the MySQL Database Engine I was optimistic to finish the migration pretty soon. But as you know, there is always something that goes wrong.

After creating the database instance class ( db.m3.large ) I have decided to proceed with some test imports before I change any database credentials in Magento.

$ mysql -h customer.1xcpdspit6hz.ap-southeast-2.rds.amazonaws.com -u customer -p
$ source ~/project_20161014_1135.sql

1 2	$ mysql -h customer.1xcpdspit6hz.ap-southeast-2.rds.amazonaws.com -u customer -p $ source ~/project_20161014_1135.sql

Good decision because the first import didn’t run through.

ERROR 1419 (HY000): You do not have the SUPER privilege and binary logging is enabled (you *might* want to use the less safe log_bin_trust_function_creators variable)
Query OK, 0 rows affected (0.01 sec)

1 2	ERROR 1419 (HY000): You do not have the SUPER privilege and binary logging is enabled (you might want to use the less safe log_bin_trust_function_creators variable) Query OK, 0 rows affected (0.01 sec)

I was able to fix the problem by adding the missing parameter log_bin_trust_function_creators as explained here. Before the next import I had to delete the database and create a new one.

ERROR 1227 (42000): Access denied; you need (at least one of) the SUPER privilege(s) for this operation
Query OK, 0 rows affected (0.00 sec)

1 2	ERROR 1227 (42000): Access denied; you need (at least one of) the SUPER privilege(s) for this operation Query OK, 0 rows affected (0.00 sec)

Unfortunately there was another problem with a DEFINER which tried to create a trigger as a different user. On Amazon RDS only a user with SUPER privileges can do that. Therefore, I had to remove the DEFINER from the MySQL schema you see below.

$ sed -i 's/DEFINER=[^*]*\*/\*/g' project_20161014_1135_toimport.sql

1	$ sed -i 's/DEFINER=[^]\/\/g' project_20161014_1135_toimport.sql

That’s it. Now I was able to import my DB on Amazon RDS without errors.

Nginx Docker Container and getpwnam(“www-data”) problem

I am using nginx:1.10.1-alpine to run Nginx as a docker container. Today I have replaced the Nginx container and always got the status Restarting (1) Less than a second ago after starting the container.

CONTAINER ID        IMAGE                          COMMAND                  CREATED             STATUS                                  PORTS                         NAMES
aadc6336a026        docker_nginx                   "nginx -g 'daemon off"   10 minutes ago      Restarting (1) Less than a second ago   0.0.0.0:80->80/tcp, 443/tcp   nginx

1 2	CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES aadc6336a026 docker_nginx "nginx -g 'daemon off" 10 minutes ago Restarting (1) Less than a second ago 0.0.0.0:80->80/tcp, 443/tcp nginx

With the command docker logs nginx I got the following error logs.

2016/09/10 22:58:49 [emerg] 1#1: getpwnam("www-data") failed in /etc/nginx/nginx.conf:1
nginx: [emerg] getpwnam("www-data") failed in /etc/nginx/nginx.conf:1
2016/09/10 22:58:50 [emerg] 1#1: getpwnam("www-data") failed in /etc/nginx/nginx.conf:1
nginx: [emerg] getpwnam("www-data") failed in /etc/nginx/nginx.conf:1
2016/09/10 22:58:50 [emerg] 1#1: getpwnam("www-data") failed in /etc/nginx/nginx.conf:1
nginx: [emerg] getpwnam("www-data") failed in /etc/nginx/nginx.conf:1

2016/09/10 22:58:49 [emerg] 1#1: getpwnam("www-data") failed in /etc/nginx/nginx.conf:1

nginx: [emerg] getpwnam("www-data") failed in /etc/nginx/nginx.conf:1

2016/09/10 22:58:50 [emerg] 1#1: getpwnam("www-data") failed in /etc/nginx/nginx.conf:1

nginx: [emerg] getpwnam("www-data") failed in /etc/nginx/nginx.conf:1

2016/09/10 22:58:50 [emerg] 1#1: getpwnam("www-data") failed in /etc/nginx/nginx.conf:1

nginx: [emerg] getpwnam("www-data") failed in /etc/nginx/nginx.conf:1

The error message basically means that the user www-data which I have defined in /etc/nginx/nginx.conf doesn’t exists in /etc/passwd. That makes sense, because nginx:1.10.1-alpine comes with a minimal setup. I my case I need the user www-data for other linked php-fpm containers. To fix the problem I just added the missing user during the container build.

FROM nginx:1.10.1-alpine
RUN addgroup -g 1000 -S www-data \
 && adduser -u 1000 -D -S -G www-data www-data

FROM nginx:1.10.1-alpine

RUN addgroup -g 1000 -S www-data \

&& adduser -u 1000 -D -S -G www-data www-data

Voilà.

Building nginx
Step 1 : FROM nginx:1.10.1-alpine
 ---> c07e2bb859e2
Step 2 : RUN addgroup -g 1000 -S www-data         && adduser -u 1000 -D -S -G www-data www-data
 ---> Running in c1cd75c7dc52
 ---> 83528539d9c9
Removing intermediate container c1cd75c7dc52
Successfully built 83528539d9c9

Building nginx

Step 1 : FROM nginx:1.10.1-alpine

---> c07e2bb859e2

Step 2 : RUN addgroup -g 1000 -S www-data && adduser -u 1000 -D -S -G www-data www-data

---> Running in c1cd75c7dc52

---> 83528539d9c9

Removing intermediate container c1cd75c7dc52

Successfully built 83528539d9c9

Nginx and Cached CSS / JS files

Yesterday I had a pretty hard time with cached CSS / JS files on my developer environment. I supposed to review layout changes, but I always got the old CSS files. I have spent about 2 hours to find the reason. At the end the solution was to turn off the syscall sendfile in my virtual host configuration.

server {

    listen 80;

    .....

    location ~\.(css|js)$ {
        sendfile off;
    }
}

server {

listen 80;

.....

location ~\.(css|js)$ {

sendfile off;

}

If you use Nginx as a reverse proxy to serve pages from an application server, you can leave sendfile turned off.

Reload Nginx Inside Docker Container

I am using docker for Nginx which is running with multiple virtual hosts. Sometimes I have to reload my updated nginx configurations, but I don’t want restart the container each time. Here is how you can reload your nginx without any downtime and without interrupting any connections.

1. Find your container name

Use docker ps to find your nginx container.

2. Reload Nginx

With docker exec -it {container_name} {command} you can directly access your container and execute commands. In my case the name of the container is nginx-server.

$ docker exec -it nginx-server nginx -s reload
2016/08/18 09:52:38 [notice] 19#19: signal process started

1 2	$ docker exec -it nginx-server nginx -s reload 2016/08/18 09:52:38 [notice] 19#19: signal process started