2013年1月30日水曜日

iOS 6.1 OTAトラブル

Apple税を払っているので、iOS betaが入手できる。いまのところ特にこれといってアプリの開発を行っているわけではないが、少なくともiOS 6.0はWi-Fiまわりが特にひどかったので、iOS 6.1 betaを入れていた。先日までにbeta 4までOTAして動いていたのだが、しばらく触っていなかったところ、奇妙な現象が起きた。

いままでOTAは、「設定」アプリから「ソフトウェア・アップデート」を開かなければ開始されなかったはずなのだが、なぜか今朝、6.1正式版に上げてみるかと電源を入れてみたところ、いつのまにかOTAが終わっていて、Wi-Fiの選択をする画面が現れたのだ。

Wi-Fiの選択肢の下には、「iTunesでアクティベートする」の選択肢があり、どうやらAppleサーバへのiOS署名の認証を待っているようだった。

ここで、どうせ充電のためにMacに接続していたのだから、iTunesでアクティベートしてみればよかったのかもしれないが、なんとなく複数あるWi-Fi APのひとつを選択して先に進んでみた。すると、「アクティベートに失敗しました」画面となり、「iTunesでアクティベートするか、数分後にもう一度試してみてください」というのだった。下に「再試行」のボタンがあるので、再試行すると、再びWi-Fi APを選択する画面に戻る。しかし、今度は「iTunesでアクティベートする」が消えている。何度も試し、別のAPも試し、最後には携帯回線のルータへ接続してみたのだが、いずれも結果は同じ。

ただひとつ、Wi-FiのAPを別のものにした瞬間、一瞬だけ「iTunesでアクティベートする」の項目が現れるのだ。そこを狙ってタップを連打すると、選択を示す青になって先に進む。iTunesはMac上で起動している。だが、結果は同じだった。

どうにもならないので、Apple Careサポートチームに連絡をとり、状況を説明した。彼らが持っている障害データベースにも該当するものはないらしい。そこで、Xcodeから何かできるかもしれないと思い、Xcodeを起動しながらその旨説明をすると、シニアアドバイザーと交代するという。ちょうどXcodeのバージョンも上がっており、更新しろとXcodeが言うのでアップデートしている間にシニアアドバイザーと話をした。

だが、彼も現象が理解できないらしい。逆にこちらがXcodeでどうするのか期待されてしまった。とはいえ、できることはプロビジョニングの更新ぐらいであった。しかも、どうもそれさえ成功していない。「このバージョンのiOSはサポートしていない」とか、わけのわからない表示になっている。

こうなると、シニアアドバイザーとしても、「復元」を薦めるしかない。だがこちらは先日マルウェア駆除のためいったん大掃除して以来、一度もバックアップしていないのだ。残念ながら、30GB超のバックアップを置いておけるディスク領域を持ち合わせていないためだった。

電話口でぶつぶつ言いながら、諦めて「復元」ボタンを押すと、バックアップをするかときいてくる。dfしてみると、なんとか入りそうなぐらいの空きはあるので「OK」を押すのだが、バックアップすることなく復元の確認に入った。そして「復元する」を押すのだが、エラーとなる。なんだそれ。

というわけで、こりゃDFUに入って完全に新しいiPadとして復元する以外に手はなさそうだと思っているところに、電話の向こうも「復元モードで復元しましょう」と言う。いわゆる、「iTunesに接続する」画面のことだ。

それで、DFUに入る手順で復元モードに入り、iTunesから「復元」を押すと、当然のことだがiOSのダウンロードが始まった。そして、インストールが始まり、Appleの認証を通して購入時と同じ、「ようこそ」画面になった。順に選択を行い、アクティベートのところでは「Wi-Fiを使わずにアクティベートする」という形で進め、なんとか初期状態になったところで電話を切った。

シニアアドバイザーの意見では、iOS 6.1 beta 4から6.1正式版へのOTA固有の不具合ではないかというのだった。たしかに、そんなところかもしれないし、そのあたりで納得しないとやっていられない。なにしろこちらはアイコンの配置も、iCloudに依存しないアプリ固有のデータも、in-app Purchaseで購入したあれこれも全部失っているのだ。

