急遽工場へ

ちょっと面白いトラブルがあった。トラブルを「面白い」というのも変だけど、会社で理解できるのが誰もいないので、ここで開陳してわかる人に楽しんでもらおうと思う。

昨日、工場から組み立て装置が動かなくなった、ほとんど在庫がないのでこのままではショートしてしまう、と連絡が来た。メールと電話であれこれ指示してなんとかしようとしたんだけど、いかんせん工場にはunixを知ってるやつは一人もいないので隔靴掻痒。昨日3時にしょうがないと諦めて行くことにした。

先週金曜まで動いていて週明けから生産がなくて昨日組み立てを再開しようとしたら動かないという。どうせ何か変なことをしたに違いない、現地で調べれば10分で解決するだろう、とタカをくくっていた。夕方7時過ぎに到着してクリーンルームに入って調べ出した。ところが全然わからなかった。夜はどんどん更けていく。こういうことがないようにvpnを入れようとつねひごろ言ってたのにぶつぶつ．．．

装置は光学定盤の上に乗った光学系と、ハードウェア制御用のRaspberry Piと、ホストのMac miniでできている。ソフトウェアから見ると装置はこんな感じ。

この装置のホストのMac miniはヘッドレスではなく、ディスプレイとキーボードを持っていてRaspberry Piとは工場内のWi-Fiを経由して通信している。調整するオペレータ（作業者）はホストのOS Xに調整専用アカウントでログインして、調整専用アプリを起動する。そのアプリ上でユーザが操作を開始すると、そのアプリがRaspberry Piにログインして専用の小さなサーバを起動し、そのあとはOS XアプリとRaspberry Pi上のサーバがUDP経由でやり取りして光強度を測定してデータをホストに送ったり、ステージを動かしたり、ということをする。操作が終わればまたOS XアプリがRaspberry Pi上のサーバを終了させるようになっている。

見てみるとすぐにサーバが起動できていないことがわかった。Raspberry Piのホスト名やサーバ専用アカウントの名前やサーバのパスなんかは、OS X側のアプリのPreferecenceに書いてあって、環境設定パネルを開くと書き換えることができる。何かの拍子に書き換えてしまったんだろうと思ってPreferenceを捨ててデフォルトに戻したんだけど症状は変わらない。

ホストには僕のアカウントも作ってあって、そこでデバグして、ビルドしたアプリを調整専用アカウントから起動できるようにしてある。不思議なことにその僕のアカウントだと問題なくサーバを起動できて、装置として使うことができる。僕が書いたコードが原因ではないらしい。

調整の過程で得られたデータの保存先は専用アカウントの「パブリック」フォルダがデフォルトになってるんだけど、オペレータによって自分のWindowsマシンから見えなかったり、ホスト自身が「ネットワーク」に表示されなかったり、あるいは昨日は見えたのに今日は見えない、とかいうトラブルがずっと続いている。当然sambaは起動してあるし、工場のプライベートネットワーク内へは変な制限をかけてないし、だから何かWindows側の問題だろう、僕には何もできないので、そっちでなんとかしてくれ、ということにしてあった。

そのせいで、なんのためかよくわからないアプリがインストールされていたり、アカウントが修正されていたりしている。しょうがないので、ネットワークやアカウント周りの設定を調べて回った。でも直接影響しそうなものは見当たらない。そんなことをしているうちに深夜になった。僕は工場を施錠することができないので、しかたなくあきらめて今朝やり直すことにした。

今朝になって、OS XからRaspberry Piのサーバを起動するコードを見直した。こんなふうな簡単なものになっている（本当にまさしくこのまま）。

    NSString    *sshPhrase = [NSString stringWithFormat:
                              @"ssh -i ~/.ssh/id_rsa %@@%@ %@ >& /dev/null &",
                              workingUserName, serverName, commandPath];
    system([sshPhrase cStringUsingEncoding:NSASCIIStringEncoding]);

sshを使ってコマンドをリモート起動する文字列をunixのランタイムライブラリにあるsystem()でshに渡しているだけ。ようするにこれが失敗している。system()そのものはfork()やwaitpid()システムコールが失敗しない限り失敗しないので、戻り値のチェックさえしていなかった。また当然shから呼んだsshが失敗するなんて考えてもないので、出力は全部/dev/nullに捨てていた。

