phpMyAdmin や WordPress から MariaDB にセキュア接続する。

 さて、「MariaDB でセキュア接続」が出来たので、自鯖の SQL サーバがセキュアになった。というわけで、 phpMyAdmin と WordPress の設定をそれに合わせて変更する。
 各バージョンは MariaDB 10.2.9 win 32-bit、 phpMyAdmin 4.7.4、 WordPress 4.8.2 で、サーバ機は Windows 7 32-bit HE SP1 である。
“phpMyAdmin や WordPress から MariaDB にセキュア接続する。” の続きを読む

MariaDB でセキュア接続。

 ここのところ MariaDB で セキュアな接続を使おうと一生懸命やっていた。はじめる前に, SHOW VARIABLES LIKE 'have_ssl'; とやったら下記の結果になった:

+---------------+----------+
| Variable_name | Value    |
+---------------+----------+
| have_ssl      | DISABLED |
+---------------+----------+

 DISABLED というのはコンパイル時に TLS サポートはされているが,現時点で有効ではないよということなので,ちゃんと設定すればうちの SQL サーバでセキュアな接続が出来るわけだ。 “MariaDB でセキュア接続。” の続きを読む

MariaDB10.2に移行。

 昨日,くりくりさんがツイートで MariaDB 10.2 が GA になったと教えてくださったので,昨夜のうちに, MariaDB 10.2.6 に移行した。

 アップグレードに関しては,特に問題なしだった。やり方は,「MariaDB10.0.11へアップデート」とを同じ。 “MariaDB10.2に移行。” の続きを読む

phpMyAdmin4.6.6 にアップデートした。

本日, phpMyAdmin4.6.6 にアップデートしたら,ログイン時に “OpenSSL error: error:0607A082:digital envelope routines:EVP_CIPHER_CTX_set_key_length:invalid key length” というのが出るようになった。
 おそらく, 👉 $cfg[‘Servers’][$i][‘ssl_verify’] のせいではないかと思うのだが……。

 説明部分に, “Disabling the certificate verification defeats purpose of using SSL. This will make the connection vulnerable to man in the middle attacks.” というのが入っているが,自鯖の SQL server と phpMyAdmin は NAT ルータ内にあるし,ユーザも私だけなので,一時しのぎとして, config.inc.php に下記を付け加えて回避することにした。

$cfg['Servers'][$i]['ssl_verify'] = false;

覚え書-#31。

投稿アップデート情報  追記(7/21)

 チョコチョコとサーバソフトのアップデートをした。

  1. ActivePerl-5.22.1.2201 から ActivePerl-5.24.0.2400 に。
    ActivePerl-5.22.1.2201-MSWin32-x86-64int-299574.msi をインストールしてたんだが,今回から msi 形式がなくなっていたので, ActivePerl-5.24.0.2400-MSWin32-x86-64int-300558.exe をインストールしようとしたのだが,下記のエラーが出てうまくいかなかった。

    Error 1723. There is a problem with this Windows Installer package. A DLL required for this install to complete could not be run. Contact your support personnel or package vendor.  Action CheckInstallDir, entry: CheckInstallDirNoBox, library: C:\Users\UserID\AppData\Local\Temp\MSIXXXX.tmp

    “覚え書-#31。” の続きを読む

覚え書-#26。

 HTTP/2 にかまけているけれども, MariaDB 10.1.8 のインストールについても書いておこう。アップデートではないよ。 PHP5.6.15,phpMyAdmin4.5.1,ActivePerl-5.20.2.2002 も昨日まとめて面倒見たので,それについても触れておく。 “覚え書-#26。” の続きを読む

WordPress 上で utf8mb4 を使う話。

 昨日,WordPress 4.2 がやってきた。 WordPress の Updates ページから更新したが,我が家は,マルチサイトタイプなので,その後, Upgrade Network が必要である。うちの SSL は自前認証局を使っているので, Upgrade Network をやる前に, wp-includes/certificates/ca-bundle.crt に自前 CA のデータを書き加えてやっておかないといけない。同様に下記の 2 行も wp-includes/class-http.php に加えてやる必要がある。これは,クライアント認証をクリアするためね。

  • curl_setopt( $handle, CURLOPT_SSLCERT, 'clientcert.pem の絶対パス' );
    curl_setopt( $handle, CURLOPT_SSLKEY, 'clientkey.pem の絶対パス' );

 この辺の話は,必要なら「WordPressでの「SSL3_READ_BYTES:sslv3 alert handshake failure」を解決。」を参照してください。

 ところで, WordPress 4.2 によると, WordPress は utf8mb4 をサポートするようになったようだ。ということで, JIS X 0213 の第 3 ・ 4 水準漢字の 4-byte になる下記の文字も記事内で使えることになった。ということは,いろんな絵文字も使えるわけだ。
 実は, 2013‎.5‎.22 に,この件やってみたんだけど,記事内では下記の文字は表示できなかった覚えがある。いや,スンバらしい。
