Nook Simple Touchをroot化してEPUB/PDFリーダーとして活用する

2017-11-10 20:01 | 技術

我が家にはBarnes & Noble社の電子書籍リーダー、Nook Simple Touchが転がっています。5年前に友人の米国出張で買ってきてもらったやつで、けっこう当時としては優秀なデバイスです。ハックしようと思ってずっと放置していたものです。

これを今更活用してみようと思い立ちました。

2011年の発売から6年以上が経過し、搭載しているAndroid 2はとっくに骨董品。rootを取る方法などを掲載したブログなども多数リンク切れになっています。そもそも検索して出てくる情報なんて最新でも2013年かそこらの記事ですし、日本語記事も数少ない。逆に言うとそれだけ枯れきっていて、うまくドキュメントを探せばやりたいことが全部インターネットに書かれてあります。そんな玄人好みの遊びをやってみることにしました。

結論から言うと、このデバイスが持っている潜在能力を引き出して電子書籍リーダーとして活用することに成功しました。私のように死者を現代に復活させようという変わり者たちの為に、いくつか有用な情報を記すことにします。

ドキュメントの探し方

キーワード:
Nook Simple Touch / NST
Android 2.1 / GingerBread
rooted / root
EPUB / PDF / mobi / EBOOK / e-book
NookManager / TouchNooter / NTGAppsAttack
日本語化 / Japanese / 中文 / Chinese / non-latin / CJK / Asian characters
(※日本語化については情報の多い中国語化手順から探した方が効率的です)

Androidいじるならおなじみxda
https://forum.xda-developers.com/

root化の方法

何はなくともrootを取らないと始まりません。あなたが米国人でBarnes & Noble社の想定ユーザに含まれているなら話は別ですが、初期状態ではそもそも日本語EPUBは文字化けしてしまいます。
(OSレベルではサポートしているのでメタデータ等は表示可能)

もしあなたのNook Simple Touchがネットワークに接続可能なら、自動的に最新のファームウェアがダウンロードされているはずです。2017年現在はversion 1.2.1で、これをroot化するにはNookManagerというソフトを使います。(もしversion1.1以前ならTouchNooterというソフトを使う)。私はNookManagerのversion0.5.0を使用しました。

手順はここにすべて書いてあります。
https://geekanddummy.com/how-to-rooting-the-nook-simple-touch/

こちらの情報もあわせてお読みください。
https://forum.xda-developers.com/showthread.php?t=2040351

TouchNooter版ですが日本語情報だとここが参考になります。
http://www.tobiume.com/pcpdapna/hardware/314-nook-touch-rooting.html

導入方法は一般的なAndroid端末のroot化手順と同じで、ダウンロードしてきたイメージをmicroSDカードに焼き、端末のバックアップを取ってからmicroSD経由で起動するとroot化されます。

もう少し説明すると、

  • PCにmicroUSBケーブル経由でPCに接続し、端末のバックアップを取る
  • microSDカードにNookManagerを焼いて起動する
  • 画面の指示に従いroot化を選択すると自動でroot化される
  • 画面の指示に従いmicroSDカードを抜いて再起動するとroot化が完了され、新しいランチャー(ReLaunch)が起動する

という手順になります。

Google Playストアを利用したい場合はあわせてNTGAppsAttackも導入しましょう。ただし標準ブラウザはとっくにサポートが終了しているのでOpera Miniをインストールして、そちら経由でGoogle Playを使うことになります。(標準ブラウザを使用すると「このブラウザは現在サポートされていません」表示。NTGAppsAttack導入時だと404ページになるか「google play terms of service(利用規約)」のページに飛ばされて何もできない)

私の場合はこちらの手順でGoogleアカウントでGoogle Playストアにログインするところまでいったものの、任意のアプリページでインストールをクリックしても何も反応しないのでGoogle Playストア経由でのアプリ導入は諦めました。別の属性を持つ3種類のアカウント(Google Appsの独自ドメインのアカウント、通常のGmailアカウント、ロケールを米国にしたGmailアカウント)で試してみましたが、いずれもダメでした。apk形式のインストーラを使用するなら、Google Playストアの使用は回避可能です。

なお、読みたい日本語EPUBが十分少ない数で、ファイルを個別編集してCSSでフォント指定可能ならroot化の必要はありません。
こちらのCSSを使用すれば標準フォントで表示可能です。
https://www.mobileread.com/forums/showthread.php?t=139782

動作が確認できたアプリ

Root Explorer 2.21
http://www.apkhere.com/down/com.speedsoftware.rootexplorer_2.21_paid
(Root Explorer 5.0.0ではNGでした)

FBReader 2.6.15
https://fbreader.org/files/android/FBReaderJ.apk
(これがAndroid 2系向けの最終バージョン)

FBReaderはページめくりボタンが使えるのでオススメです。(Aldikoはボタン無効)

Aldiko Book Reader 2.00.081
http://www.freewarelovers.com/android/apps/aldiko-book-reader
(Aldiko Book Reader 3.0.16ではNGでした)

その他Google Play BooksやEvernote、Dropboxなど導入できそうなアプリのapk情報はこちらにまとまっています
https://forum.xda-developers.com/showthread.php?t=2690166

日本語EPUBが読めるオススメリーダーは日本語情報があります
https://forest.watch.impress.co.jp/docs/serial/androidlab/515301.html

日本語IMEの導入については日本語情報があります
http://emanate28junkbox.blogspot.jp/2012/05/rooted-nook-simple-touch-reader-app.html

FBReaderで任意のフォントを導入する

FBReaderは標準フォント以外に外部フォントを選択してEPUB表示することが可能です。”/sdcard/fonts”にttfファイルを置き、設定で選択して再起動すると反映されます。Windowsに入っているフォントを流用する場合はttcファイルをttfファイルに変換する必要があり、こちらのツールが有用です。

メイリオとnotoが入ったディレクトリの表示

メイリオとnotoが入ったディレクトリの表示
このように4ファイル1セットで導入しました

メイリオとnotoが選択可能になった設定画面

