2013年12月アーカイブ

艦これをiPhoneから快適にできるようにしようと思っていろいろやっているのだけれど、なかなか実用レベルにならない。すでに手段が目的化している感はありつつ、これから何回かにわたってやったことを書こうと思う。

艦これをiPhoneでやりたくて、FreeBSDに艦メモを入れてみたりしたんだけど、flashplayerが常駐していると無駄にCPUがぶん回るのと、スクリーンショットが取れないのが嫌だったので、やはりMacをサーバにしたい。
そのためには、出先からMacにアクセスする必要があるのだが、ノート型のMacは蓋が閉まっているとWake On Demandが使えない。
いろいろ調べたり試したりしたんけど、最終的にはDownload InsomniaX for Mac - Disable sleep mode on an Apple Laptop. MacUpdate.comに落ち着いた。
こいつを常駐させて「Disable Lid Sleep」にチェックを入れておくと、蓋を閉じてもsleepしなくなるので、出先からアクセスできるわけだ。
ちなみに、「CPU Safety」と言う設定があって、これにチェックが入っているとCPU温度が80℃を超えるとsleepするようになるんだけど、あっと言う間に80℃を超えてしまって使い物にならなかった。
なので、冬の間だけと割りきって運用することにする。(やはり母艦としてのMac miniが欲しいかな・・・)

さて、これで出先でiPhoneからiSSHとかで繋げるようになったのだけれど、OS Xの画面共有のサーバは8bit colorのクライアントから接続しようとすると切ってしまう。
また、MacBook Proは解像度もそれなりなので、VNCでの転送量が多く 3G 回線ではあまり快適にプレイできない。iPhoneの場合は通信量がある程度行くと速度制限がかかる問題もあり、通信量を減らしたい。
となると、OSの画面共有を使うのではなく、ゲーム画面だけを8bit color で転送できれば良いのだ。
艦メモはQtのQWebView上に艦これのページを表示しているけれど、画面キャプチャを取る機能がある。と言うことは、Qtでゲーム画面がキャプチャできると言うことなので、ならばそのままクライアントに転送することもできるはず、と考えた。
VNCのプロトコルとかもちょっと読んだりしたんだけど、自分で一から実装したらそれなりに大変そうである。QtにVNC Serverの機能がないかと思って調べてみたところ、Qt Embedded にはそんな機能があったっぽいが、今の最新のQtのデスクトップ版には見当たらない。QPAにあっても良いのに。
さらに調べていくと、LibVNCServer/LibVNCClient と言うものを発見。
C/C++から使えるVNC Serverの実装があるじゃないですか。
と、言うわけでこいつを使って艦メモの画面が飛ばせているわけだけど、まだ公開できるところまで行っていないので、前段としてLibVNCServerのMacへのインストールについて。

MacPortsを使う場合
MacPortsにはLibVNCServerのportがあるので、port install LibVNCServer 一発で・・・入らない。
エラーログを見ると、libintl.la が見つからない的なエラー。libintl.laについて調べると、gettextに入っているらしい。
と思って良く見ると、gettextはインストール済みだし、/opt/local/lib/libintl.dylibは存在している。
さらに調べていくと、delete_la_files yes for Mavericksから始まるスレッドを発見。
イマイチどう言うことだか理解していないんだけど、MacPortsのdelete_la_filesと言うオプションがデフォルトでyesになって、laファイルが消されるようになったように見える。
しょうがないので、/opt/local/etc/macports/macports.conf の最後に delete_la_files no と書いて、gettextを再インストールしてみたところ、今度はlibiconv.laがないと言われたので、iconvも入れなおした。
これで、LibVNCServerが入った。

