目覚めよ、Concrete5

mysqlの設定でもかなり苦労させられた。結構考えられ得ることをやるだけやったのにこれだもんね、結構ショック。
やったことは、

mysql起動（当たり前）
mysqlのポートと、awsのセキュリティグループのRDS用の指定ポートが同一か確認
grant構文によるデータベースに対する全権付与
文字セットをutf8にしておく

こんだけ抑えておけば、大丈夫だろうと思ったら、タイトルのエラーがドバーーーーーン！！まじF●ck。空気読め。そこは成功して、俺、少しできるようになったかなくらいの気持ちを持たせてくれ。

・・・で、なんなのこれ。

SQLモードの制約が原因

公式では、

STRICT_TRANS_TABLES は、トランザクションストレージエンジンに対して厳密モードを有効にし、非トランザクションエンジンに対してもある程度有効にします。これは、次のように動作します。

トランザクションストレージエンジンの場合、ステートメント内で生じる不良データ値は、ステートメントの実行中止やロールバックを引き起こします。

非トランザクションストレージエンジンの場合、ステートメントは、挿入または更新される最初の行でエラーが発生した場合に中止します。(トランザクションテーブルの場合と同じように、最初の行でエラーが生じた場合、ステートメントを中止して、テーブルを変更しないままにしておくことができます。)2 行以降でエラーが生じた場合、最初の行によってテーブルがすでに変更されているため、ステートメントは中止しません。代わりに、不良データ値が調整され、この結果、エラーではなく警告が発せられます。言い換えると、STRICT_TRANS_TABLES を使用すると、テーブルを変更せずに行える場合は、間違った値によって、MySQL はこれまでに行われたすべての更新をロールバックします。ただし、いったんテーブルが変更されると、それ以降に生じるエラーは調整や警告になります。

変なデータを入れようとしたらその時点でデータ更新を打ち切るのがトランザクションですが、非トランザクションでもこのSTRICT_TRANS_TABLESである程度トランザクション機能を使えるようにしてくれる、ということでしょうか。つまり、非トランザクションエンジンでも、これを使えば、データ挿入や更新の途中でエラーがあっても挿入や更新前のデータベースへとロールバックしてくれるということですね。
ストレージエンジンについては、こちらに調べた記事を書きましたので、よろしければどうぞ。
トランザクションストレージエンジンを調べてたらアバウトにmysqlを全部知ることになった話

解決策

concrete5が入れたいデータなんだから、不良データじゃないはずなので、入れさせてほしい（意味深）。
というわけで。

sqlモードをmysqlのコンソールから確認してみると、

mysql> SELECT @@GLOBAL.sql_mode;
+--------------------------------------------+
| @@GLOBAL.sql_mode                          |
+--------------------------------------------+
| STRICT_TRANS_TABLES,NO_ENGINE_SUBSTITUTION |
+--------------------------------------------+

いますね、STRICT_TRANS_TABLESが。それじゃ、無効化させます。

mysql> SET GLOBAL sql_mode = 'NO_ENGINE_SUBSTITUTION';

もう一度確認してみます。

mysql> SELECT @@GLOBAL.sql_mode;
+------------------------+
| @@GLOBAL.sql_mode      |
+------------------------+
| NO_ENGINE_SUBSTITUTION |
+------------------------+

OK、これでconcrete5が動きました。まあ、この後mb_stringモジュールがなくてホーム画面が出てこなかったので、またrpmを探す旅が待っていたわけですが、前回の記事でrpmに関してはよっく分かったので、問題なしでした。

環境に必要なモノを手に入れるために必要なrpmの知識はこちらにまとめてあります。
検証環境を構築する上で知ったこと
 検証環境を構築する上で知ったことパート2