このように新しくフォントが選択可能になります

ADBを使ったファイル転送

NookManagerを入れるとADB KonnectというツールがインストールされてPCからADBコマンドが使えるようになります。Wi-Fiが使用できる環境であればワイヤレスでシステムディレクトリ含めたファイル転送・配置が可能なため試行錯誤を効率化できます。(マウント時にWRITE権限を設定することを忘れないで)

ADBの導入方法はこちら。
https://www.orefolder.net/blog/2017/03/platform-tools/

タイムゾーンの変更

Nook Simple Touchは米国のタイムゾーンしか選ぶことができません(当然ですね)。NookColorToolsで隠し設定をこじ開けてみましたが、タイムゾーンの設定はいじれないようです。

スクリーンセーバーの変更

些細な話ですが、Nook Simple Touchはスリープ時のスクリーンセーバーとして作家の肖像画が表示されます。自然の写真に変更することもできますが、できればカスタマイズしたいですよね。”/media/screensavers/[任意のスクリーンセーバー名]/”以下に任意の画像を置くことでカスタマイズできます。形式はPNGまたはJPG、大きさは600×800です。
http://nooktalk.net/nook-faq/article/53-using-the-nook/173-how-do-i-make-my-own-screensaver.html

初音ミクのスクリーンセーバーが表示された画面

初音ミクのスクリーンセーバーを設定しています

新しく追加したスクリーンセーバーが選択可能になった設定画面

ディレクトリにファイルを追加すると設定画面で選択可能になります

おわりに

ここまで死者を蘇らせといて何ですが、E-Inkデバイス意外と悪くないかなと思い始めて新しい機種への欲が出てきてしまいました。いま気になっているのはOnyx Boox C67ML Carta2。ひとまず気を落ち着かせて、Nook Simple Touchで不満が出るかどうかしばらく試してみてから考えようと思います。

Pocket

エレガントなパーマリンクとは

2017-10-31 19:26 | 技術

このブログを開設してから17年、現在のドメイン(yagi.tc)を使い始めてから12年になりますが、マイナーccTLDということもあり、相次ぐ値上げと運用上の制限が気になるためにドメイン移転をすることにしました。ものはついでで、どうせ301リダイレクトを設定するのならブログのパーマリンクもより運用しやすいものに変えようと考えました。

しかしブログに適したパーマリンクについて日本語でいろいろ調べてみても、SEOに有利かどうかについて書かれたエントリしか見つからず、しかもその内容もそれぞれ根拠のない内容を扱っているだけで、ベストプラクティスのようなものは存在しないようでした。それならひとつ自分が情報を整理してエントリに仕立て上げてみようと思い、ここにまとめることとします。

1. このエントリの前提

前提として、個人が所有するブログのパーマリンクに主眼を置くこととします。分野をあまり絞らないパーソナルな内容で、長期間の運用をし、独自ドメインを持ち、WordPressなどのCMSでパーマリンクを選ぶときに、ハテどうしようかと悩んでいる私のようなひとのための検討材料です。

近年は「URL」のことをより広い集合である「URI」と呼ぶこともありますが、このエントリではブログのパーマリンクを主眼にしている意味合いから「URL」で統一しています。

また、コンテンツのURL全般を指す場合は「URL」、ブログやその他コンテンツが一意に持つパーマリンクのみを指す場合は「パーマリンク」と呼んでいます。

2. 参考資料と現状認識

コンテンツのURLについては検索エンジンGoogleによってガイドラインが公開されています。

コンテンツに関するガイドラインhttps://support.google.com/webmasters/topic/4598733?hl=ja

ざっくり「シンプルかつ論理的で可読性のあるURLにしなさい」と書いてあります。そのためにコンテンツに対して一意であることが望ましく、IDを使用するよりは意味のある単語を使用した方がよいようです。

もうひとつ参考になるのは、Googleのサービスの一つであるGoogle Cloud Platformが公開したAPI設計についてのブログエントリです。

API design: Choosing between names and identifiers in URLshttps://cloudplatform.googleblog.com/2017/10/API-design-choosing-between-names-and-identifiers-in-URLs.html

これは人間が理解するブログではなくコンピュータが理解するAPIのための内容ですが、両者に共通する思想を持っているために、上記のガイドラインよりも一歩踏み込んだ内容として手本となります。

ざっくり内容を紹介すると、例えば

https://ebank.com/accounts/a49a9762-3790-4b4f-adbf-4577a35b1df7

のようなIDを使用したフラットな構造のものと

https://library.com/shelves/american-literature/books/moby-dick

のような分類による階層構造を伴うものとあり、両者にはトレードオフが存在し、より好ましいのは後者のように見えるが、一概にそうだとは言えないということが書かれてあります。そして、前者はパーマリンクとして、後者は検索のために使用して両立させるという例が挙げられています。

実際のブログのパーマリンクの主流はどのようなものでしょうか。もっとも使用されているCMSであるWordPressでは、規定値のパーマリンクは

https://example.com/?p=1

のような形式になっています。他に、日本でもっともユーザ数の多いブログサービスであるLivedoorブログでは、

https://example.com/archives/52017243.html

のような形式になっています。いずれもエレガントとは言えないようです。

3. エレガントなパーマリンクとは

では「エレガント」なパーマリンクって何なのでしょう。突き詰めるととても主観的な話になってしまいますが、基本的にはGoogleのガイドラインにある「シンプルかつ論理的で可読性のあるURL」でよいと思います。そこに私は「運用が単純であるURL」を加えたいと思います。この重要性については後述します。

これらの各要素を順番に確認していこうと思います。

3-1. シンプルさと可読性を両立させるURLとは

まずはGoogleのガイドラインにある「シンプルかつ論理的で可読性のあるURL」を見ていきます。

3-1-1. シンプルさを優先する(短縮URL)

もしこれを「シンプルかつ論理的」の方向に突き詰めるとどうなるのでしょう。

Twitterで使用されている短縮URLサービス「t.co」の例です。

https://t.co/nEDMKlFpP4