Homebrewを使う場合
HomebrewにはLibVNCServerのFormulaがなかった。
ので、とりあえずソースからビルドすることにして、公式サイトのDonwloadから最新のソースを持ってくる。
configureすると、
==========================================================================
*** The libjpeg compression library was not found. ***
This may lead to reduced performance, especially over slow links.
If libjpeg is in a non-standard location use --with-jpeg=DIR to
indicate the header file is in DIR/include/jpeglib.h and the library
in DIR/lib/libjpeg.a.  You can also set the JPEG_LDFLAGS variable to
specify more detailed linker flags.  A copy of libjpeg-turbo may be
obtained from:  https://sourceforge.net/projects/libjpeg-turbo/files/
A copy of libjpeg may be obtained from:  http://ijg.org/files/
==========================================================================
とか言われる。(言われると言っても、ずらずらと流れるconfigureのlogの途中に出ているので、気をつけて見ていないと気が付かない)
そこで、brew install libjpegして再度configureすると、
==========================================================================
*** The libjpeg library you are building against is not libjpeg-turbo.
Performance will be reduced.  You can obtain libjpeg-turbo from:
https://sourceforge.net/projects/libjpeg-turbo/files/ ***
==========================================================================
とか言われる。そこで、brew uninstall libjpegして、brew install libjpeg-turboして、試してみると、また見つからないと言う。
そう言えば、libjpeg-turboをインストールしたときに、libjpegと喧嘩するから/usr/local/opt/jpeg-turboに入れるね♪とか言っていた気がする(ログ取ってない)
そこで、configureのオプションに--with-jpeg=/usr/local/opt/jpeg-turbo を付けて上げたら、無事に行けたような気がする。
homebrewは/usr/local/のオーナーが自分なので、sudoせずにmake installまで行ける。
ここまでやって、portsはどうなってるんだろう?と思ってみたところ、portsにはlibjpegはなくlibjpeg-turboしかない。(でもjpegとかopenjpegとかある)
そして、LibVNCServerのportの依存関係にあったのはjpegだった。
さて、せっかくビルドできたので、また野良Formulaを作ってみる。
Formula Cookbook · mxcl/homebrew Wikiに従い、brew createすると、
% brew create http://sourceforge.net/projects/libvncserver/files/libvncserver/0.9.9/LibVNCServer-0.9.9.tar.gz/download
Formula name [download]: 
Formula nameを聞かれた。これは、LibVNCServerのダウンロードURLが、ファイル名ではなくdownloadで終わっているせいだろう。そこで、LibVNCServer と入れてenterを押すと、勝手にファイルが作られてviが起動した。
後は、作られたファイルの中身とにらめっこしながら、消せって書いてあるコメントを消したり、homepageを埋めたり、依存関係を埋めたりして進めていく。
test のところが、デフォルトの実装だと受け入れないよ?とか書いてあるんだけど、ライブラリの場合に何を書けば良いのかわからなかったので放置した。本家にpull reqする度胸ないし。(良く考えたら、他のライブラリのFormulaを参考にすれば良かった)
動作確認をしたら、githubに"homebrew-"で始まるリポジトリを作り、そこにFormulaを置いておくと、brew tap で使えるようになる。
私の場合は、homebrew-local にしてみたので、false-git/homebrew-localになる。
これを他の人が使いたい場合は、以下のようにする。
% brew tap false-git/local
% brew install libvncserver

Qtのプロジェクトから使えるようにする
LibVNCServerが入ったので、こいつをQtから使えるようにする。
LibVNCServerはpkg-configに対応しているので、pkg-config --cflags libvncserver とすればコンパイル時に必要なオプションが得られるし、pkg-config --libs libvncserver とすればリンク時に必要なオプションが得られる。MacPortsで入れた人もHomebrewで入れた人も同じMakefileが使えるわけだ。
と言うわけで最初に書いたバージョン。
QMAKE_CXXFLAGS += `pkg-config --cflags libvncserver`
LIBS += `pkg-config --libs libvncserver`
これでも動くんだけど、みんながVNC Serverを使うわけでもないだろうから使うかどうかを外から指定できるようにしたくていろいろ調べていたら、そもそもQtがpkg-configに対応してそうなことがわかってきた。
そこで書いたバージョン2。
!isEmpty(WITH_VNC) {
    DEFINES += WITH_VNCSERVER
    CONFIG += link_pkgconfig
    PKGCONFIG += libvncserver
}
これで、qmakeを実行するときにqmake WITH_VNC=1とか書くと、libvncserverをリンクしてくれるはずだったんだけど、libvncserverが見つからないって言われる。
なんでだろー、と調べていくと、Using pkg-config with Qt Creator/qmake on Mac OSX - Stack Overflowと言うページを発見。OS Xの場合は、QT_CONFIGにno-pkg-configが指定されてしまっているので、わざわざそれを外してやる必要があると。
そこで最終形。
!isEmpty(WITH_VNC) {
    DEFINES += WITH_VNCSERVER
    QT_CONFIG -= no-pkg-config
    CONFIG += link_pkgconfig
    PKGCONFIG += libvncserver
    SOURCES += vncserver.cpp
    HEADERS += vncserver.h
    message("with VNCServer")
}
SOURCES += と HEADERS += については先の回で説明するとして、とりあえずこんな感じで書いて上げると、もしlibvncserverがインストールされていない状態で qmake WITH_VNC=1 すると、qmake時にエラーが出て教えてくれる。
さて、これでコマンドラインからビルドする分には困らなくなったんだけど、Qt Creatorからビルドしようとするとpkg-configが見つからなくてエラーになる。
なんでだろー、と(こればっかり)・・・。osx - Environment variables in Mac OS X - Stack Overflow
Macの場合は、DockとかSpotlightから起動するアプリはユーザのシェルじゃなくてlaunchdから起動される。このため、.zshrcとかに環境変数を書いておいても、Qt Creatorには影響しないのだ。
  • 「launchctl setenv 変数名 値」で環境変数が設定できる
  • でもログアウトしたら忘れるよ
  • ~/.launchd.conf に書いたらおk
  • 最近のOS Xだと効かないよ
  • ワークアラウンドとして、~/Library/LaunchAgents/local.launchd.conf.plist ってファイル作って、以下の内容書いとけ
