にせねこメモ

はてなダイアリーがUTF-8じゃないので移ってきました。

耳を塞がないイヤホンambieを一ヶ月でぶっ壊してしまった話

はじめに

前にHoloLensを体験したとき、着用している人には音声が聞こえるが、それ以外の周りの人にはその音が聞こえないという状態を体験した。
このような、自分にだけ音が聞こえて、かつ周りの音を聞くことを阻害しないイヤホンあるいはヘッドフォンのようなものがあればなあと思い、探していると、Ambie sound earcuffという耳を塞がないイヤホンが去年から発売されていたことを知った。
今年の3月、ヨドバシカメラの店舗で視聴してみて、いい感じだったのですぐ買ってしまった*1

感想

一ヶ月ほど使ってみた上での感想は、日常生活に自分だけのBGMを重畳する、という感覚がすごくよかった。

メリットとデメリットを挙げる。

利点

  • 耳を塞がないので周りの音が聞こえ、これが自分だけに聞こえるBGMといった感じでとてもよい。散歩するにも周りの音が聞こえるので気楽。
  • 耳を塞がない構造から、しばらく聞いていてもあまり疲れない。ただし耳のそばで鳴っているわけなので、全く疲れないわけではない。
  • イヤホンでありがちなコードが擦れる音がしない。

欠点

  • 周りの音が聞こえるといっても耳元で音を鳴らしている分、小さな物音とかは聞こえなくなる。あと周りの音がどこからするのかといった周囲の音の定位が曖昧になる気がする。
  • 大きな音を出すと音漏れはする。なので、静かな図書館とかで使うには向かない。
  • BGM感覚で聞いているとつけていることを忘れるので、机に置いたスマホに接続して聞いてた時に立ち上がったり後ろ向いたりしてスマホを落っことすことが何回もあった。散歩とかしてる場合は問題ないのだけれど。
  • イヤーピースが簡単に外れるようになっていて、油断するとなくす。鞄とかに雑に突っ込んでおくと次に取り出した時にはなくなっていたりする。

f:id:nixeneko:20180506110943p:plain

結局最後は足でコードを踏んづけたまま引っ張ってしまったために、イヤホンのプラグが破損してしまった。
f:id:nixeneko:20180506110612p:plain
まだ一ヶ月しか使ってないのに…。有線は散歩にはいいが作業用には危ないように感じた。

自分で修理

さすがに一ヶ月しか使用してないのにこれは参ってしまった。引っ張って壊れたため保証による無料修理も効かないだろうと判断して、プラグ部分を入れ替えて何とか自分で修理しようとした。

f:id:nixeneko:20180506111142p:plain
プラグの辺りで切断し、被覆を剥くと銅色のものが2本あり、片方は白で被覆されたマイク線が中心に入っている。銅色はGND、緑と赤がLとRの信号線である。緑がL、赤がRだったと思う。
白色の線を取り出し、銅色のものはまとめてしまってGNDとする。イヤホンの銅線はリッツ線という名前らしく、絶縁の為に塗料がついているので、ライターで炙って先端を溶かし、紙やすりで磨いたりした。
f:id:nixeneko:20180506112436p:plain
初めはこれを汎用的なプラグにはんだ付けすればいいと思ったのだが、はんだ付けが細かく、かつ絶縁が難しそうだったので一度あきらめた。


その後、別の(生きている)プラグ付きのケーブルがあったので、切断して導線の被覆を剥き、イヤホンの導線とはんだ付けして繋げることでイヤホンとしての機能を復活させた。この時、接続の前に絶縁のため熱収縮チューブを通しておき、テスターでどの線がプラグのどの位置に来るかを調べ(プラグの先端からL, R, GND, Micを接続する)、それに従って線をよじってつなげ、ちゃんと音が出るかをはんだ付け前に確認している。
f:id:nixeneko:20180506112755p:plain
はんだ付けが上手くいかずてこずった。一応繋がってはいるので良しとしたが、素人仕事なので問題があるかもしれない。(繋がった導線は余分な部分を適当な長さで切っといた方が良かった気がする)。

あとは熱収縮チューブを2重にして、内側に一本ずつチューブで挟むことで絶縁をした。最良ではなさそうな気もするが一先ず動いてるのでよしとした。
f:id:nixeneko:20180506114700p:plain
f:id:nixeneko:20180506114910p:plain
熱収縮チューブはライターで炙って縮ませた。外側の導線がはみ出てるやんけ……別の信号の導線同士でショートしてはないようなのでまあいいかという感じ。音もちゃんと左右分離して出るし、リモコン操作も動く。

おわりに

ところが今年2018年4月にBluetooth無線版の物が発売されていたらしい。注文してしまって届いた。
f:id:nixeneko:20180512212846p:plain
充電が必要なのは面倒ではあるのだが、2時間半ほど充電して6時間ほど持つらしい。作業中にコード引っ掛けることもなさそうだし、よい。あと、イヤーピースが外れづらい構造になったのもよい。

