Testing Access to Google Bigtable
This is a minimal PHP script that’s useful for verifying connectivity and permissions to read data from a Google Bigtable instance. Unlike some of the sparse examples in Google’s PHP SDK, this script will work for any table, and you don’t need to know anything about the structure of the table. This script tests the critical elements that need to work together to enable Bigtable access:
Credential file GRPC extension for PHP Protobuf extension for PHP Scopes enabled on Compute Engine instances
Nginx default user changed in RedHat/CentOS package nginx-1.16.1-1.el7
The latest Nginx rpm (nginx-1.16.1-1.el7) from EPEL for CentOS/Redhat is a fairly major update, from version 1.12 to 1.16, and includes some very important fixes to address multiple CVEs. There is another small but critical change in the latest RPM that isn’t mentioned in the bug report. RedHat had configured nginx to run as user “apache” in past releases, but in the EPEL release on 19 October 2019, the configuration was changed to run as user “nginx”. If you ran “yum upgrade” recently (which you really need to do on a regular basis) on any system with nginx installed, you probably have a system that is affected.
Configuring Laravel/Lumen applications to connect to SQL database sockets
The Laravel/Lumen framework documentation does not explain how to connect an application to a database using UNIX sockets instead of a TCP-based network connection. I recently had to configure the Polr URL shortener (built on the Lumen microframework by Laravel) to connect to Google Cloud SQL with a UNIX socket. Since all of Polr’s configuration takes place in the .env file, and there is no environment variable that’s specific to database sockets, this took some research. I finally found the answer in an obscure StackOverflow response. Previous TCP connection: [code] DB_HOST=some-server-name DB_PORT=3306 [/code] Socket-based SQL connection: [code] DB_HOST=localhost;unix_socket=/cloudsql/cloud-project-name:us-east1:sql-instance-name [/code] This approach will work with any UNIX socket; you just need to give it the absolute path to the socket.
General error: 2006 MySQL server has gone away
“MySQL Server has gone away” is a cryptic error that can be hard to troubleshoot (look at all the various responses on Stack Overflow!) Many problems can cause this error; I would like to document one specific case. In this example, the client is a PHP app using the Phalcon framework:
[Mon, 09 Apr 18 03:34:08 -0400][ERROR] SQLSTATE[HY000]: General error: 2006 MySQL server has gone away
exception 'PDOException' with message 'SQLSTATE[HY000]: General error: 2006 MySQL server has gone away' in /path/to/ModelBase.php:
Stack trace:
#0 [internal function]: PDOStatement->execute()
...
#17 {main}This error can be tricky to troubleshoot. I looked in three logs: