裸族の集合住宅を買った

ディスクを買い足したくなったので、そのために裸族の集合住宅をついに買った。

センチュリー 裸族の集合住宅5Bay SATA6G USB3.0&eSATA CRSJ535EU3S6G

eSATA と USB 3.0 で接続できて、まぁ普通は eSATA で接続したいと思う。 ただし、eSATA を使うにはポートマルチプライヤ対応が必須で (ポートマルチプライヤに対応してないと1つのディスクしか見えない)、そのために玄人指向の SATA3E2-PCIe も買った。

玄人志向 インターフェース SATA3E2-PCIe

わりと定番の組み合わせっぽいけど、Linux でちゃんと動くか不安だった。 とりあえず WD40EFRX を2台挿してみたけど、PC からちゃんと2台とも見えて普通に動いてる。 これらの2台のディスクはなんとなく興味本位で LVM で束ねて1つの大きなディスクに見えるようにしてみて、バックアップ領域として使われる予定。 転送速度も特に問題なさそうで、あとはこの先安定的に動作してくれることを祈ってる。

余談。新しいディスクは普通に ext4 でフォーマットしたんだけど、テストで書き込みを行った後も新規のディスクに定期的に 4MB/s くらいで write があって、iotop で見たら ext4lazyinit だった。 あんまりよく知らないけど、mkfs を高速化するために inode table の初期化を遅延実行するやつらしい。 たしかにディスクサイズに対して mkfs.ext4 は早かった。

追記 2014-07-16

さすがに 4TB x 2 で1つの仮想ディスク作るのはデータロストリスクの観点から狂気だったのでやめた。

あとたまに裸族の集合住宅の電源が落ちる現象に悩んでいたけど、どうやら壊れたディスクを繋いでいて、そのディスクを使っているときに IO Error が発生すると落ちるっぽい。 ディスクを使ってなくても繋いでるだけでもたまに落ちてたけど、もしかしたら smartd によるアクセス起因かもしれない。 とにかく、壊れたディスクを外したら安定したように見える。 SMART のエラーを検知したらすぐに裸族の集合住宅からは外して、直接本体に繋いでデータのコピーをとって捨てるような運用が必要な気がしている。

iPhone 4S から Nexus 5 に移行して1ヶ月ちょっと経った感想

• 移行前
  • 2年ほど前に買った iPhone 4S
  • SoftBank
• 移行後
  • Nexus 5
  • IIJmio ミニマムスタートプラン (音声通話機能付き)

感想

• 端末が大きい
  • iPhone は完全に片手だけで操作できたけど、Nexus 5 のサイズになると厳しい
  • 慣れてきたけどときどき気になる
• 画面のバックライトの明るさの調整が雑
  • iOS のときは自動で不満はなかった
  • 今は明るさ設定のウィジェットをホームに置いて、一番暗いやつと半分くらいの明るさのやつを手動で切り替えてる…
• ロック画面で見れる通知の情報が少ない
  • iOS だとプッシュ通知の内容もちょっと見れるけど、Android だとデフォルトで全然見えない
  • ロック画面にもウィジェットを置けることを知ってから Gmail に関してはロック中でも少し見えるようにした
  • セキュリティとかプライバシー的には Android のほうがあるべき姿な気はする
• キーパッドの切り替えが煩雑
  • Google 日本語入力にして Google 日本語入力の設定することで、日本語のフリック入力とアルファベットの QWERTY キーボードを簡単に切り替えられるようになった
    • しかし Google 日本語入力の変換は余計なお世話が多くて、単文節変換しているユーザには使いにくい… 学習とか全部切ってるはずなんだけど
    • 単純な変換辞書は豊富でいい
• 全般的な操作は快適
  • iPhone 5S と比べてどうかはわからないけど、iPhone 4S よりは快適
• インテント最高
• Linux 環境でも Android アプリは開発できる
• iTunes で買った音楽をどうするのか問題がまだ解決してない
  • あとこれから音楽をどこでどう買おう問題も
  • iTunes Store 自体は良いので PC とか Android から買えるようになってほしい…
• データ通信を月に1GBもしてないので、ミニマムスタートプランで常にクーポンを ON にしてて平気
  • というか500MBも使ってない
  • あとはコミケ的な環境でも使えることを期待してる

