cles::blog

MariaDB は yum/dnf で自動的にアップデートされるようにしていたのですが、いつの間にか以下のようなエラーが出るようになってしまっていました。

どうやら GPG のキーが新しくなった^*1ようで、エラーを解消するにはこれをインストールしてやる必要があります。
MariaDB の公式マニュアル通りに以下を実行することで大丈夫でした。

• ^*1: GPG - MariaDB Knowledge Base

今度は Redmine + MariaDB を Docker 化していきます。

Redmine も MariaDB もどちらも公式のイメージを使います。

• redmine
• mariadb

今回の Redmine は要件として

• バージョンは 3.x 系統であること
• パスは /redmine で参照できること

というのがあるので、この部分についてはカスタマイズを行っています。

ファイルを配置したら以下のコマンドで起動できます。

起動ができたら http://hostname:3000/redmine/ でアクセスができるはずです。

† マイグレーション

既存の環境からの DB のマイグレーションについては、docker-compose exec redmine-db bashで MariaDB のコンテナに入り、MariaDB にデータをインポートすれば良いと思います。ファイルについては ./data ディレクトリ以下に必要なファイルをコピーすれば OK です。

† ファイル構成

今日は朝から php + MariaDB の環境で以下のエラーが発生して困ってしまいました。

Malformed communication packet というエラーは初めて見たかもしれません。

† MariaDB をダウングレードして暫定対処

原因としては MariaDB のバージョンアップに起因するようなので、以下のように MariaDB をダウングレードして暫定対象しました。

† 同じ話題が Stack Overflow にも

以下の Stack Overflow のエントリににもあるように、意外と同じところでハマった人は多いようです。
これを見ると PHP 7.3 では発生しないという話も出ているので PHP 7.1 と最新版の Maria DB の問題みたいですね。

• mysql - SQLSTATE[HY000]: General error: 1835 Malformed communication packet on LARAVEL - Stack Overflow

昔書いた Ruby のプログラムを CentOS 7 上で動かそうとしたのですが、MariaDB が 10.4 と比較的新しいバージョンだったので gem で mysql がインストールできないので困ってしまいました。

mysqlを見ると、最終アップデート日が 2013 年になっていて、最近はメンテナンスされていないようです。このまま粘っても解決の見込みも立たないので、mysql2 に移行してしまうことにしました。

† ソースの書き換えは大きく3箇所

基本的には以下の3箇所を変更してやれば、基本的な動作はするようです。
Date などの部分を自動的に cast する機能がついたようですが、これは :cast => false でオフにしてあります。

Laravel の Auth を使うとパスワードは DB にハッシュ化された状態で格納されます。
これはこれでセキュリティのために必要な挙動なので、これに文句を言うつもりはありません。

しかしながら、例えば管理者用のパスワードを忘れてしまい、DBを強制的に上書きしてログインしたいような場合、このハッシュがどのように作られているのか分からないとお手上げです。今日はまさにそんな状態に陥ってしまったので、解決方法を調べてみました。結論から言うと、以下のようにインタラクティブな php （artisan の tinker）を起動して、プログラムで DB を書き換えることができます。

これだと一撃で実行できるので、楽ちんです。

CentOS 7 に MariaDB をインストールして、Ruby の gem mysql2 実行したらエラーになってしまって困ってしまいました。

エラーメッセージを読む限りリンカのエラーのようなので、もう一度良く MariaDB のインストールを確認したら MariaDB-shared が入っていないのが原因だったようで、以下のコマンド１行で解決でした。MariaDB-devel だけでいけると思っていたのが、勘違いでしたね。

† CentOS 7 への MariaDB のインストール

ハマらないように次回からは以下のような感じでインストールすることにしようと思います。

先日、CentOS 7 の MariaDB を 10.3 にアップデートした話を書きましたが、10.1 → 10.3 の場合は 「A manual upgrade is required. 」と言われてしまうことが分かりました。
ちょうど yum でアップデートしようとすると、以下のようなエラーが出ます。

† 仕方がないのでマニュアルでアップデート

マニュアルでアップデートと言っても、やることは一旦アンインストールしてから、再インストールするだけです。
とりあえずエラーメッセージに従って、非互換な部分について確認します。
やはり主な問題は sql_mode の部分でしょうか。