みたいな流れかな。system wideのpathだったら、/etc/paths.d/ に書くって言う手もあるけど、rootに影響する環境には書きたくないのよね。

と、言うわけでここまでが準備編。次回は、LibVNCServerの使い方について触れていこうと思いますが、いつになるかわかりません。
以前のPentium Mのサーバは、FreeBSD9にすると起動してすぐにカーネルパニックを起こしてリブートループしてしまうため、8-STABLEを使用していた。
今回、サーバマシンが死んでCore i7マシンに変わったので、FreeBSD9にすることを検討する。
で、どうせ9系にするのならば、i386版ではなくamd64版にしたい。
一応、二つのスライスを利用した FreeBSD i386 から amd64 への移行: uyota 匠の一手と言うサイトを見て、stable/9をチェックアウトして、TARGET_ARCH=amd64をつけてやればアップグレードもできそうだと思ったんだけど、i386のライブラリが残るだとか、portsも全部ビルドし直した方が良さそうとかあるので、クリーンインストールすることに。
2TのHDDを購入して、新しいディスクをATA0に、古いディスクをATA1に繋いで、9.2-RELEASEのインストーラを起動。
現在のデフォルトはMBRではなくGPTらしいので、GPTでfreebsd-bootに128k、freebsd-ufs(/)に512G、freebsd-swapに8Gの領域を確保して、インストール実行。
あっという間に終わるので、再起動・・・・。
起動しません。
マシンを交換したときと同じ、
Reboot and Select proper Boot device
or Insert Boot Media in selected Boot device and press a key 
が出るだけ。
何か間違えたかと思って、インストールDVDから起動し直してgpart show とかやっても正しそうに見える。
パーティションの切り方が悪いのかと思って、全部デフォルトでインストールし直しても同じ。
この時気になったのが、ATA1に繋いでいるはずの古いディスクがgpart showで正しく見えない。 dmesgを見ると、
GEOM_RAID: Promise: Array Promise created.
GEOM_RAID: Promise: Disk ada1 state changed from NONE to ACTIVE.
GEOM_RAID: Promise: Subdisk PROMISE Array 1:0-ada1 state changed from NONE to ACTIVE.
GEOM_RAID: Promise: Volume started.
GEOM_RAID: Promise: Volume PROMISE Array 1 state changed from STARTING to OPTIMAL.
GEOM_RAID: Promise: Provider raid/r0 for volume PROMISE Array 1 created.  
とか言って、promiseのraidコントローラと勘違いしている?
この時点で、OSが起動しない、古いディスクが読めない、と言う2つの大きな問題を抱えてしまった。
GPTとFreeBSDのbootシーケンス等についていろいろ調べたりして、pmbrを書いてみたり、gptbootを書いてみたりしたけど状況は変わらず。
面白いことに、古いHDDにあるmbrからブートすると、ブートメニューでF5を押して別のディスクを選択すると、GPTの新しいFreeBSDが起動する。
しかし、古いディスクをブートシーケンスに含むのは変だし、先々困りそうである。
ここで一度諦めて古いHDDからブートし、一晩頭を冷やすことにする。
頭を冷やしている間に、古いHDDがraidに見えてしまう問題について調べてみたところ、freebsd-stable - GEOM_RAID in GENERIC is harmful と言うのを発見。
FreeBSD 9-STABLEのどこかのタイミングで、GENERICカーネルにGEOM_RAIDオプションがデフォルト化され、それが原因で古いHDDを繋ぐとおかしいことが起きるよ、的な話らしい。
そこで、最初のサイトをヒントに、古い環境にstable/9のソースをチェックアウトし、amd64用のカーネルコンフィグを作成して、TARGET=amd64でbuildkernelし、新しいHDDに入れてみた。
include GENERIC

