とある５丁目で活動する還暦を過ぎたWebプログラマーの覚え書きです。それとかかってくる迷惑電話や、家業のアパート経営について。
ここのWordPressのエディタをGutenbergに変えてみたら、「更新に失敗しました」とかエラーが出て記事が保存できなかった。
別のサイトで試してみるとGutenbergで書いて正常に保存できているので、ここのサイトの問題でしょうな。テーマとかサーバー設定とか、何かが問題なのでしょう。
エラー報告がされているGitHubを覗いてみたら、issuesが溢れていた。Gutenberg本体が安定するか障害の情報がまとまるかまで、Gutenbergは様子見。クラックエディタを有効にしておく。
ポチップなんやかんやでWordPressのサイト構築で躓くのは、PHPのプログラミングなのでした。
BackWPupプラグインでエラーの通知が来た。BackWPupはWordPressの自動バックアッププラグイ。実はエラーを出ていても、しばらく放っておいたけど。
エラーが出ていると何か気持ち悪いので対応する。BackWPupの管理画面に入ると、「mysqliがどうしたこうしたと」警告が出ていた。これを手がかりに対応する。
BackWPupのジョブを直接実行すると
「エラー: ステップを中止: 回数が多すぎます」
とエラーメッセージが表示する。こちらを手がかりにしたほうが簡単に対応方法が見つかった。
要はPHPのバージョンが古くてmysqliのPHP拡張モジュールを対応していないからMySQLに接続しようとするとタイムアウトになっているとのことだった（だいぶ意訳）。
このWordPressのサイトはさくらインターネットのレンタルサーバーを使っているけど、最初にPHP7を入れたはずだけどと思ってphp -vを打ってみると5.6だった。つまりPHPのバージョンが古いのが原因だった。
さくらインターネットのサーバーコントロールでPHPのバージョンを7.2に切り替えてみる。実はこれは危険。思いつきで切り替えてはダメ。案の定WordPressのサイトにアクセスすると、画面が真っ白になってしまう。
「ああ、やってもうた・・・」と思ったけど気を取り直して、さくらインターネットのサーバーコントロールからPHPのバージョンを5.6に戻してみる。これは無事にアクセスできて元通り。この辺りはレンタルサーバーの気軽で簡単なところ。もし、専用サーバーだったら、PHPのバージョンを元に戻すは大変だろうな。
おそらくプラグインが悪さしているのだろうと思って、めぼしいプラグインを無効にしておく。PHPを7.2に切り替えると、今度は無事にアクセスできる。
一つづつプラグインを有効にしてみて、PHP7.2に対応していないプラグインを探してみる。インストールしていて対応していていないプラグインは、
の2つだった。
spam-byebyeは、もう古いしWordPressのJetPackでスパムコメントの対応はできていそうなのでもう必要ない。
痛いのはGoogle+Blogである。こいつはいくらかお金を払ってインストールしたもの。Google+（みなさん使っていないと思うが、実は自分が利用している唯一のSNS）から記事を自動的に取得して投稿してくれる連携プラグインである。このままではGoogle+Blogプラグインを有効にするとサイトにアクセスできなくなるので、したかないけど無効にしておく。Google+Blogプラグインのサポートサイトを見てみると、Error 502になるので、既にサポート終了になってしまっている。WordPressからG+へは自動投稿できているからよしとする。
以上でPHP7.2の対応完了。本件の始まりだったBackWPupプラグインのエラーはなくていた。ジョブを直接実行してみると正常にバックアップができていた。
まだまだThinkPadの携帯ネットワークが不安定である。これはThinkPadを買ったのが失敗したかと思った。わざわざWAN対応でカスタマイズしたのにな。
と、言ってられないので再度対応を考える。レノボのサポートサイトに行っても快活方法は見つからない。Q&Aのサイトはあるけど、サポートはユーザーコミュニティでやっているみたい。
ここから余談。
レノボにすればサポートは、「何かあったらユーザーコミュニティで質問しろよ。詳しいパワーユーザーが答えてくれるぜ。」って感じなのかな。しかし、パワーユーザーっていうのが曲者で、回答内容を見てみると、「あんたの質問内容じゃあ情報が足りない。」とか「あんたの質問は何を言っているかわからない」とか「そのそもこのコミュニティで質問するべきことではない。」とか、初心者からだと凹むような回答が多い。しかもこんな回答とするのが上位の回答数のユーザーと来たもんだから始末が悪い。
まあ、こんなユーザーコミュニティに頼らないで、自力で解決しなければいけないかと思ってしまったりする、これはレノボによる”ユーザースキルパワーアッププログラム”かもしれないな。
さて話しは戻るが。
結局、今のところの解決策として、最新のWANドライバをアップデートすること。2018年7月24日リリースのワイヤレスWANドライバにアップデートしておいた。とりあえずこれでまたまた様子を見ておく。
ドライバの置き場所とかは以下のレノボのサポートサイトで
自分のThinkPadの必要なドライバは、ここのリンクからダウンロードできるようだ。あらかじめレノボのユーザーアカウントを作成して、自分のThinkPadをマイプロダクトに登録すること。登録まで多少わかりにくくて手間取るかもしれないけど、がんばって登録してね。
ダウンロードサイトでドライバの自動更新ができるみたいだけど、あらかじめLenovo Service BridgeというThinkPadのシリアルナンバーとか中身をスキャンするソフトをインストールする必要がある。しかしながら、あらかじめインストールされていても、どういう訳かLenovo Service Bridgeが起動してくれない。そのときは、仕方ないので一度Lenovo Service Bridgeを削除してから再インストールしたら無事にスキャンが始まった。
ThinkPadは何かあったら解決が難しいと痛感した。まだまだ問題があるかもな。
やはりWANでつながらない。つながっているけどスリープから復帰したときとか、明示的に携帯ネットワークをOFFにするとつながらなくなる。携帯ネットワークでつなぐためには、ThinkPadの再起動が必要になる。再起動すれば、二回に一回はつながるようになる。
さて、Lenovoのサポートをお願いしようかとサポートサイトに行ってみると、連絡先の電話番号が見つからない。自分のThinkPadを登録したマイプロダクトのぺーじには、ユーザーコミュニティと有償サポート、国際サポートのリンクしか出てこない。散々探してみると、どうやら購入後30日しかレノボからテクニカルサポートを受けられないようだ。30日以降は有償になる。とにかくレノボのサポートサイトはわかりにくい。Q&A情報からは必要な情報を取得できなかった。
どうやらレノボは技術的なユーザーサポートは、ユーザーコミュニティに任せてしまっているようだ。ユーザーコミュニティを覗いてみても、そんなに満足できるような回答をされていない。レノボもこのユーザーコミュニティはレノボが運営しておらず、レノボからの回答ではないと謳っている。これではThinkPadを買ってもあとでトラブルがあっても正常に戻すことは一般の人では難しいかもしれない。
携帯ネットワークにつながらないときの対処方法の一番は、ThinkPadを再起動することしかなさそう。こんなバカなことがあるかは置いておいて、これはどこに相談するかが問題。Lenovoか？ Lenovoのユーザーコミュニティか？ それともSIMカードを出しているOCNか？ いずれも知らないと言われそう。
最初からWAN対応なんてThinkPadを買わなければよかったと後悔している。そもそもThinkPadを買わなければよかったのかな。携帯ネットワークにつながらないこと以外は、ThinkPad Carbonを気に入っているのだけど。
最初はうまく携帯ネットワークにつながっていたけど、今はつながらなくなった。圏外になってつながらない。ThinkPadを再起動すればつながることもあったけど、もう全然つながらない。
こうなったら、根本的に解決しようと考えてGoogleさんに聞いてみる。解決したサイトはここ。
mopera.net って今さら何なの？ こいつがデフォルトで設定されていたので削除したら無事につながるようになった。
しかしながら、こんなおまじないをしないと、Windows10はモバイルでつながらないの？ もしかしたら、自分のところだけ？
自作PC用に一番左のWindows11のパッケージを実際に購入しましたが、問題なくインストールできました。Windowsは使うPCの分だけ正しくライセンスを購入しましょう。
と書いたら、やはり携帯ネットワークをOFFにしたら、再度ONにしても圏外になる、しばらくすると、接続できるようになる。そんなものなのかな？
何かのタイミングでmopera.netのデフォルトの設定が復活していた。これはダメじゃない。もうmopera.netの情報を削除するのにコマンドを叩くのも面倒なので、相変わらずリブートしてから携帯ネットワークにつなげている。Windows10のWAN接続なんて使いものにならない。
これってWindows10の障害なのかな。OCNモバイルOneの問題？それともLenovoのThinkPadの問題？。またまた、自分が持っているThinkPad X1の固有の問題かな。誰に聞いていいかもわからないし。
現在のところの再起動以外の解決としては、一旦機内モードをONして、再度機内モードをOFFにすること。ThinkPadの機嫌がよければ、携帯ネットワークにつないでくれる。でも、ダメだったら再起動・・・・。
Reshared post from +Mune Ando
ツレが明日台湾に出発。まずは台風で飛行機が飛ぶかどうか。
台湾に行くのであれば、モバイルが必要。前回の台湾旅行では松山空港で中華電信のカウンターでSIMを購入した。
今回はツレの友だちが一緒に行くそうだから、今使っているドコモのスマートフォンで中華電信のSIMを使えるように、ドコモショップでSIMロック解除の手続をしてもらうように言っておいた。
しかし、前日になってSIMロック解除をしていないことが判明。どうも、台湾でスマートフォンを使えるようにということでドコモショップに行ったら、SIMロック解除ではなくて海外1dayパケを案内されたそうだ。ドコモめ・・・。
最初は仕事の電話がかかってくるから取りたいと言ってきたけど、着信もお金かかるよ、と言ったらそれはいらないということになった。旅行くらい仕事の電話なんて取りたくないしね。
ツレや現地で合流する台湾在住の友だちと、万が一の連絡手段を確保した方がよいという理由でやはり中華電信のSIMを入れておくことになった。フリーWi-fiではめんどくさいしね。
ということで、今はMy docomoでSIMロック解除の手続をお願い中。難しかったらこちらからリモートでサポートするか。でも、明日出発までSIMロック解除の手続が間に合うか？
海外1dayパケ | サービス・機能 | NTTドコモ
海外でもいつものスマホ・携帯を楽しもう。24時間単位で利用できる海外パケット定額サービス「海外1dayパケ」。NTTドコモのWORLD WING（ワールドウィング）なら、海外でも電話やSMS、データローミングをあんしんしてご利用いただけます。
新しくThinkPadを買ったけど、一つトラブルが発生している。
今回購入したThinkPadはSIMカードを入れて携帯ネットワークで接続できるようになっている。しかし、Window10の一旦携帯ネットワークの接続を切ると、そのまま圏外になってしまう。すぐにつなごうとすると接続できない。しかし、しばらく（30秒～1分ほど？）待つとと、接続できるようになるときがある。なるときがあるというも、できないときは圏外のまま。そのときは、確実に携帯ネットワークをオフにして、再度オンにしてからしばらく待つ。これで接続できることがあるという面倒くさいネットワーク接続である。
ThinkPadに入れているSIMはOCNモバイルOneだけど、同じSIMを入れているZenPhone3ではモバイルネットワークをOFFにして、すぐにONにしても接続できるから圏外でもOCN側の問題で無いかと思う。そうすると、ちょっと待って再接続というのはThinkPadか、はたまたWindow10の仕様か？ それともOCNモバイルOneとThinkPadの組み合わせの問題か？ 今回初めてWindow10にSIMカードというのは初めてだから、そんなもんだと言われたら仕方ないけど。
このまま1分も待つのも不便だから、Lenovoのサポートに連絡して他に事例が出ていないか聞いてみようかな。Googleさんに聞いてみても事例が出てこなかったので、おそらくそんな症状はないと言われそうだけど。まあ、接続できるコツみたいなものを見つけたから、時間がかかるが何とかなると言うものかもしれない。
せっかくZenPhoneのテザリングを使わないで、いつでもどこでもネットワークにつながるようにと、プラスアルファのお金をかけてThinkPadをカスタマイズしたのにちょっと残念。
自作PC用に一番左のWindows11のパッケージを実際に購入しましたが、問題なくインストールできました。Windowsは使うPCの分だけ正しくライセンスを購入しましょう。
結局、携帯ネットワークをいちいち切断しないで、つなぎっぱなしにしておけというのが解決策かもしれないな。Wi-Fiがつながればそちらが優先になるし。WANを切断して確実にモバイル料金がかからないしようとするのはダメかもしれない。もし、確実に切断したいのであれば、再接続に時間をかかるのを我慢しなければいけないということ。
今日近くのコメダで携帯ネットワークにつなごうとしたらダメだった。
オープンソースカンファレンスでのアンケートで協賛企業からのお知らせを送ってもいいとOKしているから送るぜ、とメールに何か書いてあってあったので、ふーんそうなのか、って思うけど、カンファレンス事務局経由ではなくて直接送ってくるものも何だかなと思うけど。メールの中身が本当に暑中見舞いとメールを送る理由だけで、セールス効果も何もないというのも痛いところで。
まあ、これはメールを送ったことでその会社がマイナスになっているから放っておいて、オープンソースカンファレンスのサイト（https://www.ospn.jp/）にアクセスしようとすると、SSL証明書エラーでアクセスできないけど、これは自分ところだけの問題なのかなと。
これでアクセスできなくなるなんて、これからは証明書はきちんと面倒見なければいけないと思うのでした。
今さらながら二段階認証のためにYubiKeyを購入した。今までは二段階認証にはGoogle認証アプリを使っていた。
サービスの中にはを二段階認証に使えないサービスもある。Evernoteとかセキュリティの設定画面でYubiKeyの設定がなさそうなのだけど、どこかにあるのかな？
Googleのログインは簡単になった。それとDropboxも。GoogleとDropboxはYubiKeyとGoogle認証アプリが併用できる。
パスワード管理のサービスを使っているけど、こちらはGoogle認証で二段階認証を設定しているところにYubiKeyの設定をすると、YubiKeyだけになってGoogle認証が使えなくなる。YubiKeyの設定を解除するとGoogle認証が使えるようになる。このことをサポートに聞いたら、これが仕様だそうだ。複数の二段階認証の入口を許さないことでセキュリティを高めているということなのか。
パスワード管理はYubiKeyを使わずに今まで通りGoogle認証アプリを使うことにする。6桁コードの認証コードを入れるのは面倒だけど、スマートフォンを無くさないと思うけど、小さなYubiKeyを無くしそうで心配だから。でも、スマートフォンって壊れるよね。結局どちらも心配だけど、これはいずれ考えるということで先送り・・・。
まだまだYubiKeyを使いこなせないという感じかな。一番の問題は、どうやってYubiKeyを持ち運ぶかということ。普段は家にいるし、自宅が電子キーなのでキーフォルダなんて持っていないしな。
お客さんのサイトを常時SSL化をしたときのメモ。というか嵌まったことをメモする。
現在は、AWSのELB＋EC2（Windows Server）で運用している。EC2はとりあえず一台で運用している。インスタンスが一つではロードバランスとか冗長化と関係ないが、でもEC2一台でもELBを入れておけば、サーバーのアップデートとか入れ替えが簡単だし（言い訳）。
以上を常時SSL化を実施する。まずは、AWS Certificate Managerで証明書を発行する。認証が必要なのでDNSで認証する。AWS Certificate ManagerかかRoute 53に認証するSNAMEを追加してくれるので認証が簡単。
HTTPでアクセスしたとき簡単にリダイレクトの設定をしてしまうとループするようなので、IISのReWriteモジュールにリダイレクトのルールを追加する。Web,configにAWSのサポートページにあったルールを追加するとエラーになる。これからがトラブルの始まり・・・。
IISの設定から手作業でリダイレクトルールを追加する。参考にしたのは、こちらのページ。こちらでエラーもなくリダイレクトルールを追加できた。
次にAWS ELBにHTTPSのリスナを追加する。そのときAWS Certificate Managerで作成した証明書を指定する。これで完了を思いきや、サイトにつながらなくなった。
EC2のセキュリティグループを確認したり、Windows Serverのファイヤウォールを確認したりといろいろやってみたところダメ。これで作業終了かと思ったら、単にELBのセキュリティグループにHTTPSの設定がなかっただけだった。HTTPSを追加したらアクセスできた。
しかし、www.付きのドメインだとEdgeやFirefoxでは証明書エラーとなる。www.なしのドメインだけだと正常。Chromeだとどちらでも保護されていると正常となる。
これはAWS Certificate Managerで証明書を作ったときの失敗だった。www.無しのドメイン名だけで作成していた。www.付きでも大丈夫のように別名を指定して証明書を作ってあげるようにする。おかげで再度証明書を作り直す。
AWS Certificate ManagerでDNS認証で、どういうわけかwww.付きのドメインの認証がやたら時間がかかった。作成に失敗したかと思って、もう一回証明書を作成し直してしまった。www.無しだとすぐに認証してくれたけど、無しだと1時間くらい認証に時間がかかった。これがAWSの仕様かどうかは不明。
ELBのリスナーにHTTPSを追加する。このとき前の証明書の選択項目が残っていてリスナーの追加に失敗する。ELBから一旦別のAWSのサービスに行ってからELBに戻ると正常に追加できた。
これで常時SSL化は完了。HTTPでアクセスしてもHTTPSにリダイレクトしてくれることも確認する。www.付きでも無しでも正常にアクセスしてくれることも確認する。
途中、心が折れそうになったけど、無事に常時SSL化は完了。
ポチップお客さんから「さくらインターネットからSSLの証明書を再発行しろってメールが来たけどやっておいて。」と連絡があった。デジサート社（旧シマンテック社）が発行したSSLサーバー証明書を、Chromeで失効されてしまうので再発行しなければいけないそうだ。
さくらインターネットの指示通りにサーバー証明書を取得の手続きを行う。しかし、発行ステータスが手続中のままで一日経っても進まない。さくらインターネットのサポートに問い合わせると、認証ファイルを再度アップしなければいけないそうだ。説明書をよく読んでいなかったし（どこかに書いてあるかわからない）のが大きな敗因だった。サポートからは「認証できていないから。」の一言だったのはやさしくないサポートだった。認証ファイルを設定しなけれいけないなんて、とんと忘れていたので（更新の一年に一回しか作業しないし）、認証ファイルをアップし直すということまで、たどり着くまで時間がかかった。最初はIPアドレスの許可かファイヤウォールの設定かと思った。
無事に認証されてサーバー証明書をダウンロードできるようなった。今度はWindows ServerのIISにイントールしようとしたらできなかった。IISの「証明書要求の完了」でインポ
再度、さくらインターネットに問い合わせたところ、自分のところのサーバーではないからサポートできないと回答されてしまう。その回答メールの中に
今回の証明書再発行はGoogle とデジサート社との不仲が原因であり、
ChromeやFirefoxなどで、ある期間にデジサート(シ
証明書をエラー扱いにするというものでございます
と書かれているので、何だか会社同士の勝手なふざけた理由で、こちらが作業しなければいけないようだった。これに関しては、さくらインターネットのサポートには、「ふざけんな。」と返送しておく。
このトラブルの件を調べたところ、同じ現象が報告されている。
このような現象が発生したら、そのままIISでは証明書を入れられない。OpenSSLのコマンドで.pfxファイルを作ってからインポートしてあげないといけないようだ。面倒くさそう。
今回のサイトはブラウザでアクセスするようなサイトではないしテストサイトみたいなものだから、これからどうしようか考える。他社のSSL証明書にしたほうが速いし安いかな。
現在はさくらインターネットからSSL/TLS 証明書を全部引き上げて、AWSでAWS Certificate ManagerでSSL/TLS 証明書を管理している。その方がお金もかからず手間もかからず幸せになるのである。