𠀋 𡈽 𡌛 𡑮 𡢽 𠮟 𡚴 𡸴 𣇄 𣗄 𣜿 𣝣 𣳾 𤟱 𥒎 𥔎 𥝱 𥧄 𥶡 𦫿 𦹀 𧃴 𧚄 𨉷 𨏍 𪆐 𠂉 𠂢 𠂤 𠆢 𠈓 𠌫 𠎁 𠍱 𠏹 𠑊 𠔉 𠗖 𠘨 𠝏 𠠇 𠠺 𠢹 𠥼 𠦝 𠫓 𠬝 𠵅 𠷡 𠺕 𠹭 𠹤 𠽟 𡈁 𡉕 𡉻 𡉴 𡋤 𡋗 𡋽 𡌶 𡍄 𡏄 𡑭 𡗗 𦰩 𡙇 𡜆 𡝂 𡧃 𡱖 𡴭 𡵅 𡵸 𡵢 𡶡 𡶜 𡶒 𡶷 𡷠 𡸳 𡼞 𡽶 𡿺 𢅻 𢌞 𢎭 𢛳 𢡛 𢢫 𢦏 𢪸 𢭏 𢭐 𢭆 𢰝 𢮦 𢰤 𢷡 𣇃 𣇵 𣆶 𣍲 𣏓 𣏒 𣏐 𣏤 𣏕 𣏚 𣏟 𣑊 𣑑 𣑋 𣑥 𣓤 𣕚 𣖔 𣘹 𣙇 𣘸 𣘺 𣜜 𣜌 𣝤 𣟿 𣟧 𣠤 𣠽 𣪘 𣱿 𣴀 𣵀 𣷺 𣷹 𣷓 𣽾 𤂖 𤄃 𤇆 𤇾 𤎼 𤘩 𤚥 𤢖 𤩍 𤭖 𤭯 𤰖 𤴔 𤸎 𤸷 𤹪 𤺋 𥁊 𥁕 𥄢 𥆩 𥇥 𥇍 𥈞 𥉌 𥐮 𥓙 𥖧 𥞩 𥞴 𥧔 𥫤 𥫣 𥫱 𥮲 𥱋 𥱤 𥸮 𥹖 𥹥 𥹢 𥻘 𥻂 𥻨 𥼣 𥽜 𥿠 𥿔 𦀌 𥿻 𦀗 𦁠 𦃭 𦉰 𦊆 𦍌 𣴎 𦐂 𦙾 𦚰 𦜝 𦣝 𦣪 𦥑 𦥯 𦧝 𦨞 𦩘 𦪌 𦪷 𦱳 𦳝 𦹥 𦾔 𦿸 𦿶 𦿷 𧄍 𧄹 𧏛 𧏚 𧏾 𧐐 𧑉 𧘕 𧘔 𧘱 𧚓 𧜎 𧜣 𧝒 𧦅 𧪄 𧮳 𧮾 𧯇 𧲸 𧶠 𧸐 𧾷 𨂊 𨂻 𨊂 𨋳 𨐌 𨑕 𨕫 𨗈 𨗉 𨛗 𨛺 𨥉 𨥆 𨥫 𨦇 𨦈 𨦺 𨦻 𨨞 𨨩 𨩱 𨩃 𨪙 𨫍 𨫤 𨫝 𨯁 𨯯 𨴐 𨵱 𨷻 𨸟 𨸶 𨺉 𨻫 𨼲 𨿸 𩊠 𩊱 𩒐 𩗏 𩙿 𩛰 𩜙 𩝐 𩣆 𩩲 𩷛 𩸽 𩸕 𩺊 𩹉 𩻄 𩻩 𩻛 𩿎 𪀯 𪀚 𪃹 𪂂 𢈘 𪎌 𪐷 𪗱 𪘂 𪘚 𪚲

 ということで,「私,𩸽の開きを焼いたのが大好きなのよ」なんちゅうこともブログにかけるわけだ。ハハ。おっと,書き忘れるところだった。もちろんだけど, SQL Server の utf8mb4 サポートは当然ながら,必須ダヨ。