ident           FALSE

device crypto

options         IPSEC
#options                IPSEC_ESP
options         IPSEC_DEBUG
options         IPSEC_NAT_T
options         IPFILTER
options         IPFILTER_LOG
options         IPFILTER_DEFAULT_BLOCK
#options                TCP_DROP_SYNFIN
options         SHMMAXPGS=10000
options         SHMMNI=100
options         SHMSEG=10
options         SEMMNS=200
options         SEMMNI=70
options         SEMMSL=61

nooptions       GEOM_RAID
変更点は、最後のnooptions GEOM_RAID
これで、新しいHDDから起動してみると、無事に古いHDDをマウントして見ることができた。
その後、GPTのブートについていろいろ調べたがどうにも解決しなかったので、諦めてMBRでパーティションを作成してOSをインストール。
これで起動することができた。
再度古いHDDからinstallkernelして、今度は新しいHDDでbuildworld/installworldもやり直した。

今回のディスクも、以前のディスクも、AFT(物理セクタが4kiB)なので、パーティションも4KiB境界にあるのが望ましいらしい。(clicklog: FreeBSD 9.0-RELEASE インストールの練習)
gpartを使うと、勝手にやってくれそうな感じだけど、MBRでインストールした場合は勝手にやってくれなかったようだ。
# diskinfo -v /dev/ada0s1a
/dev/ada0s1a
        512             # sectorsize
        541165879296    # mediasize in bytes (504G)
        1056964608      # mediasize in sectors
        4096            # stripesize
        3072            # stripeoffset
        1048576         # Cylinders according to firmware.
        16              # Heads according to firmware.
        63              # Sectors according to firmware.
        WD-WMC4M1940446 # Disk ident.
diskinfo -v して、stripeoffsetが0か、4096の倍数であれば良いらしいのだが、見事に3072である。
そこで、FreeBSDでWD10EARSをMBRで使う際に本来の性能を出す方法 - mteramotoの日記を参考に504(63と8の最小公倍数)の倍数をstart sectorとするパーティションを作成し、上記ada0s1aとシーケンシャルread/writeでの速度比較を行ってみた。
結果としては、新しくアラインメントを合わせて作った ada0s2 の方が、アライメントがあっていないada0s1よりも気持ち遅い、と言う結果になった。(以下で、/varがインストーラが作ったパーティションで、/mntが自分でアライメントを合わせて作ったパーティション)
実験1: /dev/randomからHDDにddで約40Gコピー
# dd if=/dev/random of=/var/test.dd bs=4k count=10000000
10000000+0 records in
10000000+0 records out
40960000000 bytes transferred in 453.281270 secs (90363319 bytes/sec)
# dd if=/dev/random of=/mnt/test.dd bs=4k count=10000000 
10000000+0 records in
10000000+0 records out
40960000000 bytes transferred in 419.405037 secs (97662156 bytes/sec)
実験2: HDDからHDDにddで約40Gコピー
# dd if=/var/test.dd of=/var/test2.dd bs=4k
10000000+0 records in
10000000+0 records out
40960000000 bytes transferred in 905.631041 secs (45228132 bytes/sec)
# dd if=/mnt/test.dd of=/mnt/test2.dd bs=4k
10000000+0 records in
10000000+0 records out
40960000000 bytes transferred in 1377.528304 secs (29734416 bytes/sec)
稼働中のサーバなのである程度の誤差はあるが、アライメントを合わせた方がread/writeでは明らかに遅い。
これは、実験1では純粋なシーケンシャルwriteなのに対し、実験2はread/writeで間にシークが入るので、ディスクの場所(内周/外周)による差が出やすいのではないかと思ったりしている。
結局、実運用では気にするようなパフォーマンスの差はないのではないかと結論し、パーティションを作りなおして再インストールはしないことにする。(実験1はアライメントを合わせた方が速いので、今から入れる人は504の倍数に合わせた方が良いかも)

この後いろいろインストールして、rrdがアーキテクチャの違いで読めないとか、pptpが繋がらないとかあったけど、それはまた気がむいたら別の機会に。
2013年12月
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        

このアーカイブについて

このページには、2013年12月に書かれたブログ記事が新しい順に公開されています。

前のアーカイブは2013年11月です。

次のアーカイブは2014年1月です。

最近のコンテンツはインデックスページで見られます。過去に書かれたものはアーカイブのページで見られます。

Powered by Movable Type 6.1.1