今更 Debian Jessie

1年前に計画したJessie(Debian 8)へのアップグレード計画をようやく実行。

このblogを運用しているサーバはChefで構築していて、レシピの動作確認と開発環境を兼ねてVagrantでローカルのVirtualBoxの仮想環境に同じものを構築している。

ということでローカルの仮想環境で気兼ねなくアップグレードの練習をして、アップグレード手順を作ってから一気にこの運用サーバを更新した。Vagrant 1.8からsnapshot機能が標準で用意され3rd party製プラグインに使わなくても仮想環境の状態をそのまま保存・復元できるようになり、アップグレード前の状態を保存しておけば繰り返しアップグレードの練習ができるのも安心できるところ。結局、1回で上手く言ったので復元はしていないが。

はまって手順で対応したところ

  • 時間表示がUTCになっている → cp -p /usr/share/zoneinfo/Japan /etc/localtime
  • WordPressが動かない → php5-fpmphp7.0-fpmでsocketの待ち受けPATHが変わっていたのでnginxの設定を変更
  • Ruby 2.3.3にしたらChefのdatabasecookbookがmysql2 gemがなくて動かない → mysql2 gemインストール

基本、全部Chefのレシピで対応したので新規のインストールでも大丈夫なはず。

そうこうしているうちにDebian 9もリリースされてしまうのだが、今回はDebianのバージョンアップというよりPHP7に移行するのが目的だった。DotdebリポジトリからPHP7はJessie向けにしか提供されていないため。Debian 8も暫くサポートされるだろうから必要がある時にアップグレードすればよいだろう。

  • Debian 7.11 -> 8.6
  • PHP 5.5.38 -> 7.0.14
  • Ruby 1.9.3 -> 2.3.3
  • MySQL 5.6.35 -> MariaDB 10.0.28

とりあえず以上のようにアップグレードした。rbenvで入れているのでJessie関係ないがRubyを2.3.3にあげた。最近Redmineをバージョンアップする度にRedmineの依存パッケージがRuby 2.0以上を必要として運用に苦しんでいたので2.3.3にした。クリスマスに2.4がリリースされていたがアップグレードした時点ではRedmineのホームページの対応rubyバージョンに2.4が載っていないのでひとまず2.3系にした。

PHPにはOpcacheもついでに入れてみた。いろいろ速くなったような気もするし、気のせいかもしれない。そもそも自分のブログをアクセスして読まないのでよくわからない。

wp-gfm v0.9

GitHub上で公開している自作のMarkdownのWordpressプラグインを更新した。

https://github.com/makotokw/wp-gfm/releases
GitHub Flavored Markdown for WordPress

内部で使っているphp-markdownのバージョンアップと、フッターのデザインを少しポップにしてみた。

Markdown記法はWordPress本家のJetPackプラグインで出来るので基本的にはそちらを使えばいいはず。

wp-gfmはショートコードで囲った部分だけMarkdown変換するように作ってあり、Jetpackに乗り換えて過去記事を変換しなおすのが面倒なので使い続けている(メンテナンスし続けている)ところではあり、もともとソフトウェアエンジニアしか興味ないだろうと思ってGitHubにひっそり公開しているだけなのだが、何故か定期的にがつけられている。しかも大半が海外の人になっている。

ひょっとして世の中にはJetpackが使えない環境があるのだろうか? wp-gfmのスタンスとしては名前のとおりひたすらGitHubのMarkdownに記法、デザインを寄せるということでやっているのでそのあたりが良いのかもしれない。

サーバ証明書が更新されていなかった件

Let’s Encryptで取得したサーバ証明書がうまく自動更新できてていなかった。なお環境はDebian 7。

期限が20日と10日を切ると Let's Encrypt certificate expiration noticeという件名で期限が近いことをメールで知らせてくれた。ありがたい。