2014年3月の録画視聴環境

半分自分用のメモです。

ハードウェア構成

http://wanko.cc/machines.html の signum が録画、ストレージ、エンコードのすべての役割を担ってる。

• 録画
  • PT2 x 1 (地上波 x 2、BS x 1)
    • 分波器とケーブル買えば BS x 2 にできるけど要らなそう
  • PT3 x 1 (地上波 x 2、BS x 2)
• B-CAS カードリーダ
  • SCR3310-NTTCom

ソフトウェア構成

• OS
  • ArchLinux
• ドライバ
  • pt1_drv
  • pt3_drv
  • これらを DKMS で管理
    • pt1_drv-dkms-hg
    • pt3_drv-dkms-git
• レコーダ
  • recpt1
• 録画システム kaede
  • 自作 https://github.com/eagletmt/kaede
  • しょぼいカレンダー をソースにしてレコーダの起動を行い、前処理を行ってから TS をエンコードキューに入れる
  • 詳細は後述
• エンコーダ
  • ffmpeg
  • エンコードキューとして Redis を使い、ファイル名を BLPOP で取り出してエンコードする
  • 前処理として clean-ts を使ってから ffmpeg でエンコード
    • TOKYO MX のマルチ編成時やその前後の SD/HD 切り替えに対応するため
    • 今思ったけどこれ CS でうまく動かない気がする

録画システム

最近自作し直した。

• レコーダのチャンネルとしょぼいカレンダー上のチャンネルIDの対応表
• 録画したい tid

を設定しておくと、登録した tid の番組を片っ端から録画していくやつ。 「この回は MX で録ったから BS11 の回は録画しなくていいや」とかそういうことはやらないでとにかく録画する。

• updater
  • 定期的にしょぼいカレンダーのデータを取得してローカルの番組 DB を更新し、時刻に変化があったら scheduler をリロードさせる (kill -HUP)
• scheduler
  • 登録されてる tid の番組の開始時刻に recorder を起動する
    • 前のバージョンはこの部分を atd でやってたけど、いろいろつらくなって timerfd で自分で実装した
  • recorder の起動前後に好きな処理を追加できる
• recorder
  • 録画する
  • recpt1 が出力した TS を tail -f して、B25 のデコーダと字幕抽出の2つにリアルタイムにデータを流してる
    • まれに B25 のデコードに失敗するので、recpt1 でデバイスファイルから読み込んだデータを一次ソースとしてディスクに保存してから後続の処理に回したいのでこうなってる

今は recorder の前後の処理として、

• 録画前
  • @eaglercd へ録画予告ポスト
• 録画後
  • @eaglercd に録画完了ポスト
    • ファイルサイズと残り容量も一緒にポストしてる
  • エンコードキューへの追加用のファイルに録画した TS のファイル名を追記
    • 録画中に clean-ts (I/O bound) を実行すると recpt1 側がたまにドロップするので、毎朝5時に一気にエンコードキューに入れてる
    • もうだいぶ前の話で今ではこの状況が変わってるかもしれないので、近いうちに検証してみる
  • (2014-04-07) 試してみたら、3番組同時録画が連続する場合でも大丈夫そうだったので、録画直後に clean-ts してキューに入れるようにした

を行ってる。

視聴

• PC
  • NFS でマウントして mpv で再生してる
  • 字幕も見たいときは mplayer
• iPad
  • サーバに MediaTomb を入れて、8player で再生してる
  • MPEG2TS を直接再生できるのでおすすめ

その他

Chinachu がずっと気になっていながらまだ一度も試してない。

拡張可能なプログラム

Ruby のような実行時に何でもできる言語だと、ユーザが書いた Ruby のコードを実行したり、プラグインの gem をインストールするだけで使えるようになったりする仕組みを提供できる。 例えば spring は ~/.spring.rb や config/spring.rb を自動的に読み込み、また spring-commands- で始まる gem を自動的に require し、プラグイン側は Spring.register_command で独自のコマンドを定義できるようになっている。

• https://github.com/rails/spring/blob/v1.1.2/lib/spring/commands.rb
• https://github.com/jonleighton/spring-commands-rspec/blob/v1.0.1/lib/spring/commands/rspec.rb