*1:2018年5月現在では無線版も発売されているが、当時は有線版しかなかった。

粉末状完全食・日米対決: COMP vs. Soylent飲み比べ

f:id:nixeneko:20180407222131p:plain

完全食について

完全食とは、健康を維持するために必要な栄養をすべて含んだ食品のこと。ここでは、SoylentとCOMPをとりあげる。


Soylentという、食事を代替することを目的とした粉末状の食料がある。粉末のプロテインのように水などに溶かして飲む。2013年にアメリカでクラウドファンディングが実施され、2014年から最初の商品であるSoylent v1.0が出荷された。

公式の通販サイトでは日本への発送はしていないのだが、このたび知人がアメリカに行くとのことだったので、お土産にSoylentをリクエストしてみた。


COMPはSoylentの日本版とでもいうべきものであり、Soylentが日本への配送を行っていないことが開発の一つのきっかけであったらしい*1
成分についても、日本の厚生労働省が出している必要な栄養素を元にしていて、材料も日本で手に入るものに変えているとのことである。

実食

実際に飲み比べたのは

  • COMP v.4
  • Soylentのformlula v.1.8

である。食品なのにバージョン表記がなされているのが工学っぽい。

見た目比較

f:id:nixeneko:20180407224215p:plain
左がCOMP、右がSoylentである。

  • 粉の色: Soylentの方が黄色っぽく、COMPの方は白っぽい
  • 体積ベースで、粉:水=1:1になるようにシェーカーに投入し、振り混ぜた。
  • 液体の色: 混ぜた後の液体の色としてはほとんど変わらないが、Soylentの方がやや白っぽい

飲み比べ

f:id:nixeneko:20180407222802p:plain

COMP V.4
  • きな粉っぽさが強い
    • 全体として粉っぽさがあり、舌触りがざらざらしている
  • シナモンの香りがする
  • 甘く、飲みやすい
    • なんとなく、飲む八つ橋といった感じもある

COMPはv.3時代に購入して飲んでたのだが、v.3は豆乳臭さが残っていた。それに比べて、v.4は初めて飲んだのだが、凄く飲みやすく、おいしくなっていて驚いた。

Soylent v1.8
  • 塩味が強めに感じられる
  • 甘味もあるが、薄めな気がする
    • 全体として、「甘い」というより「しょっぱい」という印象
  • 液はなめらかであり、粉っぽさはないが、噛むとじゃりじゃりした感覚が少しある。

COMPと比較するとしょっぱさが際立つという感想だったが、Soylent単体で飲んでみたところ、そこまでしょっぱさが気になる訳でもなかった。味の雰囲気を牛乳に近づけているような気がする。
(2018-04-16追記)濃いめだと「しょっぱい」という印象だったが、もう少し水で薄めると塩味も気にならなくなり、さらに薄めると豆乳っぽさが感じられた。(追記終)


全体として、以前自分がCOMP v.3を飲んでたための慣れもあるのだろうけれど、COMP v.4の方がSoylentより飲みやすく感じた。

成分量比較

甘味や塩味について、400kcalあたりの分量で比較してみると、

ナトリウム 炭水化物 食物繊維 糖質
Soylent 320mg 39g 5g 34g
COMP 264mg 59.3g 4.3g 55g

となっている。

ナトリウムについてはCOMPは少なめになっている。これはナトリウムの基準量は上限であり、他の食事で多めに摂取されることが予想されるからだろう。逆に糖質についてはCOMPの方が多い*2。これらは実食したときの味の感覚と合っているように思う。

*1:食に関心のないミレニアルが「完全食」で半年生活してみた | BUSINESS INSIDER JAPAN

*2:とはいえ、甘さに寄与しない糖質もあるし、糖質以外でも甘さをもつものもあり(人工甘味料など)、甘味への寄与は何ともわからない。

Ubuntu 16.04でgooglei18n/fontviewをビルド

OpenTypeのvariable fontが発表され、デモフォントとvariable font対応のフォントビューアが公開された。そのフォントビューアがgoogle18n/fontviewである。

たぶん最初の対応ビューアなので、variable font開発でも確認に使われているだろうと思われる。

これは、主にMac向けらしい(Mac向けバイナリも配布されている)が、Linuxでもビルドできるようなので、メモしておく。なお、一筋縄ではいかない模様。

環境

依存するライブラリ等のインストール

さて、README.mdを読んでいくと、次のような記述がある。

Building on Linux

You need to first install wxWidgets as well as latest versions of FreeType, HarfBuzz and FriBiDi.

https://github.com/googlei18n/fontview

これに従って、wxWidgets, FreeType, HarfBuzz, FriBiDiをインストールしていく。

wxWidgets

sudo apt install libwxgtk3.0-dev

FreeType