人間にとってたいへん読みにくいことを除けば「シンプルかつ論理的」であると言えるでしょう。冗長な部分を廃してもっとも短く、かつ一意になるURLです。短いことの利点は単純で無駄がないことです。保存に場所をとらず、通信するのも短時間で終わります。(あくまでURLは、の話です)

このURLが生きるのはもちろんTwitterです。Twitterは一投稿あたりの文字数に厳しい制限を課しています。どのような長いURLであっても、URLが投稿に収まりきらないということはこれでなくなりました。素晴らしいですね。

URLが短いことの利点はモバイル環境でも発揮されます。これは短縮URLサービスを指した話ではなく、URLが短いこと自体についてです。モバイル環境ではブラウザのアドレスバーに表示される文字数が限られるため、より少ない文字で収まるURLであれば、人間にとって認識できる情報量が増えます。
(※ただし認識できても理解できるかどうかは脇に置きます。短縮URLサービスでは本来URLから推測できる情報が欠落するため、フィッシングサイトの温床になっている現実があります)

短縮URLサービスではなく、そのサイトのパーマリンクを「人間が理解できないほどシンプル」にしている例として以下があります。

YouTube
https://www.youtube.com/watch?v=3RDYVVmVR2U

実のところ冗長であまりシンプルとは言えませんが、投稿された動画がいくつになろうと対応できる柔軟性と、それでいてURLの長さがほぼ変わらない安定性を持っていることは特筆すべきです。私ならもっと短縮URLチックに「https://youtube.com/3RDYVVmVR2U」とするところです。

Qiita
https://qiita.com/toyoshi/items/f40e6440e50b3fc5ccd9

こちらもやや冗長ですが、エントリのハッシュ値をとって擬似的に一意にするという発想は特筆すべきです。同様の例にはGithub Gistがあります。

Github Gist
https://gist.github.com/toriwasa/7e1464d8050a596705793770fe158234

16進数のハッシュ値よりさらに短くできるBASE64で良いのではないかと思いましたが、URLのルール上「/」が含まれてしまうのが微妙なので16進数で手を打っているのかもしれません。

Evernote 共有ノート
http://www.evernote.com/l/ABANAls7iwVNvokclFwn2Vb-1jP8QVjXAsP/

人間の理解を一切考慮せずBASE64的なURLにしており、たいへん合理的です。Qiitaに比べて衝突可能性も格段に低いと思われます。

3-1-2. 可読性を優先する(冗長なURL)

上記の通り、シンプルで論理的なURLを追求すると人間の理解が難しい文字列になります。このため、たとえ短くても人間がコピー&ペースト以外で手打ちしたり読み上げたりする場合は大変です。多少冗長であれば手打ちや読み上げ時に間違いがあってもエラー訂正が可能ですが、人間の理解ができないURLでは訂正を期待できません。

そこでスラッグ(slug)を使うという方法があります。私のブログはこの形式です。

yagi.tc
https://yagi.tc/archives/2017/10/16/always-on-ssl/

上記の例では“always-on-ssl”の部分がスラッグで、全エントリ中一意になるようになっています。つまり設定を変えて、もっとシンプルに

https://yagi.tc/always-on-ssl/

とすることもできます。ある程度シンプルかつ論理的な形を保ったままで人間に理解しやすい形にするというバランスの取れた解決策です。URLから内容が推測できるため、Google Analyticsなど、配下のURLを大量に認識する必要がある場合にとても役立ちます。

ただしスラッグの難点は、タイトルとは別にいちいち設定する必要があることです。もし英語圏の人がエントリを書いたなら、自然とタイトルや本文はASCIIに収まるのでスラッグを設定しやすい(何なら自動で設定させても良い)のですが、ASCII以外の文字(マルチバイト文字)を使う文化圏の人にとってはどうでしょうか。

WordPressでスラッグを有効にした場合、他に何もしなければタイトルの前から何文字かが自動でスラッグになります。日本語で書けば当然マルチバイト文字になります。困ったことに、スラッグがマルチバイト文字で設定され、URLもマルチバイト文字を含む形になった場合、URLエンコード(パーセントエンコーディング)が発生します。エンコードされたURLはとても長くなり、人間の理解ができない形になります。Wikipediaのパーマリンクがよい例です。

Wikipedia
https://ja.wikipedia.org/wiki/%E3%82%B9%E3%83%A9%E3%83%83%E3%82%B0

URLエンコードされる前は「https://ja.wikipedia.org/wiki/スラッグ」となりますが、このページを表示してアドレスバーからこのURLをコピー&ペーストした場合、ブラウザによってコピーされる文字列が異なります。Chromeなら「https://ja.wikipedia.org/wiki/%E3%82%B9%E3%83%A9%E3%83%83%E3%82%B0」が、Edgeなら「https://ja.wikipedia.org/wiki/スラッグ」が入ります。

このように表面的にはマルチバイト文字はきちんと表示されても、内部的にはエンコードされた文字列になるので実装がまちまちで、とても厄介です。はじめからASCIIに収まる形にした方がよさそうです。しかしタイトルも本文も日本語なのにスラッグをどうやって付けるのでしょうか。

たとえばタイトルの日本語が「このサイトを常時SSL化しました」なら「konosaitowo-joujisslka-shimashita」にすればよいのでしょうか。これだと可読性に乏しく、URLエンコードされた文字列とあまり変わりませんね。おそらくスラッグを使っている多くの人は英単語を利用して設定していると思います。

でも内容が日本語なのにわざわざ和英辞書を引いて英単語のスラッグを付けるなんてちぐはぐで、ちっともエレガントじゃありませんよね。もしかするとQiitaがハッシュ値を利用しているのも、内容がマルチバイト文字であることを前提にこうした仕様にしているのかもしれません。

これについての解決策は特に思いつきません。私たちはエントリを書くたびに和英辞書を引くか、自動でID番号やハッシュ値が設定されるようにするかの、どちらかの(あまりエレガントではない)選択肢を選ぶしかなさそうです。