親サイトの自動保存がうまくいかない。

投稿アップデート情報  追記(9/6)

 いつからかは定かでないが,最近, o6asan.com での自動保存ができなくなっていた。 o6asan’s soliloquyo6asan’s soliloquy-part2 では問題なし。

 それとは別に, 29 日に php_opcache.dll がらみで, Apache のエラーログを見ていたときに多量の「WordPress database error Duplicate entry ‘0’ for key ‘PRIMARY’ for query INSERT INTO `WordPress DB table name` ~」に気づいた。

 昨日,ふとそのエラーのことを思い出して,対処してやろうと,エラーログをのぞきに行ったら, Notes 関係のものがたくさんあるということに気づいた。ここに至って,このエラーと自動保存の根が一緒だと気付いた。そんでもって,このエラーは 23 日に始まっていた。 MariaDB のアップデートのときに,何かまずいことをやらかしたに違いない (-_-;)。

 ログに含まれているテーブル名を確認したところ, `wp_postmeta`, `wp_posts`, `wp_redirection_logs`, `wp_sitemeta` の 4 つだった。 phpMyAdmin にログインして,無問題の wp_2_postmeta と wp_postmeta の構造をじっくり見比べてみた。 wp_postmeta の meta_id に AUTO_INCREMENT がないじゃん。ほかのテーブルも, ID に AUTO_INCREMENT がない。多分,このせいだ。

 何はともあれ,全データをバックアップの後,修復に取り掛かった。

  1. wp_postmeta テーブルを選択。
  2. メニューから「構造」を選択。
  3. 「操作」から meta_id の「変更」を選択。
  4. 「A_I」のチェックボックスをオンにしたのち保存。

 コマンドラインでやるなら,下みたいになるのかな。
ALTER TABLE `WordPress のデータベース名`.`wp_postmeta` CHANGE `meta_id` `meta_id`
BIGINT(20) UNSIGNED NOT NULL AUTO_INCREMENT;

 `wp_postmeta` と `wp_posts` については,問題無しだったが, `wp_redirection_logs` と `wp_sitemeta` では下記のエラーが出た。
#1062: ALTER TABLE causes auto_increment resequencing, resulting in duplicate entry ‘1’ for key ‘PRIMARY’

 `wp_redirection_logs` は単に Redirection プラグインのログなので,空にしてやってから,上の手順を再実行。テーブルを空にするのを CUI でやるなら,こんな感じになるんかね。
TRUNCATE `WordPress のデータベース名`.`wp_redirection_logs`;

 `wp_sitemeta` のほうは中のデータが絶対にいるので,ひとまず空にして,上の手順を再実行したのち,さっきバックアップした sql ファイルから `wp_sitemeta` の INSERT 文を切り出し,テーブルに再インポートした。

 Apache のエラーログから,問題のエラーが消えて,親サイトの自動保存も生き返った。めでたしめでたし。

 自己流の修復なので,あまりあてにしないでくださいませ m(_”_)m。

追記(9/6):
 BulletProof Security .50.8 へのアップデートのときに,どうやっても, “Network/Multisite BPS plugin Network Activation correction:” が消えないトラブルに遭遇した。で,フォーラムに相談に行ってきた。素早い対応をもらって解決したわけだが,これも AUTO_INCREMENT がらみだったようだ。どうも,2・3日前に読んだ phpMyAdmin のバグ関連の気がするのだが,真相は,藪の中。溜息。

 まあ,とにかく,消えるべきものは消えた。これで,安心して眠れるワ (^_^;)。

覚え書-#19。

 なんでだかすごく疲れているので,やったことのメモだけ。

 うちのサーバ OS は Windows7 HP SP1 (x86)。

  1. PHP 5.5.15 (php-5.5.15-Win32-VC11-x86.zip)
    —> PHP 5.5.16 (php-5.5.16-Win32-VC11-x86.zip)
  2. MariaDB 10.0.12 (mariadb-10.0.12-win32.zip)
    —> MariaDB 10.0.13 (mariadb-10.0.13-win32.zip)
  3. phpMyAdmin 4.2.7 (phpMyAdmin-4.2.7-english.zip)
    —> phpMyAdmin 4.2.7.1 (phpMyAdmin-4.2.7.1-english.zip)

 全部,単なるセキュリティアップデート。なので,速やかに対処。