コンパイル面倒なのでStefan GlasenhardtによるPPAレポジトリを追加して入れる。

sudo add-apt-repository ppa:glasen/freetype2
sudo apt update
sudo apt install libfreetype6-dev

入ったバージョンは2.8.1。

HarfBuzz

harfbuzz/BUILD.md at master · harfbuzz/harfbuzz · GitHubに従ってインストールする。

sudo apt install libicu-dev libcairo2-dev libgraphite2-dev gcc g++ libfreetype6-dev libglib2.0-dev libcairo2-dev
wget https://www.freedesktop.org/software/harfbuzz/release/harfbuzz-1.5.1.tar.bz2
tar xvf harfbuzz-1.5.1.tar.bz2
cd harfbuzz-1.5.1
./configure
make
sudo make install

FriBiDi

リポジトリに入っているバージョンが0.19.7だったので、そのままリポジトリから入れてしまう。

sudo apt install libfribidi-dev 

Raqm

fontviewが必要とするのでこれも入れる。

sudo apt install libglib2.0-dev gtk-doc-tools
cd ~
wget https://github.com/HOST-Oman/libraqm/releases/download/v0.5.0/raqm-0.5.0.tar.gz
tar xvf raqm-0.5.0.tar.gz
cd raqm-0.5.0
./configure
make
sudo make install

FontViewのインストール

cd ~
sudo apt install git
git clone https://github.com/googlei18n/fontview.git
cd fontview/src/fontview
g++ *.cpp --std=c++11 `pkg-config --cflags --libs harfbuzz freetype2 fribidi raqm` `wx-config --cflags --libs` -o fontview

すると、~/fontview/src/fontview/fontviewにバイナリが生成される。コンパイルコマンドはREADMEの方法と異なっているので注意。

適当にパスの通ったところにコピーしておく。

cd ~
mkdir bin
cp fontview/src/fontview/fontview bin/

再起動する。

テスト

Adobeのvariable fontのプロトタイプをダウンロードして動作を確認してみる。

cd ~
wget https://github.com/adobe-fonts/adobe-variable-font-prototype/releases/download/1.003/AdobeVFPrototype.ttf
fontview AdobeVFPrototype.ttf

f:id:nixeneko:20180406232134p:plain
Weight/Contrastを弄ると太さや細い部分がどれだけ細いかを変化させることができる。

平成の次の新元号の文字列を取得するコード

※これはネタですが、エイプリルフールとは無関係です。


まず実用性はないのだが、新元号の文字列を取得するJavascriptコードを思いついたので書いておく。

新元号 = "㋿".normalize("NFKD");

今は何も意味のあるものは得られないが、新元号が発表されてしばらくすれば、最新のブラウザで上記のコードを実行すると新元号を表す文字列が取得できるようになるはずである。

実行例:

何をやっているのか

去年の12月に、日本のNational Bodyから、(「㍾」「㍽」「㍼」「㍻」のように)新元号の合字の独立したコードポイントを、古いITシステムのためにBMP*1に確保してくれという要請が出された。

これに対し、Unicodeコンソーシアムは、U+32FFを新元号として確保するようにした。

つまり、U+32FF “㋿”は新元号が発表された後、(フォントが対応すると)新元号で表示されるようになり、Unicodeにも正式に採録されるだろうと考えられる。
一方でUnicodeは、検索などの利便性のために、Unicode正規化という仕組みを用意している。この仕組みを利用すると、例えば「平成」で検索して「㍻」をヒットさせることができる。正規化の挙動はUnicode Character Database (UCD)として提供されている。

この仕組みを利用して、"㍻"から"平成"が得られる。

heisei = "㍻".normalize("NFKD"); //"平成"が返る

実行例:

同様に新元号“㋿”についても、ブラウザの利用するUCDが新元号の分解に対応したものに更新された暁には、Unicode正規化を利用して新元号を表す文字列が取得できる様になるはずである。


とはいっても、新元号が発表されてからUCDの新版が出るまではラグがあるはずであり、結局はUCDが対応するより前に手動で対応することになるのだと思う。そもそも、UCDの更新を行っていないシステムもあるだろうので、あまり期待しない方がよさそうである。

*1:U+0000~U+FFFF。UTF-16サロゲートペアを使わずに表現できる範囲。

はてなブログ+さくらのレンタルサーバをHTTPS化する

このブログを全面的にhttpsに切り替えたので、何をやったかを書いておく。

経緯

次のページに詳しいが、ブログやWebサイトをhttpsにせずhttpのままで運用していると、不都合があるっぽい:
はてなブログSSL暗号化通信(https)対応問題、10月から起こるかもしれない問題を解りやすく書いてみました。 - 神戸グルメゲリラ