これから、それらをちまちまと作業して、できるところまで戻してやることになる。いちばん困るのはin-app Purchaseしたもので、アプリによっては実際に購入手続きに進んでみないと、すでに購入したかどうかわからないものがある。すでに購入した場合は課金されないだけという、たいへんスリリングなものだ。いったん間違えて、記憶に従って、買っているはずだと思うものを選んで購入手続きを続けていたら、結構な金額を請求されたことがあった。

またそれを繰り返すと思うと気が重くなる。

シニアアドバイザーは電話口で「デベロッパーの方に申し上げるのもナンですが、できるだけこまめにバックアップはとられたほうが」と繰り返していた。ごもっとも。

2013年1月24日木曜日

Wiimote IRカメラとのたたかい

Wiimoteの赤外線カメラと格闘している。

Wiiリモコン先端の黒い窓、いわゆる赤外線リモコンを連想する部分なんだけれども、よく知られているように、このなかには、画像処理するマイコンを内蔵した赤外線カメラが存在している。

マイコンでは赤外線の光点を4つまで追跡して、それぞれのカメラ上の座標をI2Cで出力するような処理が行われるので、単にI2Cで出てくる数値をとるだけでアプリケーションが簡単に作れるという仕様。

いわゆるWiimote Hackでは、BluetoothでWiimoteとPCなどを接続してセンサのデータをとったりするのだが、過去に作成されてきたソフトウェアはどれもWindows 7またはMac OS Lion、あるいはLinuxに限られていて、Windows 8とMac OS Mountain Lionしかない状況ではどうにもならないのであった。

それで、世界中が感動した、このカメラの解析ページをもとに、中古で買ってきたWiimoteを分解して、このページと同じように2.54mmピッチの8pinヘッダをとりつけたのだった。これはもう、自分で自分をほめるしかないタフな作業。というのは、Wiimote IRカメラは2mmピッチの千鳥足なんである。つまり、前列4pinと後列4pinは1mmずれていて、ただでさえピッチが合わないのに、前と後ろがずれているので、合わせる場所が本当に8つのピンの中央にしかない。また、カメラの極細の足を曲げないといけないので、空中配線になる。さまざまな試行をしたが、結果として、ヘッダーピン側を水平になるよう、うまく固定して、その隣に、コピー用紙5枚(試行錯誤で、この枚数で上側の端子と高さが合った)に載せたカメラユニットを置いて、そっと中央を合わせ、その2本をはんだ付けし、それから左右を少し開いてはんだを流し、片側を完了させたあと、裏返して再び横からじっくり眺め、高さが揃うように今度は前後の間隔を開くよう、適当な定規で持ち上げ、中央2本をつけ、残りを開いてつけるという作業で完了した。老眼で細かいものが全く見えないうえ、電気スタンドで強い光をあてないと細かいものが見えなくなっているので、ルーペを片目で眺めながら、片目だから距離感がないのを時計職人のつもりで慎重に位置をはかりながらの作業であった。

続いて、カメラのCPUを動作させるためのクロック回路とリセット回路の製作に入った。回路図の定数通りに部品を揃えるのだが、リセット回路の30kΩというのは謎である。E24系列でも存在しない値だから。とはいえ、これは単にプルアップしているだけなので、適当でよいはず。22kΩにしておいたら、海外で商品化した人の回路図も22kΩであった。

ひとまず完成したように見えたので、簡単に導通テストだけをやって、少なくとも電源のショートという情けない状態ではないことを確認して、クロック発振を確認してみた。手軽なので使っている、Seed StudioのDSO Nano Duoで見ようと思ったのだが、ちっとも確認できない。いくら回路を調べても、テスターで電圧を調べてもわからないので、テクトロのちゃんとしたデジタルオシロで確認したら、25MHzのはずが75MHzで発振していた。3倍の異常発振だ。