pry も似たようなかんじで、~/.pryrc や ./pryrc を読み込んだり、pry- で始まる gem を自動的に require して、プラグイン側は Pry.commands.import 等で独自のコマンドを定義できるようになっている。

• https://github.com/pry/pry/blob/v0.9.12.6/lib/pry/pry_class.rb#L109
• https://github.com/pry/pry/blob/v0.9.12.6/lib/pry/plugins.rb#L70
• https://github.com/deivid-rodriguez/pry-byebug/blob/v1.3.2/lib/pry-byebug/commands.rb#L260

一方、Haskell のような言語だとこういうことをするのは難しい。 Haskell で書かれていて Haskell で拡張可能なプログラムというと XMonad くらいしか思い付かないんだけど、XMonad は「拡張可能なウィンドウマネージャ」というより「ウィンドウマネージャを簡単に作れるライブラリ」に近くて、実際 XMonad の設定は main 関数を持つ普通のプログラムとして書かれる。

• http://code.haskell.org/xmonad/man/xmonad.hs

XMonad の場合、設定をコンパイルして得たバイナリは ~/.xmonad/xmonad-$arch-$os に作られるんだけど、xmonad コマンドは ~/.xmonad/xmonad-$arch-$os を exec し、それに失敗したらデフォルトの設定で xmonad をスタートするラッパーの役割しか持っていない。

Haskell で拡張可能なプログラムとして yi を忘れてた。 yi も XMonad と同じ方式で、設定ファイルは main 関数を持つ普通のプログラムとして書かれるっぽい。XMonad 方式の設定を実現するための dyre というライブラリがあり、yi はこれを使っている。

• https://github.com/yi-editor/yi/blob/v0.7.1/yi/src/library/Yi/Boot.hs

Haskell で拡張可能なプログラムを書くとしたら、XMonad のようなアーキテクチャにするのがいいのかもしれない。 pandoc は内部では新しい Reader / Writer を追加できるようなアーキテクチャになってるけど、ユーザ側が好きな Reader / Writer を追加できるようなものではなさそう。

ttcoder

大学の ICPC の練習会で使ってる TokyoTechCoder のリポジトリを GitHub で公開した https://github.com/eagletmt/ttcoder

元々オリジナルの TokyoTechCoder があってそれまではそれを使っていたけれども、 それを作っていた人が大学から離れて時間がたってしまったこともあり、メンテがされず動作が怪しいこともあった。 一昨年に半年間くらい初めて Rails アプリケーションを書いてみて、そのときの反省を活かしたい時期だったので、 ちょうど今から一年くらい前に rails new した。 今年度の練習会から新しいものを実際に使うようにして、オリジナルと同じようになるように機能を追加したり、 オリジナルから離れて独自の機能を追加したりしながら現在に至る。

自分もこの春に卒業して社会人になってしまい、このままだと以前と全く同じパターンになってしまうので、このタイミングで公開しておくことにした。 あとまぁ単純にオープンにしておきたいという気持ちもあった。 タダで Travis CI でテストを実行したり Coveralls でカバレッジを記録したりできるし、公開しておくと便利。

ArchLinux のリポジトリを akabei で楽に管理する

Arch のパッケージのリポジトリを作る 発展編 - eagletmt's blog で書いた内容を自動化するために akabei を作った。 さらに S3 の Static Website Hosting を利用する機能も実装して、実際に http://arch.wanko.cc/ を運用してみている。

基本機能

build サブコマンド

akabei build foo --repo-dir repo/x86_64 --repo-name bar --arch x86_64 で、foo/PKGBUILD をもとに repo/x86_64 以下に x86_64 向けのパッケージと、bar リポジトリの ABS tarball とデータベースとファイルリストが生成される。

% akabei build foo --repo-dir repo/x86_64 --repo-name bar --arch x86_64
(snip)
% ls repo/x86_64
bar.abs.tar.gz  bar.db  bar.files  foo-1.0.0-1-x86_64.pkg.tar.xz

さらに --repo-key や --package-key を指定すると、指定した鍵で署名を行う。署名を行うときは gpg-agent を立ち上げておくと楽。

ビルド時の chroot はデフォルトで毎回最初から作り直す。Arch で破壊的変更があったりすると chroot 環境をメンテするのがめんどくさいので、毎回作り直してもいいと思った。--chroot-dir オプションで既にある chroot を指定して使わせることもできる。