一方ではてなブログは、2017年10月から2018年初頭にかけて、ユーザーが設定することで全面HTTPS化ができるよう実装予定だとのことだった:
はてなブログへの接続をすべてHTTPSにできる機能の実装予定と、利用を検討するユーザー様に準備いただきたいこと - はてなブログ開発ブログ

そして、2018/02/22から、はてなの提供するドメインによるブログ(つまり、独自ドメインでないブログ)のhttpsによる配信ができるようになったとのこと。
はてなが提供するドメインのブログで、HTTPSで配信できる仕組みの提供を開始しました(追記あり) - はてなブログ開発ブログ


記事内でも書かれているが、HTTPSで配信されるページにHTTPで配信されるコンテンツ(CSS, Javascript, img, iframeなど)が混在している場合(mixed content)に問題になる。

ここで、私ははてなブログはてなが提供するドメインで運用しているため、HTTPS配信への移行は簡単に達成できることが予想されるが、一方でWebフォントなどのリソースをさくらのレンタルサーバ上に置いているため、そのHTTPS化を行わないとそれらのリソースは読み込むことができなくなる。

さくらのレンタルサーバSSL

という訳で、ブログで利用するリソースを置いているさくらのレンタルサーバ(ライト)のHTTPS化を行う。

一つの方法として、共有SSLというものをさくらで提供している。これは、設定をするとexample.sakura.ne.jpの形の初期ドメインであればそのままHTTPS化ができるというものである。初期ドメインのまま利用しているばあいはこれを使うのが簡単で良いと思うが、一方でさくらのサブドメインを含む独自ドメインについては共有SSLはセキュリティ的によろしくなく*1、非推奨とのことである。
共有SSL|さくらのレンタルサーバ

他の方法として、独自でSSL証明書を取得して、HTTPS化する方法があるのだが、これは独自ドメインのためのもので、さくらのサブドメインでは使うことができないようである。

結局、今回は共有SSLを設定し、example.sakura.ne.jpの形の初期ドメインで使うことにして、ブログ記事で参照しているURLを書き換えた。
SSLの設定はサーバコントロールパネルから行う:
【共有SSL】設定方法 – さくらのサポート情報

さくらの共有SSLはプロキシとして動作しているため、細やかな設定が難しい場合があるらしい:
さくらのレンタルサーバでHTTPS(SNI SSL)な独自ドメインのWordpressサイトを構築する際の注意点 - Qiita

はてなブログの設定

最終的にはてなブログHTTPS化したのは2018年3月28日であるが、Mixed contentの問題があるため、HTTPで埋め込んでいるものは事前に書き換えておいた。
特にさくらのレンタルサーバSSL化したため、そこに置いていたリソースのURLがすべて変更になったので、はてなブログの記事で参照しているリソースをすべてHTTPSのものに書き換えた。

HTTPS

f:id:nixeneko:20180328231517p:plain
はてなブログダッシュボードの設定を開いたら、HTTPS配信が利用できる様になっていたため、切り替えた。
切替は一度確認が出るくらいで一瞬だった。
f:id:nixeneko:20180328231718p:plain

Mixed content対策

さくらのレンタルサーバに置いてたリソースはHTTPSに移行したが、他に、はてな記法の[~:embed]で埋め込んだものなどがちゃんと読み込めるか記事を見ていって確認する。
Mixed contentがある場合、ブラウザのコンソールにエラーが表示されるらしい。それも参考に潰していく。

サイト自体はhttp配信であるもののoEmbedなどで埋め込まれるページはhttpsで配信しているサービスも多く、割とそのままでもなんとかなる様であった。

mixed contentの制限があるのでhttpで埋め込んでるコンテンツがないか探していく。

  • リンクを張っているのみ→そのままでよい
  • カスタマイズCSSなどで参照している外部ファイル→HTTPSへの対応が必要
  • はてなフォトライフの画像の埋め込み→はてな記法で埋め込んでる限り、はてな側でよしなにしてくれるっぽい。
  • はてなhttp記法[~:sound]で音声ファイルのプレーヤを表示するのはhttpsに対応していないので、HTML5の<audio>タグ等で置き換える。
  • はてなhttp記法[~:embed]で埋め込み→埋め込み先がhttpsに対応していない場合、困るかもしれない。
    • oEmbedによるブログカード等の埋め込みが表示されなくなっていた場合、記事の編集画面を開いて保存し直したら表示される様になったことがある。

埋め込んでいた他サイトの動画やブログカードについて次のような感じであった。次のようなサイトは、URLがhttp://~のままでもはてな記法の埋め込み[http://~:embed]でうまくいった。一旦記事の編集画面を開いて保存し直すと表示されるようになるものもあった。

  • ニコニコ動画: サイトはhttpであるが、埋め込み用のページはhttpsで配信されている。
  • はてなブログ: ブログがhttp/httpsに関わらず、oEmbedで指定された埋め込み用のページはhttpsで配信されている。
  • Qiita: httpでアクセスするとhttpsに飛ばされる。


