エレクトロニクス

本来はスクリプトを作って一発変換のほうが楽なのですけど、手作業した場合の手順をメモしておきます。

XSERVERからaccess_logをダウンロードしてサクラエディタで開く
ctrl-rで文字列置換のメニューを出す
正規表現のチェックが入っているのを確認
置換前の文字列に"^kadono.xsrv.jp “(最後に空白U+0020一文字)と入力
置換後の文字列は空欄のまま(下の画像参照)
alt-bで全行の先頭1カラムが黄色でハイライト(選択)されることを確認
問題なければalt-aで文字列置換(先頭カラム削除)を実行
IPアドレスの数字が先頭のカラムになったことを確認してログファイルをセーブ

httpdに付属のlogresolveが使えるマシンへ処理したファイルを転送
logresolve < kadono.xsrv.jp.access_log > resolv.log
などでDNSを引いてFQDNへ変換、変換出力ファイルを確認

 上記の変換無しでいきなりlogresolveを実行しても先頭カラムが仮想ホスト名のため期待する結果は得られませんでした。Windows版のlogresolve.exeも存在するようですけど作業量を考えるとスクリプト一つの方が楽ではないかと思います。

エレクトロニクス

本日朝にアップデートの通知が表示されていましたけどMR05LNのBluetooth接続では遅すぎて400MB以上もダウンロードできないため放置していました。帰ってから自宅のWiFi+VDSL回線経由で更新作業を行いました。

更新直前までの連続稼働時間は583時間で約24日です。先月運転免許更新の講習受講時に電源を切ってから連続稼動していたようです。

更新内容は以下の通りでAndroid 8.0.0からの変更(8.1へ)はありませんでした。

普段使っているアプリケーションで特に変わったところは無さそうです。

エレクトロニクス

 どこのページを参照していたのか分かりませんが(結局そのページの手順ではsftpで接続できなかったのでメモを消しました)、XSERVERへSFTPで接続する際にFTPアカウント設定は不要のようです。というか、FTPアカウントの方が設定されているとソフトによってはフォールバックするらしくsftpのつもりが普通の非暗号化ftpで接続している恐れがあります。
 WinSCPで正しくsftpで接続していれば右下に使用しているプロトコル(下の画像ではSFTP-3)が表示されるはずです。

 まれに私もsftpに限らずフォールバック(機能縮退運転)に気づかないことがあるので確認する習慣を付けたほうが良さそうです。
 セキュリティ向上の為、XSERVERの設定画面で使わないFTPアカウント設定は削除しましたけどSFTP接続は使えています。契約内容や収容先ホストによる違いまでは分かりません。このサイトはX10プランです。