他にも --pacman-config、--makepkg-config、--logdest、--srcdest 等のオプションを指定できて、詳しくは akabei help build を参照。

その他のサブコマンド

また、ABS tarball やデータベースやファイルリストを扱うための abs-add、abs-remove、repo-add、repo-remove、files-add、files-remove といったサブコマンドがある。 {repo,files}-{add,remove} は既存の repo-add(8) と同じ機能だけど、余計なファイル出力や symlink が無いのが特徴。

Omakase mode

普通にリポジトリを運用するときに行う操作を自動化した Omakase mode がある。

最初に、akabei omakase init で設定ファイルを生成する。

% akabei omakase init foo --repo-key $GPGKEY --package-key $GPGKEY
      create  .akabei.yml
      create  foo
      create  sources
      create  logs
      create  PKGBUILDs
      create  etc
      create  etc/makepkg.i686.conf
      create  etc/pacman.i686.conf
      create  etc/makepkg.x86_64.conf
      create  etc/pacman.x86_64.conf
Edit etc/makepkg.*.conf and set PACKAGER first!
% echo 'PACKAGER="John Doe <john@doe.com>"' >> etc/makepkg.i686.conf
% echo 'PACKAGER="John Doe <john@doe.com>"' >> etc/makepkg.x86_64.conf

パッケージを追加するときは、PKGBUILDs/$pkgname というディレクトリを作ってその中に PKGBUILD を置き、akabei omakase build $pkgname とする。 するといいかんじに i686/x86_64 用のパッケージが作られ、ABS tarball、データベース、ファイルリストが更新される。 ビルド時にダウンロードしたソースやビルドのログも、それぞれ source ディレクトリと logs ディレクトリに作られる。

% akabei omakase build bar
(snip)
% tree foo
foo
`-- os
    |-- i686
    |   |-- bar-1.0.0-1-i686.pkg.tar.xz
    |   |-- bar-1.0.0-1-i686.pkg.tar.xz.sig
    |   |-- foo.abs.tar.gz
    |   |-- foo.db
    |   |-- foo.db.sig
    |   `-- foo.files
    `-- x86_64
        |-- bar-1.0.0-1-x86_64.pkg.tar.xz
        |-- bar-1.0.0-1-x86_64.pkg.tar.xz.sig
        |-- foo.abs.tar.gz
        |-- foo.db
        |-- foo.db.sig
        `-- foo.files

そして、この foo ディレクトリを Apache なり nginx なりで公開する。

パッケージを更新するときも、PKGBUILD を更新してから同じように akabei omakase build $pkgname とすればいい。 このとき、古いパッケージファイルは消されずに残る。 これは意図的にそうしている (けど、古いパッケージを消すオプションもあってもいいかもしれない)。

パッケージを削除するときは akabei omakase remove $pkgname とする。 ただし、これによって消されるのは ABS tarball、データベース、ファイルリスト内のエントリであり、パッケージファイル自体は消されずに残る。

Omakase mode with S3

これは完全に自分の都合で追加した。 S3 上にリポジトリを作るのは便利で楽だと思っていて、実際に http://arch.wanko.cc/ ではそうしてる。

akabei omakase init --s3 とすると S3 の設定を含む .akabei.yml が生成されて、.akabei.yml に S3 用のアクセスキーを設定すれば、あとは同じように akabei omakase build $pkgname でビルドして公開できる。

Arch のパッケージのリポジトリを作る 発展編

基本編は http://eagletmt.hateblo.jp/entry/2012/12/21/214507 。 基本編で紹介した方法だけでもリポジトリとしての機能を果たせるディレクトリ構成を作れるが、 公式リポジトリと比較して足りないものが3つある。

1. 署名
2. pkgfile 用のデータベース
3. abs 用の tarball

実際にこれらを追加したリポジトリが http://arch.wanko.cc/vim-latest/ にある。

署名をつける

pacman 4 にメジャーバージョンアップしてから、パッケージとデータベースに署名をつけられるようになった。 2012-06-04 の時点ですべての公式リポジトリのパッケージに署名がつけられ、デフォルトで署名のチェックを強制するようになっている (Arch Linux - News: Having pacman verify packages)。 独自リポジトリでも署名のチェックを強制するには /etc/pacman.conf で SigLevel = Required に設定すればいい。