はてなブログtex記法を使っている場合、mixed content (混在表示コンテンツ)の警告が表示されることがあった。これは、一度記事の編集画面を開いて保存し直すと直るらしい。
はてなが提供するドメインのブログで、HTTPSで配信できる仕組みの提供を開始しました(追記あり) - はてなブログ開発ブログの追記を参照。



とりあえずしばらくは様子見。とはいってもhttpでの配信に戻すことはできないのだけど。

*1:××××.comというドメインであれば、共有SSLのURLは https://secure○○.sakura.ne.jp/××××.com のようになり、他のブログと同一ドメインにまとめられてしまう。

Pleromaのお一人様インスタンスをUbuntu 16.04で立てた作業ログ

https://nixeneko.infoにPleromaのおひとり様インスタンスを立ててみた。
Mastodon等やっている方は、よければ@nixeneko@nixeneko.infoをリモートフォローしてください。
(※20181227追記: この記事は古くなってるので、多分今はそのまま使えません。)

概要

Pleromaという、GNU SocialやMastodon互換のマイクロブログSNSソフトウェアがある。機能としてはTwitterに近い。
これは自分でサーバを用意して動かす(インスタンスを立てる)こともでき、インスタンスが異なっても互いにフォローできる*1ので、自分専用のインスタンスとして使っても問題ない。
Twitterという一企業のサービスに依存しないのも良いなあと思って、VPSを借りて立ててみた。


以降は2018/3/6に作業したログという感じなので、まとまっていないし、現在では変わっている部分もあるかもしれない。

実際に立ててみたい場合には、Pleroma公式Wikiのインストールガイドや次のページなどを参照するとよいと思う。

下準備

  • ドメインを取得した(nixeneko.info)。
  • ConoHaで一番安いメモリ512MBのVPSを借りた。
    • OSはUbuntu 16.04(.4 LTS)にし、SSH用にローカルで作成した公開鍵を登録しておいた(とはいえ、別に作業用のユーザを作成したので後で削除した)。接続許可ポートはすべて許可にした。
  • VPSIPアドレスを確認し、取得したドメインVPSIPアドレスを指すようにドメインのAレコードを設定した。

作業ログ(2018/3/6)

初期設定

上のページを参考にサーバの初期設定を行った。

rootでSSHでログインして(公開鍵を設定してない場合はConoHaのコンソールから作業することになると思う)、ソフトウェアを更新する。

apt update
apt upgrade

と更新したら、設定がリポジトリでインストールしたデフォルトから変更されてるよって言われて置き換えるか聞かれたが、/etc/cloud/cloud.cfgはそのまま残した(これは初回起動時に実行されるものらしいので、たぶんどっちでもよい)。

作業ユーザの追加

rootユーザで

adduser workuser
gpasswd -a workuser sudo

とし、作業ユーザを追加しsudoできるようにした。

su workuser

rootから作業ユーザに切り替える。

sudo: unable to resolve host回避

その後、sudoする度に“sudo: unable to resolve host (ホスト名)”と表示されるので、/etc/hostsに

127.0.1.1       (ホスト名)

を追記したら表示されなくなった。
参考: sudo: unable to resolve host が表示されたら - Qiita

作業ユーザへのSSH公開鍵の設定
cd ~
mkdir .ssh
chmod 700 .ssh
cd .ssh
touch authorized_keys
chmod 600 authorized_keys
nano authorized_keys

authorized_keysにローカルで作成した公開鍵をペーストし保存した。

sshdの設定
sudo nano /etc/ssh/sshd_config

/etc/ssh/sshd_configを開き、ルートログイン禁止とsshのポートの変更を行った。
ルートログイン禁止:

PermitRootLogin no

SSHポートの変更:

Port 10022

以上のように書き換え(sudo sshd -tで構文チェックができる)、sshdを再起動。

sudo service sshd restart
rootユーザに対して追加されていた公開鍵を消す
sudo su root
rm ~/.ssh/ authorized_keys

設定が済んだら作業用ユーザでログインし直す(ポートも変更したものに合わせる)

Pleromaのインストール

公式のWikiに載ってるのに従ってやっていく。

PostgreSQL 9.6のインストール

9.6以上のバージョンが標準リポジトリにないので、PostgreSQLの公式ページに従ってインストールする。

sudo nano /etc/apt/sources.list.d/pgdg.list

以下を書いて保存する。

deb http://apt.postgresql.org/pub/repos/apt/ xenial-pgdg main

その後、次のコマンドを実行してインストールする。

wget --quiet -O - https://www.postgresql.org/media/keys/ACCC4CF8.asc | sudo apt-key add -
sudo apt update 
sudo apt install postgresql-9.6 postgresql-contrib-9.6
Elixir 1.5+

参照: Installing Elixir - Elixir