ASCII文字以外を用いる言語圏のサイトを少し見てみましたが、ロシア語では英単語で代替、フランス語やスペイン語では発音区別符号を無くした母国単語と英単語の混在などの形にしているようです。

3-2. 長期的な使用に耐えるURLとは

ブログのパーマリンクについてSEO的にどのようにすればよいか書かれたエントリは多数ありますが、正反対のことを主張する二つの勢力に分かれているようです。それは「カテゴリをパーマリンクに含めるか否か」です。

WordPressのパーマリンク設定を変更して、SEOや日本語URLの対策をしようhttps://liginc.co.jp/web/wp/customize/148458

http://トップレベルドメイン/カテゴリー名/投稿名(英数字)

「http://liginc.co.jp/web/wp/custmize/145732」という形ですね。
パッと見ただけでも、Web関連でWordPressのカスタマイズにまつわる記事なんだろうな、ということが想像できるようになりました。

結論から言うと、おおむね上のようなパーマリンク構造が理想的です。

【WordPressのパーマリンク】おすすめの設定と理由https://fujimotoyousuke.com/2017/01/wordpress-permalink-setting/

パーマリンクにカテゴリ名を入れたほうが良いという人もいますが、わたしはおすすめしません。

二つの勢力に分かれているだけあって容易に解決できる問題ではないのですが、私は「カテゴリをパーマリンクに含めるべきではない」という立場をとります。なぜならカテゴリは(少なくともブログのパーマリンクとしては)長期的な使用に向かないと考えるからです。

以下ではそれについて触れていきます。

3-2-1. 階層構造の弱点

Google Cloud Platformのブログエントリでは、

https://library.com/shelves/american-literature/books/moby-dick

のような分類による階層構造を伴うURLが示されています。見たところ分かりやすいURLですし、実際インターネット上でもっともよく見るタイプのURLだと思います。

ところがパーマリンクは「Permalink」の文字通り、恒久・不変である必要があります。困ったことに、こういった分類というものは途中で弄りたくなるものです。動植物の分類学でしょっちゅう変更があるように、「このページはこっちだったけど、あっちでまとめた方が良さそうだな」みたいなことが起きる可能性があります。これは長期的に運用すればするほど高まります。

もちろんそういった場合のために、301リダイレクトという方法があります。しかし細かい話をすると、そのマッピングがあることで運用コストはどんどん上がっていきます。初めから無いに越したことはありません。特に私の場合何度かの移転を経てマッピングが膨大で、これ以上増やしたくないのです。

はじめに前提条件として「個人が所有するブログのパーマリンクに主眼を置く」と述べました。個人が所有するブログである以上、私のように十数年と運用していると興味関心がどんどん変わっていきます。その都度ブログを作るのも良いですが、私は文章のはけ口を一箇所にしたいのです。もしそういう場所でカテゴリ分けをするのであれば、なるべく長期間それが機能するものでなければなりません。この教訓は私が10年以上前、このサイトをブログに再構成したときに作ったカテゴリが現在は機能していないという事実に基づくものです。

3-2-2. 階層を廃したURLとは

ではカテゴリを使用しない場合、どのような形が「エレガント」なのでしょうか。

私のブログのパーマリンクについて再掲します。

yagi.tc
https://yagi.tc/archives/2017/10/16/always-on-ssl/

これをよりエレガントにするには2つの方向性があります。一つはスラッグのみにしてしまうことです。

https://yagi.tc/always-on-ssl/

内容について推測ができ、それでいてシンプルです。階層構造が一切ないので、スラッグを設定する名前空間に気を付ける必要があります。(サイトの連絡先が書かれた重要なページも、ただの一エントリも同じ階層に所属することになります)

気を付けなければならないのは、Movable TypeのようにHTMLファイルをパブリッシュ(出力)するタイプのCMSでは、一ディレクトリの直下に大量のファイル(またはディレクトリ)が存在することになるため管理が煩雑になります。なのでこれはWordPressのようなタイプのCMSに向いています。

もう一つはタイムスタンプのみにしてしまうことです。

https://yagi.tc/2017/10/16/
または
https://yagi.tc/20171016/

スラッグではないので内容については推測できませんが、ブログは時系列で更新していくので割と理にかなっていると思います。特にテクノロジーなど陳腐化の激しい分野を扱う際、URLから書かれた時期を把握できることは重要です。(テクノロジー系のブログエントリなのに書かれた日付がどこにも表記されてなくて怒りに震えることはよくあることです)

難点は、この形式では一日に最大一エントリしか扱うことができないことです。時刻の2桁まで入れれば一時間に最大一エントリになりますが、パッと見てそれが時刻であると認識できる人は少ないと思いますので、思い切って時分秒まで入れた方が良いかもしれません。

https://yagi.tc/2017/10/16/12/00/58/
または
https://yagi.tc/20171016120058/

作家の結城浩さんは自らの文章をまとめるのに以下のようなURL形式にすることを検討しているようです。

以前から結城はタイムスタンプを使った14桁の数が大好きです。 14桁の数というのは「2017年10月31日12時34分56秒」なら、 20171031123456のことです。

いろんな文章をネットのあちこちに書いていても、 作成日時をもとにした14桁の数ならば、 散らばらずにぎゅっと集約できます。 そして、

 hyuki.org/20171031123456

のような形で、自分の活動へのリンクとできないだろうか。 結城は「仕事の集約」をそんなイメージで描いているのです。

結城浩の「コミュニケーションの心がけ」2017年10月31日 Vol.292

同じ形式ですね。

なお、一般的にはスラッグの代わりにエントリIDを用いたパーマリンク

https://example.com/789/
または
https://example.com/?p=789

も見かけますが、万が一CMSを変更した場合にIDが変わる可能性があることから、あまり推奨できません。

3-2-3. バージョン番号を付ける構成

APIでよくあるURIにバージョン番号を付けたものがあります。

https://www.googleapis.com/upload/drive/v2/files/fileId

これを応用すればバージョン番号ごとに異なるパーマリンク体系を採用できるので長期間の運用に耐えられるのでは……と思いましたが、結局後方互換性を残すために全バージョンでCMSを運用し続けないとパーマリンクとして機能しないので、運用コスト的に現実的ではなさそうですね。HTMLファイルをパブリッシュするタイプのCMSではアリかもしれません。