単にcronの設定を初歩的なミスで間違えていただけ。/etc/cron.d/certbotにchefでファイルを置くという運用をしていたが、個別のファイルにしたこともあってユーザのcrontabの設定と間違えてコマンドの実行ユーザを指定していなかった。それを直した次の日もcronはうまく実行できず、/usr/local/binにPATHが通ってなかったのでcertbot-autoコマンドが実行できていなかった。

とりあえず期限が迫ってきたのでおとなしく手動で実行したが、何故かaptnginxのパッケージの更新実行されて対話が必要だった。--no-self-upgradeを付けてもかわらなった。nginxが最新じゃないとだめだったりするのだろうか。

最新のドキュメント(Debian+Nginx)を見ると自動化はcronで以下の設定をしろと書いてある。見落としていたのか、いつの間にかコマンドが増えていたのか。

./path/to/certbot-auto renew --quiet --no-self-upgrade

ただ --force-renewal をつけてみたけどやっぱりnginxをreloadしないと反映されなかったので最終的に以下の設定にした。このブログは週末にアクセスが減るので日曜日に更新しておけばよいと思っている。

PATH=/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
0 5 * * 0 root certbot-auto renew --quiet --no-self-upgrade --post-hook "service nginx reload"

最初は && service nginx reload で繋いでいたけどrenewコマンドはデフォルトだと期限が近いもの(30日以内)しか更新されない。無駄なNginxの再読込が実行されてしまう恐れがあるので--post hookを使うのが良さげ。

PC VRへの道

二つの反動からPC VRへの道を模索している。

  • PS4 VRが買えなかったこと
  • 新MacBook Proの買い替えの踏ん切りがつかなかったこと

もともとはPS4 VRが10万とかで転売されているのを見て、その価格だったらPCのVRでも良くね?と思ったのがきっかけ。PCのVRの2大巨頭がOculusViveで大体10万前後する。

しかし、調べるとPCでVRを試すにはVR Ready PCと呼ばれる結構なスペックのPCが要することがわかった。特に高性能なGPUでないと描画が追いつかなくて酔ったりするらしい。自分は乗り物酔いも3D酔いもしないのでどうなるのかはわからないが。

ちなみに5年以上前に買ったDellのXPS-8300だとそもそも最新のグラフィックボードのインターフェースも合わないのでPCを買い換えるところから始めないといけない。最近のVR熱によってVR Ready PCで検索すると各社がVR Ready PCを販売し始めていて、15万くらいで買えそうである。

5万のPS4 VRを買えない反動にしては高すぎるが、もう一つの反動でMacBook Proを買い換えずに散財のしどころを奪われるので久しぶりにWindows PCを買い替えたくなってきた次第。今のMacBook Proで不満がそれほどないのでMacBook Proを買い換えるよりもWindowsのデスクトップPCをVR Ready PCに買い換える方がなんかお得感がある。

しかしながらOculusとViveのどっちを買うべきかは記事を読んでも決めかねる。マイクロソフトがOculus側についていてマインクラフトのWindows 10 Editionで対応しているらしき記事を呼んだが、普通にVive対応Modも存在するようなのでViveでも普通のPC版Minecraftで試せそうである。

Raspberry PiのDirty COW対応

基本外からはつながらないようにしているがRaspberry Piを自宅サーバで使っているので一応Dirty COW対応した。

Dirty COWは管理者権限を取られてしまう恐れのあるLinuxカーネルの脆弱性でLinuxベースのOSで漏れなく発生しておりDebianベースなRaspbianも例外ではない。Raspberry Piの用途はサーバであったり、デスクトップPCであったり、IoTであったり様々だと思うがそれなりに数が出ているので狙われる恐れがある。

Dirty COWの対応記事は Fix Dirty COW on the Raspberry Pi にあり、以下の対応策が書かれている。

sudo apt-get update
sudo apt-get install raspberrypi-kernel

自分のjessie環境では apt-get updateraspberrypi-kernel は更新されていたので明示的なインストールが必要な環境があるのかはよくわからない。