エレクトロニクス

 本日レンタルーサーバーを運営しているエックスサーバー社より連絡があり表題の通り2018/6/12よりTLS 1.0/1.1 を無効化するとのことです。このサイト(https://kadono.xsrv.jp以下)も影響を受けます。詳細は下記公式ページを御覧ください。
【重要】「ファイルマネージャ」「(旧)WEBメール」「phpMyAdmin」「お客様が運用中のWebサイト」における TLS1.0/1.1 の無効化について(https://www.xserver.ne.jp/news_detail.php?view_id=4435)

 既にTLS1.2以降を利用可能なブラウザを使っている方が大半だと思いますので大きな影響は無いと思います。TLSへの移行で思い出したのが2015年のJR東海によるご利用の携帯電話の機種等をご確認ください/SSL3.0脆弱性への対応としてのアクセス遮断(4/11更新)(https://expy.jp/topics/detail/?id=191)ですけどこのときはTLS1.0に【未対応】な多くのi-mode端末が接続不可になりました。

 後日追記)6/22に確認を行いました。確認方法はXSERVER TLS1.0, 1.1無効化確認、TLS1.2のみ作動中(https://kadono.xsrv.jp/2018/06/22/5604)を参照してください。

エレクトロニクス

 特に考えずにhttps://kadono.xsrv.jp/feedの最後に"/"(スラッシュ)を付けて掲載していましたけど、無い方が極わずかながら無駄が減らせるようです。
 レンタルサーバへ移行したのでhttp server (nginx)のログが15年+ぶりに見られるようになりました。それを見ていて気づきました。以下、一部カラムの抜粋です。

"GET /feed/ HTTP/1.1" 301 0 "https://kadono.xsrv.jp/"
"GET /feed HTTP/1.1" 200 11022 "https://kadono.xsrv.jp/"

というようにfeed/からfeedへ301リダイレクトでの転送が行われてからfeedで実データ(このときは11022bytes)を取得しているからです。初めから/無しならば無意味な転送が発生しないため、このサイトでは/無しを推奨することにします(跡地を含めた移行ページの表記を更新しました)。この設定が一般的なものかどうかは分かりませんけどrssとかrss2の後に/は付けないことが多いので同様の扱いかと思います。たかが1リクエストの転送(1hごとの巡回として24/day)だけですのでここのような辺境サイトではあまり大きな影響はないとは思います。それでも、無駄は無駄ですので低減する方向に設定します。
 私のinoreaderの設定(統計情報→iマーク→XMLのアドレスで確認できます)は/付きを削除して無しへ差し替えました。

エレクトロニクス

 はてなダイアリーというよりもはてなフォトライフの変な(はてなな?)仕様により公開していた写真データ中の位置情報がダダ漏れになっていた点についてタイトルの方法にて対応を行いました。
 このサイトへの移行ついでに支障があると独断と偏見で判断した2000+中114ファイルだけ位置情報データのみの削除を行いました。その他のカメラデータや撮影時刻・条件などはオリジナルのまま残しています。100以上の対象ファイルをGUI手動で変更するのは面倒すぎるので簡単なスクリプトを見つけてきて使用しました。
 元にしたのはstackoverflowという英文サイトに掲載されたRemoving GPS data using from an image using Pillow and Piexif(https://stackoverflow.com/questions/38483074/removing-gps-data-using-from-an-image-using-pillow-and-piexif
)
というほぼそのままの記事と一緒に投稿されたプログラムです。ただ、目的が異なるためこの問題点再現プログラムをそのまま使うにはいくつか課題があります。

一つ目はGPSデータが削除できているかを確認していません(.clear後に.getを再度実行)。

二つ目はEXIFの処理後にimg.saveでjpegデータを書き戻すと画像データの再圧縮処理が行われ画像データ本体が元と一致しないばかりか劣化します。

 一つ目の問題はpiexifのドキュメントを読みながら適当に作れば比較的簡単なので省略します。私はこのチェックに加えて再度問題ファイル抽出用の緯度経度計算スクリプトを掛けてダブルチェック後に再公開しました。

 二つ目の問題が少し悩みまして(データ移行が遅くなってすみません)、例によって寄り道していました。jpeg再圧縮時のパラメータをいじってquality=98, optimize=Trueぐらいで見た目はほぼ同じにできましたけどファイル容量がかなり増えてしまいました。そこから新規格のWebPやらJPEG2000やらも試してみましたが全くだめ(容量が増える、非対応ブラウザが多すぎる、処理が重いなどなど)でした。
# img.save(output_filename, 'JPEG’, quality=98, optimize=True, exif=exif_copy_nogps)
# img.save(output_dir+"/"+file_base+"_nogps.webp", 'WebP’, lossless=True, quality=100, exif=exif_copy_nogps)
# img.save(output_dir+"/"+file_base+"_nogps.webp", 'WebP’, quality=100, exif=exif_copy_nogps)
# img.save(output_dir+"/"+file_base+"_nogps.j2p", 'JPEG2000’) shutil.copyfile(file, output_filename)
piexif.remove(output_filename)
piexif.insert(exif_copy_nogps, output_filename)
 結局最後の2行で解決しました。出力先ファイルをshutil.copyfileでコピーしておき一旦exif情報を削除してそれからGPSデータを消したexifを書き込みます。やり直しが嫌だったので上書きができるかどうかまでは試していません。
 スクリプト全部を晒すことも考えましたけど、フォトライフの二の舞いになる(削除したつもりができていなかった)では困る可能性もあるため要点のメモだけ公開します。
 基本は位置情報が残ったら困る場所では撮影前にカメラや携帯の測位情報付加機能を無効にしておくべきだと思います。が、後処理でもなんとかならんこともなかったというお話です。

エレクトロニクス

 色々試して結局以下の形式にしました。
まず日記なので年・月・日ごとに検索できた方が便利です。
 以下の使い方がWordPress的にアリなのかはよく知りません(よって再変更の可能性もあります)けど、
https://kadono.xsrv.jp/2018で2018年分の記事を表示します。
https://kadono.xsrv.jp/2018/05で2018年5月分の記事を表示します。
https://kadono.xsrv.jp/2018/05/27で2018年5月27日分の記事を表示します。
この機能は大変便利です。ただ、これだけですと同じ日に複数の記事があるとかぶってしまうので個別に識別できる必要があります。色々迷いましたけど連番は不都合もあるため、飛び飛びになるpost_idを採用することにしました。
https://kadono.xsrv.jp/%year%/%monthnum%/%day%/%post_id%
一例:https://kadono.xsrv.jp/2018/05/27/3685
 基本は日付設定までで対応できると思います。post_idを間違えてもその日のデータは表示される仕様のようです。
https://kadono.xsrv.jp/2018/05/01/0000000
でも5/1分が表示されます。ただし、000000の部分が数字以外(hogefuga等)の場合は404でエラーとなります。

 時刻6桁(235959)を提案するページも見ましたけどはてなダイアリーからの移行時に時刻データは削除したため全て000000で重複したためこの案は採用できませんでした。

 このサイトはあくまでも自分を含めた"人"が読むために書いています。決して検索ロボット向けでは無いためSEOを無視してでも使いやすい方に設定します。

エレクトロニクス

一応、旧サイトからの全データを一通り移しました。ただし、以下の点はまだ未対応です。

同一日付に複数の投稿がある場合にパーマリンクが重複(?)何かおかしいですがなぜ一部のみ重複したかは未確認。→パーマリンク設定を変更しました(詳細別記事予定)。関連してカテゴリーのスラッグも英文小文字へ更新しました(日本語入力不可能/困難な環境に対応するためです)。
上記に関連してサイト内リンクが切れている可能性が高い。
PNG画像またはjpegのキャプチャ画像(EXIFデータに日付なし)などでのリンク切れの可能性。
Youtubeの動画へのリンク切れ。(6/24までに修正しました)
縦長で撮影した画像が極端に大きく表示される(横幅で制限のみのため)。→サイズ指定に変更予定。

確認しながら直していきますけど古い記事までは時間がかかると思います。

エレクトロニクス

WordPressへの移行を開始して既に1週間経ちましたけどまだ2016年分(1200件+)までしか移せていません、お目当ての記事が見られない方にはすみません。この土日で追い込むつもりです。

だいぶ移行の手順は決まってきて効率は上がっているとは思います。しかし、2013年(たぶん現状年次での投稿データ量ピーク)分の写真だけで1GB超あったりでサーバーにも結構な負荷を掛けています。

新たに見つけたポイントとしては2013年11月購入のOLYMPUS STYLUS TG-2で撮った写真に入っているEXIF GPS位置情報が大きくズレている点です。どうやら電源を入れて新たに測位できるまでに直前に電源OFFした時点で有効な位置情報があるとそれを新しい写真の撮影位置として書き込んでいたようです。AW100の0よりもたちが悪い仕様になっています。どの写真で不整合が起きているのか絵とデータを突き合わせるしかありません。プリウスなど自動車の移動中ですと最悪は1km超ズレている恐れもあります。このサイトにアップロードしている画像で見つけた誤差最大は今のところ、直線距離で約1.12kmズレです。WiFiで測位したほうがマシだったかもしれないレベルです。この写真1枚については測位情報の公開は不適当と判断してEXIFデータ内のGPS項目だけ削除してアップロードし直しました。

ついでに(こんなことしているから移行が進みません)、緯度0度・経度0度を調べるとギニア湾の海上になります。日本国内と言わずとも陸上で撮影した画像に対しては明らかに位置情報エラーというのが分かるため未測位や補足衛星数が不足して誤差100m超過の状態では北緯ゼロ度・東経ゼロ度で記録してくれたほうが後処理しやすいです。

エレクトロニクス

このサイトのWordPress用テーマLuxeritas 3.0.2へのアップデートを実施しました。不要なテーマを根こそぎ削除していたため一旦デフォルトのテーマへ戻した上で古い3.0.0(3.0.1はスキップ)を削除してから3.0.2をインストールしました。特に変わったところは無さそうです。

ソフト404では中々旧サイトのURLが消えないためGoogle Search ConsoleのGoogleインデックス→URLの削除を申請してみました。

2012年分までデータを移しましたが文字列自動置換だけでは取りこぼす場合があるようなのでところどころリンク切れが徐々に直していきます。画像データが巨大化してきてレンタルサーバーの一日あたり転送量が1GBを超えました。表示確認のためアップロード→ダウンロードを繰り返しているためサーバー上で消費する容量の2倍以上の転送が必要になります。