カテゴリー
Windows

うー、久々にハマった。

 MariaDB の LTS である 10.6.x で久々にアップデートが出てたので更新しようと取り掛かったのだが、ダウンロードファイルの検証のところでハマったあ~。

 いっつも zip を落としてるので普通にダウンロードして、

gpg --verify mariadb-10.6.12-winx64.zip.asc

 ところが、 gpg: Can’t check signature: No public key が出てる。アレっとか思って、 https://archive.mariadb.org/ の PublicKey の日付見たら、 2022-May-03 なので 10.6.11 をやったときので何も問題はないはず。しかし、まあいいかというわけで、一度、 下記をやる。

gpg --delete-key [mail-address]
gpg --list-keys

で MariaDB 関係が消えてることを確認したのち、本日 https://archive.mariadb.org/ から落とした PublicKey を再度インポート。しかし、 list-keys で見る限り前と変わりない。 verify をやると、当然というかまた No public key が出る。

 今日落とした PublicKey で変わりないならどうすりゃいいのよと、ここからググり倒した。どうやら、下記の件だったみたい。

https://mariadb.com/kb/en/gpg/

 も一度、 delete-key [mail-address] をやったのち、普通に上記ページの Key ID を指定して、

gpg --receive-keys [Key ID]

をやれば、無事、 OK。 receive-keys は recv-keys でも問題ない。新しい ID のメールアドレスは前のよりちょっと短くなっていたよ。

 本題の 6.10.11 から 6.10.12 への更新は、無問題でした。やれやれ。

カテゴリー
WordPress

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

The same article in English

 さて、「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 である。

カテゴリー
Windows

MariaDB でセキュア接続。

The same article in English

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

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

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

カテゴリー
Windows

MariaDB10.2に移行。

The same article in English

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

 アップグレードに関しては,特に問題なしだった。やり方は,「MariaDB10.0.11へアップデート」とを同じ。

カテゴリー
everyday life

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

The same article in English

本日, 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;
カテゴリー
Windows

覚え書-#31。

The same article in English
投稿アップデート情報  追記(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:UsersUserIDAppDataLocalTempMSIXXXX.tmp
カテゴリー
Windows

覚え書-#26。

The same article in English

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

カテゴリー
WordPress

WordPress 上で utf8mb4 を使う話。

The same article in English

 昨日,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 サポートは当然ながら,必須ダヨ。

カテゴリー
WordPress

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

The same article in English
投稿アップデート情報  追記(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 のバグ関連の気がするのだが,真相は,藪の中。溜息。

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

カテゴリー
Windows

覚え書-#19。

The same article in English

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

 うちのサーバ 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)

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