3-3. より踏み込んだ議論

長期間の運用を前提にする場合、上記以外にもパーマリンクを構成する要素はなるべく普遍的なものを使用するのが良いと思います。
以下は要素として挙げるのみで、具体的な議論は行いません。

  • 自然言語の選択
    • 英語以外のURLがメジャーになる可能性があります
  • マークアップ言語の選択
    • https://example.com/example.html より https://example.com/example/ が好ましいです
    • 現在はHTMLですが、XML等の形に置き換えられる可能性があります
  • ドメインの選択
    • ランニングコストが安く、メジャーなgTLD/ccTLDが適しています
    • サーバ運用上/メールアドレス運用上、タイプする量が少ない方が好ましいです
  • サブドメインの選択
    • https://www.example.com/ より https://example.com/ が好ましいです
  • スキームの選択
    • 現在はhttpからhttpsに移行しつつありますが、ポストhttpsが今後出てくる可能性があります

4. おわりに

長くなりました。

結論としては、スラッグ形式とタイムスタンプ形式を組み合わせた以下のような形式でいこうと思います。

https://yagi.tc/2017/always-on-ssl/

以上

Pocket

独自ドメインのWordPressを常時SSLに変更する際の注意点

2017-10-24 20:26 | 技術

先日このサイトを常時SSL(AOSSL、または常時HTTPSとも)に対応させました。いろいろと知見がありましたのでまとめておきます。

要点

私は今回以下のことを実施しました。

  • Apacheからnginxへの変更とconfigの書き直し
  • Let’s Encryptの導入
  • HSTSの導入(※必須ではない)
  • ドメインのネームサーバの変更(※必須ではない)

それによって得たTips/注意点は大きく以下のとおりです。

  • SSL/TLS対応状況確認について
  • nginxのconfigについて
    • “/.well-known/acme-challenge/”へのルールを設定しよう
    • HSTS設定を有効にするのは最後にしよう
    • SSL/TLSプロトコルバージョンの指定はよく確認しよう
  • Let’s Encryptの導入について
    • 試行錯誤は”–test-cert”オプションを使おう
    • cron実行時に”–force-renewal”指定は避けよう
  • WordPressについて
    • 混在コンテンツのデバッグにはSearch Regexなどのプラグインが便利
    • 混在コンテンツを許容する場合はネットワークパス参照が使える
    • ソーシャル連携では「いいね」数やブックマーク数の引き継ぎ対応が必要
  • ネームサーバについて
    • 今後証明書を発行するならCAAレコードが必須になりそう

SSL/TLS対応状況確認について

確認のための便利なサイトがあります。

SSL Server TEST
https://www.ssllabs.com/ssltest/

このように、うまく対応できていれば「A+」の結果になります。

nginxのconfigについて

nginx1.12+PHP7.1環境において、nginxのconfファイルは最終的に以下のようになりました。
(一部改変しています)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
server {
    server_name example.com;
    listen 80;
    listen [::]:80;
    root /var/www/html;
 
    # Let's Encryptで使用するディレクトリ
    location ^~ /.well-known/acme-challenge/ {
    }
 
    # Let's Encryptで使用するディレクトリそのものには404を返す
    # (つまり配下に実在するファイルのみ200を返す)
    location = /.well-known/acme-challenge/ {
        return 404;
    }
 
    # 上記以外のすべてをHTTPSにリダイレクトする
    location / {
        return 301 https://$host$request_uri;
    }
}
server {
    server_name example.com;
    listen 443 ssl http2;
    listen [::]:443 ssl http2;
    root /var/www/html;
 
    location / {
        index index.html index.php;
        try_files $uri $uri/ @wordpress;
    }
 
    location ~ .php$ {
        try_files $uri @wordpress;
        fastcgi_pass unix:run/php/php7.0-fpm.sock;
        fastcgi_index index.php;
        fastcgi_param SCRIPT_FILENAME $document_root/$fastcgi_script_name; 
        include fastcgi_params;
    }
 
    location @wordpress {
        fastcgi_pass unix:run/php/php7.0-fpm.sock;
        fastcgi_index index.php;
        fastcgi_param SCRIPT_FILENAME $document_root/index.php; 
        include fastcgi_params;
    }
 
    charset utf-8;
    access_log /var/log/nginx/access.log;
    error_log  /var/log/nginx/error.log;
 
    # Let's Encryptで設置されたファイル
    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem; 
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
 
    # HSTSの設定(最大365日間は常時リダイレクトする)
    add_header Strict-Transport-Security 'max-age=31536000; includeSubDomains; preload';
 
    ssl_session_cache shared:SSL:1m;
    ssl_session_timeout 5m;
 
    # プロトコル設定など
    ssl_protocols SSLv2 SSLv3 TLSv1 TLSv1.1 TLSv1.2;
    ssl_ciphers HIGH:!aNULL:!MD5;
    ssl_prefer_server_ciphers on;
}

基本的にはこのコピペでいけると思いますが、初めてnginxの表示を確認するなど常時SSLがまだ始まっていないときは以下の行(19、53、54、57行目)をコメントアウトしてください。