• Upgrading from MariaDB 10.2 to MariaDB 10.3 - MariaDB Knowledge BaseUpgrading from MariaDB 10.1 to MariaDB 10.2 - MariaDB Knowledge Base

ちなみに yum remove しても /var/lib/mysql の下のデータファイルは消えませんが、念のため全データのダンプは取っておきます。
.conf は .rpmsave にリネームされてしまうので、特別な設定を入れている場合にはファイルを復元しておきます。

具体的には以下のような感じでしょうか。

CentOS 7 に載っている MariaDB 5.5 を 10.3 にアップデート^*1してみたので、その手順をメモ。

† アップデート自体は yum で OK

単に MariaDB を更新するだけならば、以下の手順ですんなりアップグレードできます。

† 問題になるのは SQL_MODE の STRICT_TRANS_TABLES

MariaDB （MySQL）は当初はいろいといい加減な部分がありましたが、最近は機能も増えていろいろと厳密になってきています。

特にバージョンアップの際に問題になると思われるのは、最近のバージョン（10.2.4 以降）の SQL_MODE にデフォルトで設定されている STRICT_TRANS_TABLES という指定です。これにより INSERT 文の書き方がいい加減な場合、これまで通っていた INSERT 文が通らなくなるという不具合が発生します。

以下が MariaDB 10.3 系でのデフォルトの SQL_MODE です。

ちなみに、この SQL_MODE は

• 10.1.7 以前は指定なし
• 10.1.7 は NO_ENGINE_SUBSTITUTION, NO_AUTO_CREATE_USER
• 10.2.4 以降は STRICT_TRANS_TABLES, ERROR_FOR_DIVISION_BY_ZERO, NO_AUTO_CREATE_USER, NO_ENGINE_SUBSTITUTION

という設定になっているようです。

とりあえず、デフォルトから STRICT_TRANS_TABLES を除くためには /etc/my.cnf.d/server.cnf の [mariadb] のセクションに以下を追加する必要があります。

変更後に MariaDB のデーモンを再起動させると、SQL_MODE が以下のようになっていることが確認できるはずです。

• ^*1: DB をアップデートするといろいろ動かなくなったりするのであまりやりたくなかったのですが、あるテーブルで Row size too large (> 8126) というエラーを吐くようになってしまったので、ROW_FORMAT=DYNAMIC に変換するための苦肉の策です。

PHP のファイルが静的解析したくなったので、ソースから AST を得る方法を調べてみました。
以前、Eclipse の ASTParser を使う話を書いたことがありましたが、それの PHP 版になります。

今回の作業にあたって、以下のスライドがとても参考になりました。

• PHP AST 徹底解説

PHP は 7 になってから内部的に AST が利用されているため、以前よりも AST を得るのは簡単になっています。
既に以下のような extension が提供されているので、いずれかをインストールすれば大丈夫です。

• nikic/php-ast: Extension exposing PHP 7 abstract syntax tree
• sgolemon/astkit: Parser kit for PHP7 ASTs

今回はマニュアルが充実している前者の nikic/php-ast を入れてみることにしました。
以下、構築メモになります。

Windows 10 のコンソール上から MySQL (MariaDB) にログインすると、文字コードをきちんと CP932 や SJIS にしていても日本語が文字化けすることがあるようです。

「することがある」とちょっとぼやかした書き方なのは、同じバージョンの Windows 10 と MySQL (MariaDB) の組み合わせで導入しても文字化けする端末とそうでない端末があり、僕が調べた限りでは再現条件が不明です。確認方法は簡単で、以下のようなテーブルを使わない SQL を打ち込んでみるだけです。嘘のような話ですが、こんな単純なSQLですら文字化けします。

いろいろ調べてみると Windows 10 1809 のコンソールには以下のバグがあり、今のところ Fix されていないようです。この指示に従って文字化けしているマシンの cmd.exe の設定をレガシーコンソールモードにしてみると、文字化けが解消することが確認できました。こういうのが OS のバグというのは困ったものです。

バージョン 1809 の OS 上でコンソール出力が正しく表示されない問題について

本問題は対象のバージョンの OS で導入された新しいコンソールの不具合に起因して発生しています。
出力ストリームに紐づけられた内部的なコードページ テーブルの初期化処理に不足があり、内部処理でマルチバイト文字を正しく認識することができず、正しくコンソール出力を行えない問題が発生します。