気になるのは該当記事に問題が起きる環境と修正された環境の確認方法が書いていないということである。これはコメントに書いてくれている人がいて 4.4.26 kernel 以上になっていれば良いとのこと。再起動後に uname -mrs などのコマンドで確認できる。

軒並みアップデートしたが、それなりに非力なPCであるので暫くアップデートしていないRaspbery Piでは apt-get update にかなりの時間を要した。

MacBook Pro Retinaのディスプレイ交換

かなり前にELECOMの液晶用ウェットクリーニングティッシュでMacBook Pro Retinaの液晶ディスプレイを拭いたらディスプレイがおかしなことになった。この現象は液晶コーディング剥がれというものらしい。

新しいMacBook Proを買わないかもしれないので直そうかと調べてみたら1年前くらいにこの問題の無料修理がされている。MacBook Pro Retinaユーザ全員に知らせてくれればいいのに・・・と思いつつゴネたらなんとかなるんじゃないかと思ってジーニアスバーに予約。結論から言うとゴネる必要もなくあっさりと無料交換してもらえた。

Apple Storeの店員さん曰く、MacBook Pro Retinaの液晶コーディング剥がれについては保証期間が過ぎていても初回に限り無料でディスプレイ交換を行っているとのこと。この問題は起きるユーザと起きないユーザがいたり、1年、2年後に突然おきるなどまだ現象がはっきりしていないので調査中らしい。だから全ユーザには通知していないという論理には腑に落ちていないのだが無料で直してもらえるので特にそれ以上は突っ込まなかった。

在庫があるとのことで1日で修理してもらえたが、そう言えば表参道のApple Storeはショップに修理コーナがあるみたいなことをオープン時のニュースで聞いた気がする。

内蔵ディスプレイのパーツだけ交換されると思っていたのだが、蓋全体が取り替えられて戻ってきたのでステッカーは全部張り直しになるので貼りたくっているエンジニアは注意が必要。

Beforeの写真を撮り忘れたので比較が出来ないが、交換後のディスプレイの方が輝度が上がり、より見やすくなった気がする。(追記: 修理後のディスプレイ輝度の設定がMAXにされていただけで輝度上がったと思ったのは気のせい)店員さん曰く、新しいディスプレイは液晶コーディング剥がれも起きにくくなっているとのこと。とは言え問題が完全に起きなくなるわけではないのでメガネのレンズ拭きで使うようなマイクロファイバー素材の布でディスプレイを掃除することを勧められた。あとはキーボードをPCクリーナーで掃除したあとに蓋を締めてしまうとディスプレイに溶剤が付いてしまう恐れがあるので注意ということも教わった。いろいろ怖いので普通に液晶保護シートを貼ってしまおうと思う。

液晶ディスプレイが新品になり、いよいよ新MacBook Proを買う気が無くなってきた。

MacBook Pro Mid 2012との比較

まだ新MacBook Proを買うかどうかを決めかねている。

さて、現行モデルより14%薄くなったとか言われても現行モデル知らんし。と思っていたので自分が持っているMid 2012と比較してみた。ググるとAppleの技術仕様のページが見つかるので各自持っているモデルで比較してみると良いと思う。

MacBook Pro (15-inch, Mid 2012) – 技術仕様

項目 Mid 2012 Late 2016
高さx幅x奥行き(cm) 2.41 x 36.4 x 24.9 1.55 x 34.93 x 24.07 厚み35%減
重量 2.56 kg 1.83 kg 730g減
バッテリー 77.5Wh 76.0Wh 1.5kh減
ワイヤレスインターネット閲覧 7時間 10時間 3時間長持ち

さすがに4年待つとすごく軽くなっている気がする。持ち運ぶ面でも良さそう。ただUSB-Cになって不便になる場面が目に見えているためまだ踏ん切りがつかず。

MacBook Pro買うかどうか