見てわかるように、sshはパスワード認証ではなくて、公開鍵を使っている。アプリケーションからsshを使うときは安全性や利便性から僕は必ずこうするし、それが普通だろうと思う。だからここでおかしなことが起こるとは全然思ってもみなかった。

ふと思って、Raspberry Piへのログインを自分で使っているMacBook Proからではなく、一旦ホストにしてるMac miniにログインして、そこからさらにRaspberry Piへログインしてみた。すると案の定パスワードを要求された。

秘密鍵はデフォルトの場所（調整専用アカウントの~/.ssh）に保存してあって、ターミナルからsshを起動してリモートログインすれば自動的に公開鍵を使った認証が有効になって、それが成功すれば（OS X側の秘密鍵で暗号化した認証コードがRaspberry Piに書いた公開鍵で解ければ）パスワードが要求されることはなく、ログインできる。

sshは親切で、ターミナルからログインしようとした場合、「id_rsaのパーミッションがゆるいので信用しないことにする、従ってパスワードを要求する」、とstderrに出してくれる。調べてみると本来「-rw- --- ---」でないといけない秘密鍵の書いてあるファイルid_rsaのパーミッションが「-rw- rw- rw-」になっていた。要するに誰でも書き換えることができるという状態。少なくとも僕が設定したときはこうではなかった。

sshの出力を/dev/nullに捨てなくてログでも残すようにしてあればすぐに気がついたはずだった。それは僕のまずかったところ。パーミッションを戻すとあっさり動いた。原因探索5時間、解決3秒。朝8時過ぎにクリーンルームに入って9時には解決できて、アサイチの作業から装置を使うことができるようになった。

あとはなぜパーミッションが変更されていたのか、という問題。これはもう追求は無理。工場の連中にsshが使う秘密鍵のパーミッションを変更できる人間がいないことは断言できる。今でもホストのMac miniのファインダからは.sshディレクトリは見えないし、そもそもそれが何かわかる人間もいない。

おそらく、ファイル共有のためにいろいろインストールされたアプリの中に行儀の悪いのがいて、ssh-keygenを起動しながらあとはほったらかし、というのがあったのだろう。

工場の彼らにしてみればWindowsで構築されたシステムだったら問題ないのに、僕が勝手にunix主体のシステムにしたのがそもそもの間違いだと言いたいだろう。他所の設備屋さんに頼めば今彼らが悩んでいるような問題はまったく発生しない。

でもこういったトラブルのせいで勝手に変なアプリをインストールするな、というような方向には僕はしたくない。バージョンの限定されたIEでないと保証しません、なんていう銀行屋のサイトにいい加減うんざりしてる僕が、同じようなことを言いたくない、というのがホンネ。また、前の会社で仕事で使うパソコンは完全お仕着せのWindowsノートブックだけで、勝手なアプリのインストールはまかりならん、HDDは全領域完全暗号化、クラウド禁止、そのくせバックアップは自分でやれ、で使い勝手は最悪だった。そういうマネもしたくない。

まあ、ネットワークの世界では実質的にunixが標準だと僕は思ってるし、工場の連中だけでなく、本社の連中も少しはWindowsのOfficeスイート以外の世界もあるということを理解してもらいたい。でないとすでに僕のせいでいろいろなところに入り込んでいるOS Xマシンと、それより台数は少ないけどそれ以上に大切な局面で使っているRaspberry Piが誰にも理解されないことになる。

例えば僕が明日死んだら、今回みたいなことがあったとき誰も何もできない。そうすると「ああ、Windowsのシステムにしておけばよかった」ということになって、そうすると設備の費用は何割か、物によっては一桁二桁上がることになる。つまり僕が前いた大企業が使うような生産設備と同じになって、今の会社のような零細企業には結局手にあまる、ということになりかねない。

僕はそういうことにはしたくないので、僕なりに努力しているわけだけど、それが実を結ぶのはまだまだ先のようである。