wget https://packages.erlang-solutions.com/erlang-solutions_1.0_all.deb && sudo dpkg -i erlang-solutions_1.0_all.deb
sudo apt update
sudo apt install elixir
他に必要なものをインストール

他の必要なパッケージをインストールする。

sudo apt install erlang-dev erlang-parsetools erlang-xmerl git build-essential nginx
ユーザ作成
sudo adduser pleroma
sudo usermod -aG sudo pleroma
su pleroma
ソースコードを持ってきて必要なプログラムをインストールしたり設定をする
cd ~
git clone https://git.pleroma.social/pleroma/pleroma
cd pleroma
mix deps.get

Hexをインストールするか聞かれたらyを入力。

設定ファイルを作成
mix generate_config

rebar3をインストールするか聞かれるのでy。
他にも、ドメイン名、インスタンス名、adminのEメールアドレスを入力する。
mediaproxyを有効にするか聞かれ、nとした。

作成された設定ファイルをリネームする。

mv config/generated_config.exs config/prod.secret.exs
データベースの作成・マイグレーション
sudo su postgres -c 'psql -f config/setup_db.psql'
MIX_ENV=prod mix ecto.migrate
起動テスト
MIX_ENV=prod mix phx.server

これで起動するが確かめたらCtrl-Cで停止する。

SSL証明書取得

Let's EncryptでSSL証明書を取得する。(ここらへんよくわかってない)

sudo add-apt-repository ppa:certbot/certbot
sudo apt update
sudo apt install python-certbot-nginx
sudo certbot certonly -d (ドメイン名)

すると色々聞かれるので入力すると、 /etc/letsencrypt/live/(ドメイン名)/ 以下に証明書が生成された。
(Pleromaのサイトによると証明書の取得についてより先にnginxの設定がきているので、その順番でやっていたが、certbot --nginxというふうに証明書を取得しようとしたところ、nginxの設定で指定されている証明書がないよ、とエラーが出て動かせなかった。最初は--standaloneで証明書取得を行った方が楽かもしれない)

nginxの設定

設定ファイルをコピーし、設定を変更する。

sudo cp /home/pleroma/pleroma/installation/pleroma.nginx /etc/nginx/sites-enabled/pleroma.nginx
sudo nano /etc/nginx/sites-enabled/pleroma.nginx

サーバのドメインを指定し、cert pathsも取得した証明書にあわせて修正する。

sudo systemctl restart nginx.service
サービスの設定
sudo cp /home/pleroma/pleroma/installation/pleroma.service /lib/systemd/system/pleroma.service
sudo nano /lib/systemd/system/pleroma.service

/lib/systemd/system/pleroma.serviceを開き、[Service]のところに

Environment="MIX_ENV=prod"

を書き加える。

sudo systemctl start pleroma.service

サービスを起動する。

自分用のアカウントを作る

設定したドメインにアクセスし、自分で使うためのPleromaのユーザを作成する。

登録の停止
nano ~/pleroma/config/prod.secret.exs

を編集し

  limit: 400,
  registrations_open: false

に変更して登録を停止した。またついでに投稿辺りの文字数の上限を何となく400文字とした。

設定の反映・自動起動設定

再起動してPleromaの設定を反映

sudo systemctl restart pleroma.service

Pleromaのサービスを自動起動するように設定

sudo systemctl enable pleroma.service
iptablesの設定

firewall有効化

sudo ufw enable

Ubuntuファイアウォールはデフォルトでufwなのであるが、iptablesの方が設定ファイルの流用がしやすいのでiptables使って設定ファイルを編集した。ufwコマンドで設定する方が筋がいいかもしれない。

このサイトの記述を元に設定を書いたテキストファイル(~/iptables)を作成する。sshのポートをsshd_configで設定したものに合わせて変える。(最終的に、http, https, sshの接続を許可した)

設定を反映し、永続化させる。

sudo iptables-restore < ~/iptables
sudo apt install iptables-persistent

ここで、iptablesの設定の反映は次のコマンドでできるっぽい。

sudo /etc/init.d/iptables-persistent save 

参考: Ubuntuでiptablesの設定をiptables-persistentで永続化する

let'sencryptの自動更新
/usr/bin/certbot renew --post-hook "service httpd restart"

を動かしてみてちゃんと動くか確認する。(証明書取得してすぐだと更新されないが、Cert not yet due for renewalと出れば問題ない)

cronに更新用のコマンドを設定する。

sudo nano /etc/cron.d/letsencrypt

で開き、内容は次のようにする。これは毎週火曜日16時33分に発動する設定になっている。

33 16 * * 2 root /usr/bin/certbot renew --post-hook "service httpd restart"

参考: Let&#39;s Encryptを使ってSSL証明書を自動更新する(AWS/Amazon Linux/Apache) - Qiita

こまごまとした設定

Instance specific panelの表示
nano ~/pleroma/priv/static/static/config.json

  "showInstanceSpecificPanel": true