署名するにはもちろん GPG の鍵が必要なので、最初に用意しておく。自分は以下のサイトを参考にした。

• https://sites.google.com/site/kspjapanese/create-gpgkey
• https://wiki.archlinux.org/index.php/GnuPG

以下の説明では、署名する鍵として実際の自分の鍵である C48DBD97 を用いる。

パッケージに署名をつける

単純に makepkg で作る場合は、/etc/makepkg.conf で GPGKEY を設定して BUILDENV の !sign を sign に変更すればいい。

BUILDENV=(fakeroot !distcc color !ccache check sign)

GPGKEY="C48DBD97"

ただし、基本編に書いたようにきちんとパッケージを作るには makechrootpkg を利用して chroot 環境で作成したほうがいい。 chroot 環境から自分の GPG 鍵は見えないので、makechrootpkg でパッケージを作った後に gpg コマンドで普通に署名を追加するしかない (たぶん)。

例えば vim-latest というパッケージを作る場合、

sudo makechrootpkg -cur ~/chroot-x86_64
gpg --detach-sign -u C48DBD97 vim-latest-7.4.141-1-x86_64.pkg.tar.xz

とする。 あとはパッケージと同じディレクトリに .sig ファイルも置いて公開するだけでいい。

データベースに署名をつける

ついでにデータベースにも署名する。 これは --sign --key C48DBD97 というオプションをつけて repo-add すればいい。 さらに --verify というオプションをつけると、現在のデータベースの署名をチェックしてから新たな署名を生成する。 独自リポジトリを更新していくときは常に --verify をつけておいたほうがいいだろう。

例えば vim-latest というリポジトリの場合、

repo-add --sign --key C48DBD97 --verify vim-latest.db.tar.gz vim-latest-7.4.141-1-x86_64.pkg.tar.xz

とする。 すると vim-latest.db.tar.gz.sig も生成されるので、それぞれ vim-latest.db と vim-latest.db.sig という名前で公開する。

pkgfile 用のデータベースを作る

pkgfile を使うと、あるコマンドやファイルがどのパッケージについているか調べることができる。

% pkgfile -b vim
extra/gvim
extra/vim
vim-latest/vim-latest

この機能は pkgfile -u したときにリポジトリから "#{repo}.files" というデータベースをダウンロードしてくることで達成されている。 この .files というデータベースを作るには repo-add を使う。

repo-add --sign --key C48DBD97 --verify --files vim-latest.files.tar.gz vim-latest-7.4.141-1-x86_64.pkg.tar.xz

これによって生成された vim-latest.files.tar.gz を、 普通のデータベースと同様に vim-latest.files という名前で公開する。 .sig を一緒に公開してもいいけど、pkgfile は特に署名のチェックはしない。 結局、.files はリポジトリのデータベースにファイル一覧をつけただけのファイルなので、リポジトリのデータベースと同様に新たにパッケージを追加する度に repo-add --files して更新する。

abs 用の tarball を作る

これを作っておくと、abs コマンドでソースツリーを保ったり、yaourt -G でソースパッケージを展開したりすることができる。

ただし、これを作るための便利なコマンドというのは用意されていない様子。 なので適当に自分で tarball を作るしかない。

vim-latest/
vim-latest/vim-latest/
vim-latest/vim-latest/PKGBUILD
vim-latest/vim-latest/vim-7.4.035-breakindent.patch

というような構成の tarball を vim-latest.abs.tar.gz という名前でデータベースと同じディレクトリで公開すればいい。

まとめ

最終的に公開するディレクトリの構成はこのようになる。

i686/vim-latest-7.4.141-1-i686.pkg.tar.xz
i686/vim-latest-7.4.141-1-i686.pkg.tar.xz.sig
i686/vim-latest.abs.tar.gz
i686/vim-latest.db
i686/vim-latest.db.sig
i686/vim-latest.files
x86_64/vim-latest-7.4.141-1-x86_64.pkg.tar.xz
x86_64/vim-latest-7.4.141-1-x86_64.pkg.tar.xz.sig
x86_64/vim-latest.abs.tar.gz
x86_64/vim-latest.db
x86_64/vim-latest.db.sig
x86_64/vim-latest.files