Appleの製品発表イベンドがあり、MacBook Proに関しては大方の予想通りのものが出たようだ。買うかどうか。そもそもここまで4年間も買い替えてこなかった理由は大きく二つある

  • CPUが刷新されない
  • MacBook Pro Retina Mid 2012が素晴らしすぎる

前者がようやく解決されてようやくSkylakeにはなったらしい。問題はKaby Lakeの時代が始まってきていることだがそんなことを言い出していたら永遠に買い換えれないのでどこかで行くしか無い。そのポイントがSkylakeだったと記憶しているのだが待ちすぎて忘れてしまった。(Skylake MacBook Pro買うかどうか)

1年前書いた記事を読んでみても、もう一つの「MacBook Pro Retina Mid 2012で充分」問題(?)は解決していない。何故か新モデルもメモリ16GBなのでMid 2012でも戦える気がする。もう世界はメモリ16GBで充分な時代なのか。これ以上向上しても人間が体感できる限界があるのか。MacでこれだとPC市場はもう限界のような気がする。ひょっとすると我々が買い換えないからメーカーもモデルを対してアップデートしなくなるのか。

最新OSがサポートされなくなるまで使い続けるという案も無くはないがどうするか。

https化の道その2

前回はLet’s Encryptの証明書を入れた。今回はmakotokw.comのコンテンツをhttpsに対応し、httpへのアクセスをhttpsにリダイレクトするようにした。

GitHubのBadgeでoctocard使っていたのだけど、これがhttps対応していないで諦めて直接GitHubのAPIをjsonpで処理して表示するようにした。

ブログのRSSからコンテンツの要約をトップで表示しているけど画像のリンクをhttpsにするためkwLogでAmazonJSのhttps版をこっそり運用している。

その他細々とした画像やフォントのurlをhttpsに変えていった。このブログはコンテンツが多いので画像のリンクなどを直すのが大変そうである。何かhttpsじゃないリンクをチェックしてくれるツールを探した方が良さそうな予感。

Pebble Time 2対応の道

Pebble Time 2(Emery)向け対応がなかなか大変そうな雰囲気。

Pebble Time 2は来年出る予定のPebbleの新型。名前の通りカラー四角のTimeの後継。解像度が144×168 → 200×228、DPIが172 → 202と変わる。

Pebble Time 2にはBezelモードというのがあって過去のPebble Classic(Aplite),Pebble Time(Basalt)向けに作ったWatchappは144×168のセンター寄せで周囲を黒い縁にして表示してくれる。なのでなにも対応しなくても実行できることはできる。昔iPadでiPhoneアプリを動かすときにあったときに似ている。

しかしDPIが上がっているので同じ解像度で表示しても文字などが小さくなってしまうと思われる。iPadならまだしもスマートウォッチでこれは致命的なので対応しないとなかなか使ってもらえないと思う。

丸型のPebble Time Roundが出たときはPBL_ROUNDPBL_RECTで分岐して四角か丸かで最適化した。今後はPBL_DISPLAY_HEIGHTPBL_DISPLAY_HEIGHTで頑張れということらしい。以下の例では228がTime 2、180がTime Round向けということになる。

#if PBL_DISPLAY_HEIGHT == 228
  uint8_t offset_y = 100;
#elif PBL_DISPLAY_HEIGHT == 180
  uint8_t offset_y = 80;
#else
  uint8_t offset_y = 60;
#endif

画像もexample-image~color~rect~228h.pngなどとできそう。

とりあえずレイアウトそのままでMineclockをそのまま実行したらこんな有様。

Round 2が出るのでは?と期待してTime 2はまだ買っていないが、微妙な解像度やDPIの違いはエミュレータでは確認できなさそうな気がするので凝ったデザインのWatchfappを作っている場合は実機を買わないと行けないような気がする。199ドル。
https://www.pebble.com/buy-pebble-time-2-smartwatch