のようにtrueに変更する。

Instance specific panelの内容の設定は~/pleroma/priv/static/instance/panel.htmlを弄るとできる。

nano ~/pleroma/priv/static/instance/panel.html

として開いて、適当に書き換える。

インスタンスのサムネイル画像の差し替え

また、 ~/pleroma/priv/static/instance/thumbnail.jpeg を置き換えると、 Pleroma Instances などで表示されるアイコンが、デフォルトの暗灰色にπλήρωμαの文字の画像から変更できる。

ロゴの変更

ロゴ、つまりブラウザでPleromaを開いたとき上部真ん中に表示される画像が標準で ~/pleroma/priv/static/static/logo.png となっているので、これを入れ替えるとPleromaフロントエンドの真ん中上部に表示される画像を変更できる。
なお、ロゴ画像ファイルの位置は ~/pleroma/priv/static/static/config.json で指定されている。

チャットの削除

チャットはお一人様インスタンスでは意味がないので消す。 ~/pleroma/config/prod.secret.exs を開き、

nano ~/pleroma/config/prod.secret.exs

次の内容を最後に書き加える。

config :pleroma, :chat,
  enabled: false

設定が終わったらPleromaを再起動する。

sudo systemctl restart pleroma.service

Pleroma最新版への更新(2018/3/17)

2018/3/8あたりでPleromaにActivityPubによるfederationが追加された。私がインストールしたのは3/6なので更新したが、やや面倒だった。更新でなくて一から入れ直すのであれば必要ない手順だと思う。

Pleromaの更新

このページに書かれているように、Pleromaのサービスを止め、最新版のコードにし、マイグレーションを行った。

sudo systemctl stop pleroma.service
cd ~/pleroma/
git pull
MIX_ENV=prod mix ecto.migrate
Nginxの設定を変える

に従って、

sudo nano /etc/nginx/sites-enabled/pleroma.nginx

と /etc/nginx/sites-enabled/pleroma.nginx に次のように書き加える。

        proxy_set_header Host $http_host;
ActivityPub対応

に従って

MIX_ENV=prod mix deps.clean --build mime

を実行し、NginxとPleromaを再起動する。

sudo systemctl restart nginx.service
sudo systemctl restart pleroma.service

感想

PleromaはRaspberryPiでも動かせる! という触れ込みだったのでメモリ512MBのVPSにインストールしたみたのだが、今のところ問題なく動いているようだ。メモリ2GB程度無いと安定動作が難しいMastodonと比べると軽さが際立つ感じがする。

リソース使用量

2018/3/20現在、11アカウントをフォローし、10アカウントからフォローされている。
基本的に、リソース使用料はインストール時を除いて安定しているように思う。しばらく様子見。

CPU

f:id:nixeneko:20180320145001p:plain

ディスクIO

f:id:nixeneko:20180320145127p:plain

転送量

f:id:nixeneko:20180320145043p:plain

*1:このようにサーバーやインスタンスが異なっても「連合」(federation)して互いにフォローすることができる。連合しているSNSネットワークのことをfediverseという。

静的なHTMLページをoEmbedで他サイトに埋め込み可能にする

YouTubeなどの動画サイトの動画や、ブログ記事の内容をブログカードとして埋め込むための規格の一つとして、oEmbedがある。はてなブログもoEmbedに対応している(埋め込む側・埋め込まれる側両方とも)。

仕様概要

oEmbedの仕様は https://oembed.com/ にある。

これを見ると、埋め込まれる側がoEmbedに対応するには、だいたい次のようになっている。

URL schemeはendpointと同じドメイン(サブドメインは違ってもよい)で、http/httpsも一致してる必要がある。

http://flickr.com/services/oembed?url=http%3A//flickr.com/photos/bees/2362225867/

のようにAPI endpointにURL schemeを渡すと、仕様に定義されているようなパラメータをもったJSONまたはXMLが返ってくる。JSONXMLのどちらを返すかは、クエリパラメータで指定することもできるし、別々のendpointを用意することもできる。

さて、これではURL schemeAPI endpointのペアを知らないとoEmbedを呼び出すことはできない。ここで、HTMLページにその情報を埋め込むことで発見できるようにしている。次の例が挙げられている。

<link rel="alternate" type="application/json+oembed"
  href="http://flickr.com/services/oembed?url=http%3A%2F%2Fflickr.com%2Fphotos%2Fbees%2F2362225867%2F&format=json"
  title="Bacon Lollys oEmbed Profile" />
<link rel="alternate" type="text/xml+oembed"
  href="http://flickr.com/services/oembed?url=http%3A%2F%2Fflickr.com%2Fphotos%2Fbees%2F2362225867%2F&format=xml"
  title="Bacon Lollys oEmbed Profile" />

静的Webページにも対応できるか