実はクロック回路を自分で組み立てるのは初めてで、ネットに助けを求めたところ、水晶発振子の異常発振の現象と対策についての解説があり、まさに3倍のケースだったので、Rsを追加することで解決をはかった。幸い抵抗はE24系列すべて100本ずつ揃えてあるので、100Ωから順に10kΩまで試してみた。1kΩでようやく25MHzが出たものの、過電流のせいか、振幅が大きく、3.3Vの給電なのに5V近くまで上がり、逆にマイナスにも振れてしまっていた。10kΩでそれはおさまったけれどもまだ歪みがあるので22kΩにしたら、50MHzになってしまったので10kΩに戻した。ほかにも、CLを大きくするというアドバイスがあったので、15pFを4つ買ってあったのを幸いに、それぞれ2個並列にしてみたが、あまり効果はなかった。

そうしてようやく、デバイスを壊さないであろう程度のクロックが得られたのでカメラユニットをソケットに挿してみたのだが、I2Cのクロックさえ出てこないうえに、しばらく調べながらふとユニットを触ってみたら熱いこと。危ないので即座に取り外して、基板を調べてみると、よくわからないのだけれどVcc-GND間が19kΩしかない。はては、I2Cの端子に至っては34kΩとかで、電圧を測ってみると2V以上出ていた。配線ミスなんだろうけれど、やり直す時間も体力もないので、再び海外の商品の回路図を眺めてみたところ、クロックはオシレータユニットを使っているのであった。秋月ならこれで済ませられるところ。

クロックまわりを除けばあとは単に電源とI2Cの引き出しをするだけなので、せっかくがんばったクロック回路はとりやめることにした。それで、なんとなく検索をしていたら、ARMマイコンであるmbedに接続したよという例があって、クロックはCoretex-M3内蔵のPWMで生成してしまい、結局リセット端子のプルアップとI2C端子のプルアップをするだけの簡単回路になっていた。

当初はArduinoに接続するつもりで、Arduinoの5V端子に接続するため、手持ちのSparkfunのレベルコンバータ基板まで実装していたのだけれど、mbedで済むならこれさえいらない。また、mbedでシリアルに流してやれば、当初予定していたNode.jsとの連携もArduinoでやるのと変わらない。この人のように、シリアル(USBだが)に出力するように素直に書けば、Arduinoとやってることは同じだ。

なんだかすごく遠回りをしたような、まぁ勉強になったのではあるが、そんじゃあ、ということで、mbed+StarBoard Orangeを取り出してきたところである。StarBoard Orange使うならWebSocketで出力する例で、さらにUSB HostにもなるからWi-Fiドングルつければいいんじゃないかとか、そんな意見もあるかもしれないが、BluetoothがWi-Fiに置き換わっただけなんだがそれってうれしいのか、とか、それならBlueUSBで無改造のWiimoteと直接ペアリングしてWebSocketしゃべれよとか、いままでの努力はなんだったのかと悲しくなってくるので、シリアルでデータを流すところで勘弁して貰いたいと思っているところだ。

(2013年1月26日追記:昨日mbed接続用の基板を作ってカメラユニットを装着し、見事に4つずつのXY座標をシリアルポートで得ることに成功した。ちなみに、mbedのPWMが出していたクロックは20MHz前後だった。したがって、水晶発振子でクロック回路を自作する人も25MHzにこだわることなく、入手しやすいクリスタルなりオシレータを使っても大丈夫なようだ。また、mbedの出力は結構ジッターがあるので、クリスタルでなくセラロックでも大丈夫かもしれない。あと、Mac OSでシリアルポートと通信するのは、screenコマンドだというのが新鮮だった。古いUNIXユーザなので、POSIXならcuと頭から決め込んでいたのだけれど、cuの仕様も変わっているし、しばらく迷ってしまった。シリアルポートの速度設定はsttyで。だがめんどくさいのでmbed側のプログラムで9600bpsにして、デフォルトから変更しなくてもよいようにした。)

2013年1月18日金曜日

Zabbixでマシンの稼働状況監視をしてみる

