エレクトロニクス

　大雨やらなんやらで詳細は見ていませんがとりあえずアップデートしました。こういう忙しい時に限って作業が増えるのはいつものことですけどどうしてでしょうか。
WordPress 4.9.7 Security and Maintenance Release(https://wordpress.org/news/2018/07/wordpress-4-9-7-security-and-maintenance-release/)
要望対応と細かい修正だけ Luxeritas 3.2.4(https://thk.kanzae.net/dev/wp-themes/luxeritas/t9785/)
　とりあえず不具合や脆弱な部分は減ったと思います。雨が振り続けているし過去記事でも直そうか…と作業していたところ、
不具合 1 件修正（条件に該当する方はアップデート推奨） Luxeritas 3.2.5(https://thk.kanzae.net/dev/wp-themes/luxeritas/t9809/)がリリースされましたので２連続テーマ差し替えを行いました。今日は私以外503無いようです。

エレクトロニクス

　先月書いたXSERVERのaccess_log内IPアドレス欄をFQDNへ変換(サクラエディタ＋logresolve編)(https://kadono.xsrv.jp/2018/06/06/4658)では一々面倒なのでPython3.6で動くスクリプトを作成しました。Windows10およびCentOS6.9(VirtualBox)上のPython3.6 (CentOS6.9は後から入れる必要あり)で動いています。入力がログファイルで標準出力に逆引き後のログが出てきます。ファイル入力のみでlogresolveとは異なり標準入力からのストリーム動作(?)には対応していません。XSERVERのログが日毎なので私はこれで問題ありません。また、ファイルを２回読みすることで最初は重複削除と逆引きだけ(Max.100スレッド逆引き)行い、２パス目で逆引き結果の文字列置換を行います。仮想ホスト名はこのサイトのURLで決め打ち、変換後のログからは削除しています。

　コードの大半はRuby, Pythonで並列に逆引きを行う(http://0xcc.net/blog/archives/000099.html)で公開されているPython用のマルチスレッド逆引きプログラムです。一部Python2向けの部分などを直しています。DNSの逆引き＋タイムアウト待ち時間が処理時間の大半を占めるため、このマルチスレッド処理が無ければ普通にlogresolveを使ったほうが速いと思います。
マルチスレッド処理と結果を辞書で処理するアイデアはpythonでマルチスレッドで処理して各スレッドの結果を受け取る(https://qiita.com/komorin0521/items/c25cfcff89c0b1afe882)を参考にしています。
IPアドレスの重複削除についてはPython Tips：リストから重複した要素を削除したい(https://www.lifewithpython.com/2013/11/python-remove-duplicates-from-lists.html)を参考にしました。紹介されている内包表記など凝った書き方は勉強不足で十分理解できていないため使用していません。
また、IPアドレスの正規表現は5.2.3　IPアドレスのフォーマットチェック（正規表現）(http://www.geolocation.co.jp/learn/program/07.html)を多少変更(修正?)して使用しています。

　ほとんどGoogleで検索して組み合わせるだけでスクリプトが完成しているので大変楽になったと思います。

""" mt-logresolver """
# -*- coding: utf-8 -*-
# http://0xcc.net/blog/archives/000099.html
# https://qiita.com/komorin0521/items/c25cfcff89c0b1afe882
# https://www.lifewithpython.com/2013/11/python-remove-duplicates-from-lists.html
# http://www.geolocation.co.jp/learn/program/07.html
import re
import threading
import queue
import socket
import sys
def lookup(ip_address):
    try:
        return socket.gethostbyaddr(ip_address)[0]
    except socket.herror:
        return ip_address
def resolver(queue, lock, resolver_dict):
    while True:
        ip_address = queue.get()
        if ip_address is None:
            break
        host_name = lookup(ip_address)
        lock.acquire()
        try:
            resolver_dict[ip_address] = host_name
        finally:
            lock.release()
def logresolver(filename):
    queue1 = queue.Queue()
    num_threads = 100
    re_pattern_1 = re.compile(r"^kadono.xsrv.jp ((([1-9]?[0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])\.){3}([1-9]?[0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])) (.*)")
    resolver_dict = dict()
    ip_address_list = []
    fp = open(filename, 'r')
    for line in fp:
        pattern_1 = re_pattern_1.search(line)
        if pattern_1:
            ip_address = pattern_1.group(1)
            if ip_address not in ip_address_list:
                queue1.put(ip_address)
                ip_address_list.append(ip_address)
    fp.close()
    lock = threading.Lock()
    for i in range(num_threads):
        queue1.put(None)
        thread = threading.Thread(target = resolver, args = (queue1, lock, resolver_dict))
        thread.start()
    thread_list = threading.enumerate()
    thread_list.remove(threading.main_thread())
    for thread in thread_list:
        thread.join()
    fp = open(filename, 'r')
    for line in fp:
        pattern_1 = re_pattern_1.search(line)
        if pattern_1:
            print(resolver_dict[pattern_1.group(1)]+" "+pattern_1.group(5))
    fp.close()
if __name__ == '__main__':
    logresolver(sys.argv[1])

決め打ちにしている部分(最大スレッド数、仮想ホストURL)などまだまだ改良の余地はあると思います。しかし、先延ばしにしているといつ出せるかわからないので見切りで公開します。
※動作チェックはこのサイトのXSERVERログのみでnginxのログ全般で動くかどうかは未確認です。

後日追記)経験上100位ならば問題ないと思いますけど、num_threadsを大きくしてリソースが少ないマシンで走らせるとRuntimeError: can’t start new threadで止まることがあります。その場合はthread数を少なくすると動くようです。Python3.6デフォルトでの限界はPythonとRubyでthreadとfiberをいくつ作れるか検証して見た(https://qiita.com/yohm/items/32e5965cc7b561dc8e4e)によると2048のようです。

エレクトロニクス

　またしても3.2.2をスキップして一個飛びで3.2.3へのアップデートとなりました。仕様変更と機能追加があったようです。が、詳しく読んでいる暇もないのでリンクだけ置いておきます。
404 Not Found の設定機能 ＋ 一部仕様変更 Luxeritas 3.2.3(https://thk.kanzae.net/dev/wp-themes/luxeritas/t9763/)
環境によって PWA でオフラインできない場合の対策を組み込んだ Luxeritas 3.2.2(https://thk.kanzae.net/dev/wp-themes/luxeritas/t9709/)
　一応ログを見た限り更新作業は1分以内で済んでいるので503 (Service Unavailable)になった方はいないはずです。ログを見るとブラウザのキャッシュが効いて無駄なデータ転送が省略されているのがよくわかります。あと、画像検索で高解像度画像だけ持っていった方とか…。

　一方で、404になっていたapple-touch-icon-*.pngって何だろう？(アクセス元IPを見る限り検索ロボではなさそうですが…)調べる暇が無いのでメモっておきます。

エレクトロニクス

　またしてもZenfone3 ZE520KLのアップデートを行いました。気になったのでGoogleの
Android のセキュリティに関する公開情報(https://source.android.com/security/bulletin/)を見たところ大量の重要度が高い脆弱性対策などが入っているようです。このページへは設定→端末情報→Androidセキュリティパッチレベルを選択していくとリンクで上記サイトへ飛びます。
アップデート完了時のメッセージによると1806.65になったようです。

エレクトロニクス

　過去記事の修正作業だけで手一杯で3.2.0と3.2.0.1の2つのバージョンをスキップして3.2.1へのアップデートとなりました。
　アップデート内容の詳細はWeb Font を設定してると AMP エラーが出る不具合修正 Luxeritas 3.2.1(https://thk.kanzae.net/net/wordpress/t7875/)を参照してください。3.2.0.1から3.2.1での変更はタイトルの一件だけのようです。
　3.2.0でPWA（Progressive Web Apps）に対応したとのことですけど、このサイトで新機能を設定する余裕など無いためデフォルト(無効)のままスルーです。どうやって使うのかを調べる余裕もありません。
　余裕がなくてもやらなければならないこともあるため以下を実施しました。
エックスサーバー社からのお知らせ推奨PHPバージョン変更のお知らせ(https://www.xserver.ne.jp/news_detail.php?view_id=3163)に基づき、PHP7.1.18からPHP 7.2へ切り替えました。
WrdPress のセキュリティ強化方法(https://thk.kanzae.net/net/wordpress/t7875/)を読んで変更をいくつか(記事への影響はありません。詳細は非公開です)。

エレクトロニクス

　対応が追いつかず3.1.4はスキップしました。早速アップデート用テーマの出番だと思ったので使用してみました。テーマ切り替えにより存在しないURLが検索結果に出る事を抑止できたかと思います。zipを展開してsftpで上書きするのとブラウザだけで作業が完結するのとどっちが確実で楽かは微妙なところです。
　nginxのログを確認したところ以下のようにチェックしにアクセスした私としつこいロボットが合計5回503になっていました。
GET / HTTP/2.0″ 503 371 …
　アップデート内容の詳細は開発元のカスタマイズの組み合わせによる不具合の修正とか Luxeritas 3.1.5(https://thk.kanzae.net/dev/wp-themes/luxeritas/t9613/)を参照してください。
　ver 3.1.4からIntersection Observer (画像の遅延ロード機能)に対応したそうなのですけど効果確認などをしている時間が無いためさしあたって設定は変えずdisableのままスルーします。

エレクトロニクス

　kadono.xsrv.jpに接続してこの記事を読めているということはTLS1.2に対応したブラウザを使用しているはずです。最近バタバタしていて放置状態だったethOSを起動して以下のコマンドで確認を行いました。コマンドはQiitaのcURL, OpenSSLコマンドでTLSのバージョンを指定する方法(https://qiita.com/Esfahan/items/53399964cb76cdb87e60)という記事を参考にしました。

$ curl --head -s -v --tlsv1.2 https://kadono.xsrv.jp > /dev/null
* Rebuilt URL to: https://kadono.xsrv.jp/
# 中略、URLの表記を直されました。
* SSL connection using ECDHE-RSA-AES128-GCM-SHA256
# 中略、TLS1.2指定ではデータが読み出せました。
$ curl --head -s -v --tlsv1.1 https://kadono.xsrv.jp/ > /dev/null
# 中略
* error:14077102:SSL routines:SSL23_GET_SERVER_HELLO:unsupported protocol
* Closing connection 0
$ curl --head -s -v --tlsv1.0 https://kadono.xsrv.jp/ > /dev/null
# 中略
* error:14077102:SSL routines:SSL23_GET_SERVER_HELLO:unsupported protocol
* Closing connection 0
$ curl --version
curl 7.35.0 (x86_64-pc-linux-gnu) libcurl/7.35.0 OpenSSL/1.0.1f zlib/1.2.8 libidn/1.28 librtmp/2.3
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtmp rtsp smtp smtps telnet tftp 
Features: AsynchDNS GSS-Negotiate IDN IPv6 Largefile NTLM NTLM_WB SSL libz TLS-SRP

　TLS1.0, 1.1ではエラーになり1.2では接続できているので予告通りTLS1.0/1.1の無効化が実施済みのようです。
　ethOSにcurlが付いていたのは楽ですけど2014年1月リリースでバージョンが古く複数の脆弱性があります。最新版は今年5月リリースの7.60のようです。一方でOpenSSLはopenssl 1.0.1f-1ubuntu2.24で今年3月のpatchが当たっています。ただし、バージョン番号は1.0.1fのまま表示されます($ openssl versionも)。

エレクトロニクス

　朝の出勤途中に歩いていていきなり揺れだし揺れてからSHF32とZE520KLの緊急地震速報が鳴りました。出勤して少し落ち着いてから高槻の辺りが震源と聞いて驚きました。
　SHF32はauのVoLTE SIMが入っていてこれまで何度も緊急速報メールを受け取っています。ただ、今回SIMカード無し(MR05LNとBluetoooth接続)でこれまで一度もETWSが鳴ったことが無いZenfone3 ZE520KLも動いたことであれ？と思いました。少し落ち着いてから画面を見たところ以下の2つが表示されました。多くの方が書かれている通り、両方とも揺れる前には届きませんでした。


Android8へのアップデートで追加された機能のようです。しかし、今回のような直下型では備える時間など無かったためあまり役に立ちません。
　早めに仕事を切り上げて念のためプリウスにガソリンを給油しました。帰ってから確認したところ、自分の部屋で目立った被害は無く机や棚の上の書類など軽いものが落ちたり引き出しが出た程度でした。引き出しや戸棚には対策が必要かもしれません。

　なんだかんだの対応で疲れました。とりあえず、私は無事です。

エレクトロニクス

　寝る前にZE520KLを見たところまたまたアップデートのお知らせが表示されていたので作業を行いました。

タイトルに表示しているソフトウェア情報→ビルド番号最後が61(6/4アップデート)から62_0に変わっただけのようです。

WiFi周りの変更らしいですけど具体的に何がどう変わったのかまでは分かりません。更新前でも普通にWiFiで使っていました。

エレクトロニクス

　このサイトへ移行するにあたって非常に重要な要素だったWordPress用テーマLuxeritasのアップデートを行いました。詳細は開発元のLuxeritas 3.1.3 色々パワーアップ（7月までにアップデート推奨）(https://thk.kanzae.net/dev/wp-themes/luxeritas/t9465/)を参照してください。

　たぶん、このサイトがLuxeritasを利用しているサイトのうちで最大数の記事(1400+)と画像データ(2000+)を公開しているのではないか？と思います。ちらほら、このサイトのデータ量を見て変わったのではないかな？？と思うところもありますけど詳細を追っている時間もありません。

　いかんせん、移行に手間取り過ぎでまだサムネイルの調整などがまだまだできていません(OCN時代の画像データ発掘は後回しです)。古い記事を表示させようとした時にブラウザが引っかかるような挙動をするのはサーバやテーマの問題ではなくほぼ高解像度画像(3〜6MB)を転送ないしデコードしているためと思います。一部例外を除いて新しい記事から順番に対応していますのでしばらくお待ち下さい。縦横やトリミングなどの影響で画素数がバラバラのため、一括処理が困難となっています。

　追記)勢いでテーマのアップデートを行いましたがアップデート後からGoogle Analyticsのデータが取れなくなっていました。今のうちにサムネイルなどを直してしまえ！と思ったのは単なる思い込みでした。子テーマもアップデートしたため子テーマの編集→アクセス解析(head)の中身がクリアされてAnalyticsのトラッキングコード(グローバル サイトタグ（gtag.js）というやつ)が消えていたようです。まぁ、レンタルサーバに移行したおかげでアクセス解析など無くてもnginxのログを見れば分かるのですけど、ログにはあってAnalyticsに出ないのは気になりました。

　更に追記)子テーマは通常アップデート不要だそうです。あと、私は乱暴(SEO無視)に適当なテーマに切り替えてテーマのアップデート作業を行っていましたけど、ちゃんとLuxeritas アップデート用テーマ(https://thk.kanzae.net/wp/update/)というのが用意されていました。子テーマのアップデートまでは無理なようですけど、思っていたよりもサポートが手厚いです。インストールはしたものの実際に使うのは次アップデートになるので備忘録として追記しておきます。