API endpointは入力されたURLに対応して動的に出力を返すことを前提としている。
しかし、適当にHTMLで書いたページを公開するのに動的なCGIを置くのも気が引けるので、ページ毎にendpointを用意したら、動的な仕組みを用意せずともoEmbed対応できるのでは? と考えて、やってみた。

以下の4ファイルは https://nixeneko.sakura.ne.jp/hatenablog/20180316_oembed/ 以下にアップロードすることを前提としている。

index.html

<!DOCTYPE html>
<html>
<head>
<title>oEmbedのテスト</title>
<link rel="alternate" type="application/json+oembed"
  href="https://nixeneko.sakura.ne.jp/hatenablog/20180316_oembed/oembed.json"
  title="oEmbed Profile of oEmbedのテスト"/>
<link rel="alternate" type="text/xml+oembed"
  href="https://nixeneko.sakura.ne.jp/hatenablog/20180316_oembed/oembed.xml"
  title="oEmbed Profile of oEmbedのテスト"/>
</head>
<body>
このページを埋め込み可能にします。
</body>
</html>

クエリパラメータのurlは固定なので省いた。Vineなんかも似た様な感じで、動画毎にJSON/XMLファイルのURLを用意してクエリ文字列を使わずに対処してるっぽい。
参考: はてなブログの貼り付けにVineが対応していた - すなばいじり

oembed.json

{
    "author_name": "nixeneko",
    "html": "<div style=\"width:100%;height:120px;border:1px solid;font-weight:bold;overflow:hidden;background-color:white;\"><img src=\"https://nixeneko.sakura.ne.jp/hatenablog/20180316_oembed/simarin.jpg\" width=120 height=120 style=\"float:left;margin-right:10px;\"/>ここをキャンプ地とする</div>",
    "url": "https://nixeneko.sakura.ne.jp/hatenablog/20180316_oembed/index.html",
    "version": "1.0",
    "height": 120,
    "width": "100%",
    "description": "おい概要食わねぇか",
    "type": "rich",
    "title": "埋め込みどうでしょう"
}

JSONXMLの情報は、oEmbed公式の説明やはてなブログの設定などを参考に書いた。ブログなどではhtmlパラメータが埋め込まれて表示されるっぽい。
また、widthに100%と指定しているがこれは仕様としては正しくなく、ピクセル単位の数値にすべきであるが、はてなブログのoEmbed情報では100%となっている。

oembed.xml

<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<oembed>
  <author_name>nixeneko</author_name>
  <description>おい概要食わねぇか</description>
  <height>120</height>
  <html>&lt;div style=&quot;width:100%;height:120px;border:1px solid;font-weight:bold;overflow:hidden;background-color:white;&quot;&gt;&lt;img src=&quot;https://nixeneko.sakura.ne.jp/hatenablog/20180316_oembed/simarin.jpg&quot; width=120 height=120 style=&quot;float:left;margin-right:10px;&quot;/&gt;ここをキャンプ地とする&lt;/div&gt;</html>
  <title>埋め込みどうでしょう</title>
  <type>rich</type>
  <url>https://nixeneko.sakura.ne.jp/hatenablog/20180316_oembed/index.html</url>
  <version>1.0</version>
  <width>100%</width>
</oembed>

.htaccess

AddType application/json .json
AddType text/xml .xml

HTTPレスポンスヘッダのContent-Typeを適切に設定する必要があり、JSONはapplication/jsonXMLtext/xmlにする。

テスト

はてなブログではURL記法で:embedを指定することで、oEmbed対応サイトを記事に埋め込むことができる。

[https://nixeneko.sakura.ne.jp/hatenablog/20180316_oembed/index.html:embed]

と書くと、↓のようにoEmbedの埋め込みが表示される。

ここをキャンプ地とする
↑ここまで

いけた! htmlパラメータがそのまま埋め込まれているようである。

また、 http://iframely.com/debug などを使ってoEmbedが認識されているかを確かめてみることもできる。

備考

ブログなどでoEmbedを埋め込む側ではセキュリティ的にホワイトリスト方式をとっているものもあり、そこではこのような得体のしれないoEmbedは参照されないことになるかもしれない。

JSONを手で書くのは現実的ではないので、何らかの方法で自動生成した方がよさそう。

oEmbedの情報はキャッシュされるので、JSON/XMLに変更を加えても反映にしばらく時間がかかる可能性がある。テスト中はキャッシュの生存期間cache_age (秒数を指定)を小さく指定しておくといいかもしれないが、必ずしもcache_ageの値を使うとは限らないらしい。

(2018-03-22 追記)
今回は埋め込み用HTMLにiframeを使っていないが、oEmbedで埋め込めるようになっているページは、大抵はiframeを使って別のHTMLページを読み込ませるようになっている。このとき、iframeによって埋め込まれるページのレスポンスヘッダのContent-Security-Policyが他サイトへの埋め込みを許可するように適切に設定されていないと、読み込まれないことになる。