ネットワーク屋さんやSI屋さんが設置する、導入システムの稼働状況監視(障害検知)には、いくつかのシステムがあるようだけれど、今回、職場の情報処理センターに導入予定のZabbixを手元で動かして試してみることにした。

Zabbixは1.x系と2.x系があるようだけれど、今回ははじめてなのでいま最新の2.0.4を使うことにした。

サーバが情報を集約し、PHPを使ったWebインタフェースでリアルタイムに情報を見るというしくみ。情報収集にはSNMPを使ったりサービスポートを叩いたりといった原始的なものから、システムの稼働状況を詳細に計測してサーバからの問合せに応える「agent」とよばれるプログラムをインストールしておくという方法もある。

今回は、手元のMac miniでサーバを動かし(グローバルアドレスが振られている)、職場のNAT内のWindowsマシンやプリンタ、WiFiルータなどと、個人的に契約しているさくらのVPSを一括でみることを考えた。

さくらのVPSは、ISOイメージさえあれば、それを一時的なアカウントでアップロードして、Java経由の仮想コンソールでインストール作業を完了することができるので、OSはたいていのものが使える。僕はLinuxに慣れていないので、以前からFreeBSDを使ってきた。いまは9.1が動いている。

zabbix2のagentは、もちろんFreeBSD用もあり、portsに入っている。PKGNGではそのまま入るところにまだなっていないので、/usr/ports/net-mgmt/zabbix2-agent以下でmake install distcleanすることになる。/usr/local/etc/zabbix2/zabbix_agentd.confに、サーバを動かすマシンのIPアドレスを設定し、/etc/rc.localからでも起動スクリプトを動かしてやればおしまい。

サーバを動かすMacでは、MacPortsを使っているので、port install zabbix2で入れることになった。

ところが、昨日現在での最新状態では、アカウントzabbix、グループzabbixが作成されないため、インストールスクリプトのなかでchownするところで落ちてしまう。しかたがないので、dsclコマンドでアカウントとグループを作り、再度インストールして切り抜けた。

ただ、インストール後のMySQL5の準備(データベースの作成、テーブルの作成、データの挿入)などはすべて手作業になるので、portコマンド実行後に表示される長い説明を読み飛ばさないように注意する必要がある。あと、PHPのモジュールもいろいろと必要なので、Webインタフェースで最初の設定作業をするときのPHPの診断表示に合わせて足りないモジュールや/opt/local/etc/php5/php.iniの書き換えと、カーネルパラメータの設定(共有メモリを大きくとるように設定変更する)は必要だ。カーネルパラメータの値はどの値が適切なのかよくわからなかったが、とりあえずFreeBSD用の値と同じで動いている。FreeBSDと違うのは、/etc/sysctl.confというファイルではなく、sysctl -wコマンドで直接データベースの値変更を行うところ。

なお、ZabbixのWebインタフェースで最初にZabbix Serverを追加するような説明が多いのでそのようにすると思うけれども、MacPortsの起動スクリプトではzabbix_agentdは起動されないので、障害として報告されてしまう。エージェント監視を無効にするか、エージェントも起動するように手を入れておくことが必要になるので注意。

最後に、Windowsについて。Windowsのエージェントをサービスとして登録し、起動するにはコマンドプロンプトを使うが、管理者権限でなければならないので、コマンドプロンプトを管理者権限で起動することを忘れずに。また、zabbix_agentd.confファイルもC:\に置くことになっているので、これも管理者権限がないとできない。設定ファイルの内容は、たった1行、「Server=サーバのIPアドレス」だけで十分なはず。

あともうひとつ罠は、Windows Firewallの設定で、zabbix_agentd.exeの通信許可を手動で行わなければならないということ。コントロールパネルから、Windowsファイアーウォールを開いて、設定をすれば、Zabbixサーバと通信ができて、通信障害が出ることはなくなる。

とりあえずいまのところはこんな感じ。WiFiルータの状態監視もしたいのだが、SNMPトラップをどうみるかは、まだ検討中というところ。