17
18
19
20
    # 上記以外のすべてをHTTPSにリダイレクトする
    location / {
        return 301 https://$host$request_uri;    }

まず19行目。当然ながらnginxインストール直後でHTTPでの表示を確認したい場合はここをコメントアウトしてリダイレクトを無効にしてください。

52
53
54
    # Let's Encryptで設置されたファイル
    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;     ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

その場合、まだ53~54行目のファイルが存在していないので(19行目が無効であっても)エラーになりnginxが起動できません。あわせてここもコメントアウトしておいてください。Let’s Encryptのcertbotを起動しファイルが作成されたらコメントインしてHTTPSでの表示確認を行ってください。

56
57
    # HSTSの設定(最大365日間は常時リダイレクトする)
    add_header Strict-Transport-Security 'max-age=31536000; includeSubDomains; preload';

57行目は常時SSLを実現するHSTSの設定です。HSTS(HTTP Strict Transport Security)はHTTP接続を強制的にHTTPSへリダイレクトし、以後はすべてHTTPSで接続する機能です。上記では1度接続したら最大365日間(31536000秒間)HTTPSを使い続ける設定になっています。HTTPSの表示確認中の段階ではこの行はコメントアウトしてください。でないと手元の表示環境でHSTSが効いてしまい、一度HTTPSで表示したページをHTTP表示に戻したい場合などにうまく表示されなくなってしまいます。都度ブラウザのキャッシュをクリアするか、最後の最後にコメントインするようにしてください。

includeSubDomainsの指定はサブドメインにもHSTSが適用されるようにするための設定です。preloadはプリロード登録のためのものです。今のところ私はプリロード登録をしていませんがいちおう残しています。

HSTSの設定についてはこちらのページも参考になります。

常時SSL化(https)するときのHSTS設定の方法と注意点
http://tuono034s.com/web-entry/2310/

それから、63行目のプロトコル指定はnginxのバージョンによりますので確認して指定してください。2017年10月現在、最新バージョンのnginxにおいてTLS1.3はドラフト版のみの対応となっており、厳密には以後の動作保証ができないため外しています。

Let’s Encryptの導入について

導入方法については他のサイトを参照するとして、まだ試行錯誤段階である場合はcertbotの実行時に”–test-cert”オプションを付けてテストサーバに接続するようにしてください。メインサーバの方には一定期間内の接続回数に上限があり、何回か繰り返すと弾かれます。

テストサーバでテスト用証明書を取得した後、証明書をそのままにしてメインサーバへと接続すると、既にある証明書を置き換えるかどうか尋ねられるので自動実行の際は注意してください。

また、certbotのrenewコマンドをcronで実行する時は”–force-renewal”オプションを使わないようにしましょう。Let’s Encryptのサーバに不要な負荷をかけることになります。

以下のページも参考になります。

Let's encrypt運用のベストプラクティス – Qiita
https://qiita.com/tkykmw/items/9b6ba55bb2a6a5d90963

WordPressについて

WebサーバだけをHTTPS対応させても、読み込むコンテンツ(JavascriptやCSS、iframeなど)がHTTPだと混在コンテンツ(Mixed Content)となり、ブラウザで警告が出ます。これらを取り除くためにはブラウザの開発者ツール機能などを利用しながら一つ一つ取り除いていく必要があります。

読み込み元によっては “http://example.com” を “https://example.com” に置き換えればよいだけのものもありますし、URLが変わるために丸ごと書き換えが必要なものもあります。

特定のサービスを利用しているなどで一括置換できる場合は、Search Regexなどのプラグインを利用するのがよいでしょう。正規表現が使えますし、置換前後を確認しながら置換していくことができます。

これらのツールはエントリ内などで内部リンク(aタグやimgタグ)を絶対指定で行っている場合の置き換えにも使うことができます。便利。

もし常時SSLを行わない場合で、あるページがHTTPでアクセスされるかHTTPSでアクセスされるか一定しない場合、埋め込まれたリソースを「src=”http://example.com~”」などと指定して読み込んでしまうとブラウザで警告が出ることがあります(混在コンテンツ)。この場合はネットワークパス参照を使用してURIスキームを省略し、「src=”//example.com~”」などと指定することで、ブラウザ側で読み込み元ページのURIスキームに合わせて解釈してくれます。あまり見ない記述方法ですが、RFCに準拠した方法であり、最近のブラウザでは正しく動きます。もちろんこの場合、どちらのURIスキームであっても埋め込みリソースに正常にアクセスできる必要があります。

常時SSLを行うとURLが変わるため、ソーシャル連携していた場合「いいね」数やはてブ数が引き継がれません。特殊な対応が必要になります

ネームサーバについて

今は必須ではありませんが、今後SSL/TLS証明書の取得には、第三者による発行を防止するためドメインのネームサーバにCAAレコードを設定するよう求められるようです。CAAレコードについての解説は以下が分かりやすいです。

DNS CAA レコード設定について – さくらのサポート情報
https://help.sakura.ad.jp/hc/ja/articles/115000139062-DNS-CAA-レコード設定について

現在CAAレコードに対応しているDNSサービスは少ないですが、HTTPS化の流れとそれに伴うCAA必須化の流れに乗って今後続々と対応が進むでしょう。私の場合はGoogle Cloud DNSを使用して有料で運用しています。

Pocket

Vivaldiのキーボードショートカット設定を晒す

2017-10-22 12:52 | 技術

Vivaldiはキーボードショートカットのカスタマイズが柔軟にできるので、私は設定をかなり変えています。誰かの参考になればと思い設定をここに晒します。

赤太字はカスタマイズした部分。マウス操作を伴うので特に左手部分に手を入れています。

シングルキーのショートカットは有効にしている前提。
(有効にすると誤入力時に干渉することがあるので注意)

コマンド 操作 説明
Q
F2
クイックコマンド
一発でURL入力やWeb検索ができる。ショートカットを忘れたときやブックマークを開くのにも使う
Ctrl+F1
ショートカットキーのチートシート
ショートカットを忘れたときのお助けコマンド
Alt+P
設定
カスタマイズする際にはよく使う
Ctrl+0
ズームのリセット
誤爆などで間違えて拡大縮小した場合に使う
F11
全画面表示
dマガジンで雑誌を読むときなどに特に使う
Ctrl+F11
UIを表示/非表示
タイトルバー以外を非表示にする/元に戻す
Ctrl+[
F4
パネルを表示/非表示
パネルを出したり引っ込めたりする
Ctrl+Shift+B
ブックマークパネル
ブックマークページはCtrl+B
Ctrl+Shift+D
ダウンロードパネル
Ctrl+Shift+H
履歴パネル
履歴ページはCtrl+H
Alt+1
Webパネル1
Google翻訳パネルを割り当てている
Alt+2
Webパネル2
Instapaperパネルを割り当てている
Alt+3
Webパネル3
Facebook Messengerパネルを割り当てている
Alt+4
Webパネル4
Twitterパネルを割り当てている
T
Ctrl+T
新しいタブ
そこそこよく使う
C
タブの複製
cloneの”C”
Ctrl+W
タブを閉じる
一番よく使う
Ctrl+1~9
1~9番目のタブに切り替え
2
次のタブ
どちらかというとCtrl+TAB、Ctrl+Shift+TAB、Ctrl+1~9で移動することの方が多い
1
前のタブ
Ctrl+Shift+S
現在のタブをセッションとして保存
開いているタブを全部まとめて一旦保存。便利
Ctrl+Shift+O
保存されたセッションを開く
上記で保存したタブを開く
Ctrl+P
F7
パネルにフォーカスを移す
パネルを閉じる(Ctrl+[)と合わせて使うのでキーも隣り合わせにしている
Ctrl+I
F8
アドレスバーにフォーカスを移す
ページにフォーカスを移す(Ctrl+O)と合わせて使うのでキーも隣り合わせにしている
Ctrl+O
F9
ページにフォーカスを移す
アドレスバーにフォーカスを移す(Ctrl+I)と合わせて使うのでキーも隣り合わせにしている
Shift+G
ページ最下部へスクロール
viに準拠
G
ページ最上部へスクロール
viに準拠
/
.
Ctrl+F
ページ内検索
viに準拠
Z
戻る
一番連打するコマンド
X
進む
W,A,S,D
Shift+↑←↓→
空間ナビゲーション
(上、左、下、右)
H,J,K,Lを使ったvi風にするか迷ったが、左手で使いやすいデフォルトのまま
Ctrl+Q
キーボードショートカットを無効に
Webページにキーボードショートカットが設定されているときなど、一時的にショートカットを無効にしたいときに使う。当然ながらショートカットの再開は設定画面を開かなくてはならない
Ctrl+L
パスワード保管庫を開く
※拡張機能

参考

Vivaldiの設定晒し · GitHub
もっと快適にVivaldiが使えるおすすめの設定
Vivaldi WEBパネルの活用方法まとめ #VivaldiJP

Pocket

私がヘビーユースしているストアアプリ5つ

2017-10-11 21:32 | 技術

私がヘビーユースしているWindowsのストアアプリを5つ紹介します。Windows8の混乱で嫌われがちなストアアプリだけど、便利なものもあるんだよということを伝えたい。

Microsoft To-Do

https://www.microsoft.com/ja-jp/store/p/microsoft-to-do/9nblggh5r558

MicrosoftのTo-Do管理アプリ。無料。シンプルで機能が少ないがMacrosoftの製品らしからぬ分かりやすさがあって使いやすい。

マルチOSに対応していてMicrosoftアカウントでサインインすればどの環境でも最新の状態で使える。Web版もある。日付が変わると「レビュー」をするようにメッセージが出て(延期することもできる)、前日にできなかったタスクを翌日に持ち越すかどうかを選ぶことができる。この思想は私にピタリとハマったので、うまく運用できている。

このアプリを開発したチームは元々Wunderlistという別のToDo管理アプリを開発しており、Microsoftが買収したため新たに機能を取捨選択したこのアプリが開発されたという経緯がある。

Pico Viewer

https://www.microsoft.com/ja-jp/store/p/pico-viewer/9wzdncrdr0gm

高機能なPDFリーダー。300円。特にコミックを読むのに適している。私がPDFに求める主要機能、

  • 見開き表示ができる(表紙を含むか除外するかも選べる)
  • 綴じ方向(右開き左開き)をファイルの設定を無視して指定できる
  • PDF標準のしおり(インデックス)が使える
  • マウススクロールでページめくりができる
  • 矢印キーでページめくりができる

をすべて満たしている。さらにネットワーク上のフォルダを本棚に指定することもできるので、NAS上のPDFをまとめて読んだりするのに重宝している。ガンマ補正やコントラスト補正を備えるなど高機能で、設定項目・カスタマイズ項目が多いのもGood。

Token2Shell/MD

https://www.microsoft.com/ja-jp/store/p/token2shell-md/9nblggh2ncx9

綺麗なSSHクライアント。3500円。デフォルトのフォントが特に美しい。洗練されたUIでありながら、マルチタブ、秘密鍵管理、known hosts管理、キーパッド、マクロ機能などを備えていてヘビーユースに耐える。

リモート デスクトップ

https://www.microsoft.com/ja-jp/store/p/microsoft-リモート-デスクトップ/9wzdncrfj3ps

Windows標準のリモートデスクトップ(mstsc.exe)のストアアプリ版。無料。長らくコピペができないなどmstsc.exeに比べて機能が劣っていたが、現在は同等の機能を実現できている。見栄えが良いのと、ときどき自動アップデートされる(バグフィックス?)のでこちらを使っている。

Fresh Paint

https://www.microsoft.com/ja-jp/store/p/fresh-paint/9wzdncrfjb13

Microsoftのドローアプリ。私はペン付きタブレットPC(VAIO Z Canvas)を使っていて、お絵描きをすることがあるので気軽にやりたいときは機能の少ないこのアプリを使っている。レイヤー機能や補正機能はなく、ただキャンバスにペンで描くだけという分かりやすさで重宝している。

ストアアプリ以外でヘビーユースしているもの

Vivaldi
高機能なブラウザ。キーボードショートカットをカスタマイズできる点と、タブを左側に表示できる点が気に入っている。これについては別エントリに書きたい。

Evernote
ノート管理アプリ。作業中のノートはすべてここで管理している。

OneDrive
クラウドストレージ。作業中のドキュメントや絵はここで管理している。

Snipping Tool
Windows標準で付いている画面キャプチャアプリ。こういったブログに載せる画像はこのアプリを使ってキャプチャしている。

WinSCP
OneDriveやboxといったクラウドストレージのファイルを手っ取り早く動かしたいときは純正アプリを使わずにWebDAVを使った方が楽なため、このアプリを使っている。

PC TV Plus
nasneクライアント。TV番組はこれで見る。

ATOK
IME。かれこれ20年くらい使い続けている。

Pocket

Evernoteに編集ロックがないと嘆く前に

2017-09-25 19:00 | 技術

MarxicoというサービスがEvernoteの編集ロック機能として使えますよという話と、共有ノートにすることでも読み取り専用にできますよという話です。

Marxicoで手っ取り早く読み取り専用にする

MarxicoはMarkdownでEvernoteのノートを読み書きできるWebサービスです。
(有料:$15.99/年)

このサービスを使うと、このようにノートを読み取り専用にできます。

ひとまずMarkdownのことは気にせずに、あなたのEvernoteの既存ノートを手っ取り早く読み取り専用にしてしまいましょう。10日間無料ですのでレッツトライ。

手順

https://marxi.co/ にアクセスして、Profileをクリックします。

右側にLink with Evernoteと表示されるので、それをクリック。

EvernoteアカウントのIDとパスワードを入力します。二段階認証を有効にしている場合はそのトークンを入力します。

「Marxicoがアカウントにアクセスすることを許可しますか?」と出るので「承認」をクリック。

右下に”Successfully link with Evernote”と表示されて元の画面に戻ります。
続いてNew documentをクリック。

画面が空白になるので、Evernoteの任意のノートをコピーして貼り付け。

“Local draft. Click to sync.”アイコンをクリック。しばらくするとアイコンがチェックマークに変わります。これでEvernoteに保存できました。

Evernote側を見ると、先ほどのテキストが「Untitled」という名前で保存されています。右上には鍵マークが表示され、マウスオーバーすると「読み取り専用」と表示されます。これで編集ロック完了です。

再び編集する場合は右上にある赤い栞マークをクリックするとブラウザで編集画面が開きます。またはMarxicoを開いて左側に出てくるメニューから編集することも可能です。

「Untitled」となっているノート名はそのまま変更しても構いませんし、Markdownで見出しを作ってやると一番上の見出しが自動的にノート名に設定されます。

MarxicoはWeb版のほか、Windows/MacOSに対応したデスクトップアプリ版、Chromeアプリ版もあります。

Marxicoの難点

Marxicoを使った方法の難点は有料であることです。$15.99/年かかります。

もうひとつ難点があります。複数環境でのシームレスな編集が意図されていないことです。たとえばPCで編集して保存した後、モバイルで編集しようとすると編集できません。一旦PC上でログアウトし、モバイルでEvernote連携の承認をし直す必要があります。

Evernote連携の仕様上一度にひとつの環境でしかログインすることができないようで、しかもMarxicoはローカル処理で完結するしくみ(おそらくセキュリティ的な理由)なのでこのようになっています。

しかしこれで意図しない編集で最終更新日が変わったり、ノートの並び順が変わったり、レイアウトがどんどん崩れていったりといった問題からは解放されます。

共有ノートに設定する方法

Evernoteのみを使って編集ロックする方法としては共有ノートにする方法があります。ノートの共有用リンクをコピーしてブラウザで表示させれば、読み取り専用になったノートが表示されます。

ただしノートがWeb上に公開されるため、公開されても問題のないときにこの方法を使うようにしましょう。

なぜか知られていないこの方法

どういうわけか(少なくとも日本語圏においては)これらの方法は知られていないようです。

Evernote (編集ロック OR 編集不可 OR 読み取り専用 OR 閲覧専用) – Google 検索

おわりに

以上2つの方法をご紹介しました。他にも方法をご存じの方がいましたら情報を頂けるとありがたいです。

Pocket

DIYでスマートハウスを作る私のアイデア集

2017-09-24 14:38 | 技術

以前、Raspberry Pi 2を使った我が家の自動化システムを紹介しましたが、他にもやりたいことがたくさんあります。IoTコンピュータを活用したい方の参考になればと思い私のネタ帳というかToDoリストを公開します。

Raspberry Pi や Intel Galileo といったシングルボードコンピュータでできる範囲で書いていますが、他にも Arduino、Intel Edison、BeagleBoard/BeagleBone、Espruino、Tessel、mbed といったものでも実現可能なものがあると思います。Node-RED なんかで実現しても楽しいと思います。
続きを読む »»

Pocket

Raspberry PiでMastodonインスタンスを立てる方法(1.3.3対応版)

2017-05-24 17:53 | 技術

うちで動いているRaspberry PiをMastodonインスタンスにしようと試行錯誤しているのは先日書いたとおりなのですが、最終的にうまくいったので手順を公開します。

手順は入れたばかりのまっさらなRaspbian Liteを想定しています。
続きを読む »»

Pocket

Raspberry Pi 2でMastodonインスタンスを立てようとして失敗した件 その2

2017-04-29 21:22 | 技術

うちで動いているRaspberry PiをMastodonインスタンスにしようと試行錯誤しているのは先日書いたとおりなのですが、トップページを確認できるとこまでいったので手順を公開します。でも最終的にはやっぱり失敗していますので不完全です。

手順は入れたばかりのまっさらなRaspbian Liteを想定しています。
続きを読む »»

Pocket

Raspberry Pi 2でMastodonインスタンスを立てようとして失敗した件

2017-04-24 22:45 | 技術

うちで動いているRaspberry Pi 2をMastodonインスタンスにしようと画策してみたのですが、docker-compose buildが動いてくれず失敗しました。需要があるのか分かりませんが、ひとまず失敗したところまでの手順を公開します。

はじめはaptで入れた古いdockerとdocker-compose(x86_64用)でうまくいかず、ARMアーキテクチャ上ではx86用を流用してもうまくいかない、Raspbianではdebian用を流用してもうまくいかないことを知って調べて最終的に一番確度の高そうな手順が以下になりました。

でも動かなかったんですけどね。
続きを読む »»

Pocket

 1 2 3 4 5 6 7 8 Next

人気の記事

このページについて

yagitchの日本語練習帳です。本のレビューとか技術的なメモとか。詳細≫

過去の記事

キーワードから探す

一覧から探す

年月から探す

分類から探す