phpMyAdmin 環境保管領域。

投稿アップデート情報  追記(7/5)  追記2(7/9)

 phpMyAdmin には,バージョン 3.4.2. から環境保管領域と呼ばれるようになった記憶媒体がある。 phpMyAdmin にしょっぱなにログインすると,「phpMyAdmin 環境保管領域が完全に設定されていないため、いくつかの拡張機能が無効になっています。理由についてはこちらをご覧ください。」というメッセージが出るので,名前にはなじみのある方も多いと思う。この機能を有効にすると, bookmarks, comments, SQL history, relations, PDF schema, MIME transformations を使えるようになる。まあ,この SQL サーバでやったことをまとめて覚えてくれている領域とでもいえばいいだろうか。なかなか,使いこなすところまでいかないのだが, bookmarks 機能なんかは,便利に使っているのものの一つだ。前にも,同名で記事を書いたことがあるのだが,それからだいぶ私の知識が進歩したと思うので,書き直すことにした。
 ところで, phpMyAdmin をサーバにインストールするについては,セキュリティ上,気を付けなければいけないことがたくさんあるが,ここではそれには触れないので, Official Documentation にしっかり目を通して,各自気をつけていただきたい。手前味噌だが,我が家の phpMyAdmin タグの記事もいくらかは参考になると思う。

 はじめて,環境保管領域を有効にするときの手順は以下のとおりである。

  1. create_tables.sql を使って, MySQL 上にそれ用のデータベースとユーザーを作る。
  2. 1. で作ったユーザに control user としての特権を付与する。
  3. config.inc.php をカスタマイズする。

 では,始めます。

  1. テキストエディタで create_tables.sql を開け,下の2行をアンコメントする。
    ————
    GRANT SELECT, INSERT, DELETE, UPDATE ON `phpmyadmin`.* TO
    ‘pma’@localhost;
    ————

    phpMyAdmin に root 権限でログインし, create_tables.sql をインポートする。これで, phpmyadmin データベースとパスワード未設定の pma ユーザが作成される。

    注) 気休めかもしれないが, phpmyadmin と pma という名前は,サーバ独自の別の名前にしておいたほうがいいと思う。なにしろ, phpMyAdmin というのは有名どころのソフトで,攻撃も半端でないので。インポート前に, create_tables.sql を編集しておけばすむ話ですから。

  2. phpMyAdmin SQL クエリウインドウから,以下のステートメントを実行してやる。
    ————
    GRANT USAGE ON mysql.* TO ‘pma’@’localhost’ IDENTIFIED BY ‘pmapass’;
    GRANT SELECT (
    Host, User, Select_priv, Insert_priv, Update_priv, Delete_priv,
    Create_priv, Drop_priv, Reload_priv, Shutdown_priv, Process_priv,
    File_priv, Grant_priv, References_priv, Index_priv, Alter_priv,
    Show_db_priv, Super_priv, Create_tmp_table_priv, Lock_tables_priv,
    Execute_priv, Repl_slave_priv, Repl_client_priv
    ) ON mysql.user TO ‘pma’@’localhost’;
    GRANT SELECT ON mysql.db TO ‘pma’@’localhost’;
    GRANT SELECT ON mysql.host TO ‘pma’@’localhost’;
    GRANT SELECT (Host, Db, User, Table_name, Table_priv, Column_priv)
    ON mysql.tables_priv TO ‘pma’@’localhost’;
    ————
    当然ながら, ‘pmapass’ はちゃんと変えてネ。 phpmyadmin と pma も自分の使うものに変えるのを忘れないでください。
     
    phpMyAdmin をログアウトする。
  3. config.inc.php を開けて,以下の 20 行をアンコメントする。 pmapass , phpmyadmin , pma の件もお忘れなく。
    ————
    /*
    * phpMyAdmin configuration storage settings.
    */

    /* User used to manipulate with storage */
    // $cfg[‘Servers’][$i][‘controlhost’] = ”;  ⇐必要ならば,設定。
    // $cfg[‘Servers’][$i][‘controlport’] = ”;  ⇐必要ならば,設定。
    $cfg[‘Servers’][$i][‘controluser’] = ‘pma’;
    $cfg[‘Servers’][$i][‘controlpass’] = ‘pmapass’;

    /* Storage database and tables */
    $cfg[‘Servers’][$i][‘pmadb’] = ‘phpmyadmin’;
    $cfg[‘Servers’][$i][‘bookmarktable’] = ‘pma__bookmark’;
    $cfg[‘Servers’][$i][‘relation’] = ‘pma__relation’;
    $cfg[‘Servers’][$i][‘table_info’] = ‘pma__table_info’;
    $cfg[‘Servers’][$i][‘table_coords’] = ‘pma__table_coords’;
    $cfg[‘Servers’][$i][‘pdf_pages’] = ‘pma__pdf_pages’;
    $cfg[‘Servers’][$i][‘column_info’] = ‘pma__column_info’;
    $cfg[‘Servers’][$i][‘history’] = ‘pma__history’;
    $cfg[‘Servers’][$i][‘table_uiprefs’] = ‘pma__table_uiprefs’;
    $cfg[‘Servers’][$i][‘tracking’] = ‘pma__tracking’;
    $cfg[‘Servers’][$i][‘designer_coords’] = ‘pma__designer_coords’;
    $cfg[‘Servers’][$i][‘userconfig’] = ‘pma__userconfig’;
    $cfg[‘Servers’][$i][‘recent’] = ‘pma__recent’;
    $cfg[‘Servers’][$i][‘favorite’] = ‘pma__favorite’;
    $cfg[‘Servers’][$i][‘users’] = ‘pma__users’;
    $cfg[‘Servers’][$i][‘usergroups’] = ‘pma__usergroups’;
    $cfg[‘Servers’][$i][‘navigationhiding’] = ‘pma__navigationhiding’;
    $cfg[‘Servers’][$i][‘savedsearches’] = ‘pma__savedsearches’;
    ————

    phpMyAdmin に再ログイン。

    「phpMyAdmin 環境保管領域が完全に設定されていないため、いくつかの拡張機能が無効になっています。理由についてはこちらをご覧ください。」というメッセージが消えたはず。

 おしまい!!

 これで,環境保管領域の機能が使えます。

追記(7/5):
 書き忘れ。
 アップグレードのときは,バックアップを取ったのち,新create_tables.sql を再度インポートする。前からあるものはそのままで,新しいテーブルのみ作ってくれるので,あとは,config.inc.php を手直しすればよい。
 もちろん,既にcontrol user は存在しているので,例の2行のアンコメントはしない。また, phpmyadmin と pma も自分の使うものに変えておくこと。

追記2(7/9):
 本日,くりくりさんへお返事を書いてて,ふと,1.と2.の間にタイムラグがあるのは,かなり怖いのかもと思った。うちのサーバの場合, MariaDB の接続ポートは外に対しては開いていないし,内向きに関してもユーザが私だけなので,そこまで神経質になる必要はないのだが,アクセス数が多く,必然的に悪意のアタックの絶対数の多いサーバの場合,1.と2.の間にタイムラグがあると, pma ユーザがノーパスでさらされる時間ができることになる。これは,かなり怖い。

 ということは,ユーザづくりは手作業でやって,パスワードと特権を設定したのち, create_tables.sql インポートするほうが,やっぱベターかな。

 ところで,うちの controluser の特権は,現時点で以下のようになっている。
————
GRANT USAGE ON *.* TO ‘pma’@’localhost’ IDENTIFIED BY PASSWORD ‘pmapass’;
GRANT SELECT, INSERT, UPDATE, DELETE ON pma_main.* TO ‘pma’@’localhost’;
GRANT SELECT (
Host, User, Select_priv, Insert_priv, Update_priv, Delete_priv,
Create_priv, Drop_priv, Reload_priv, Shutdown_priv, Process_priv,
File_priv, Grant_priv, References_priv, Index_priv, Alter_priv,
Show_db_priv, Super_priv, Create_tmp_table_priv, Lock_tables_priv,
Execute_priv, Repl_slave_priv, Repl_client_priv
) ON mysql.user TO ‘pma’@’localhost’;
GRANT SELECT ON mysql.db TO ‘pma’@’localhost’;
GRANT SELECT ON mysql.host TO ‘pma’@’localhost’;
GRANT SELECT (Host, Db, User, Table_name, Table_priv, Column_priv)
ON mysql.tables_priv TO ‘pma’@’localhost’;
————