Project Airbase: プロジェクトアイディア

[hfu]

#214 直前の今考えるべきことではないかも知れませんが、 #221 での議論を踏まえ、 #205 Kalaja Architecture を踏まえて、Raspberry Pi 群をリモートに配置する形で研修環境を提供するというアイディアについて少し練ってみました。後で考えるためにおいておきます。

情報: Kalaja アーキテクチャ

基本的アイディア

• Raspberry Pi をリモート化した場合、問題となるのはアカウントの配布方法であろう。
• とりあえず、SSHキーベースのログインを求めるのが枯れていて順当であろう。
• 事前に公開鍵を集めておいて、jump host 及び hosts に ~/.ssh/authorized_keys をセットアップするという戦略でどうか。
• Ansible とかで構成管理をするのか。それとも、@yuiseki さんが以前実施されていたように、MicroSD 用イメージをセットアップするという手法をとる方が現実的か。

要検討事項

• マルチユーザにするのか、pi 相当のシングルユーザでやるのか。マルチユーザを実現するのは（UNIX的には普通であっても、）どれくらい面倒か。そもそも、ユーザ名を決めてもらったり、かぶりをチェックするのは面倒ではないか。メールアドレスがユーザ名になる、といったような割り切った運用にしたほうがよいかも。あるいは、機体番号を割り振って「jump host に入ったら、この機体番号の Raspberry Pi にログインしてね。この機体にだけあなたの公開鍵をセットしておきます。といった運用。」

ユーザーストーリー

1. 参加者は、ワークショップに参加したい。参加要領によれば、公開鍵を送れとあるので公開鍵を主催者に送る。
2. 主催者は、公開鍵に機体番号を割り当てて、参加者に案内を返す。
3. ワークショップ当日。参加者はまずジャンプホストにログインする。ジャンプホストにも公開鍵を登録してあるので、参加者はパスワードレスにログインできる。
4. 参加者は、案内に基づき、ジャンプホストから指定機体番号のRaspberry Piにログインする。ここもパスワードレスで進めることができる。演習はすべて指定機体で行う。
5. 演習の結果はIPFSに置かれるので、参加者はCIDを持ち帰ればデータを持ち帰ることができる。
6. ワークショップ後、一定のグレースピリオドを経て、主催者は機体番号のRaspberry Piをリセットする。公開鍵も処分される。

概念整理

1. jump host と Raspberry Pi 機体で構成される施設を Airbase（航空基地）と呼ぶことにします。Kalaja が多数からのリモートユース対応したもの（近代化したもの）が Airbase というイメージです。
2. Airbase とワークショップの場所がネットワーク的に近い、あるいは同一ネットワークである場合には、Airbase だけでワークショップができます。JICA 国家測量研修の場合はそのアレンジメントでしょう。
3. Airbase とワークショップの場所がネットワーク的に遠い場合には、ウェブ地図で致命的な低レイテンシー確保を「ワークショップの側に IPFS Node 及びゲートウェイを置く」ということで実施するべきかも知れません。ワークショップの題材にもよるでしょう。10MB程度のプロジェクトであれば、それほど気にする必要はないかも知れません。Airbase 側で add された CID をワークショップ側の Node で自動的に pin するみたいなことをするのかもしれません。

気になること

• Ansible を勤勉に書いていくということは SMG (Smart Maps Group) が得意とする技法（technique）に含まれるのだろうか。エンタープライズすぎたりしないか。
• IaaS や FileCoin を再発明するようなことになるのかもしれない。だとすれば逆にアリモノの技術があるのかも。

どう思いますか

@yuiseki @smellman @mapconcierge

[yuiseki]

メンションしていただいたので私の考えを共有しますが、私はJICAを始めとした研修に関しては利害関係者ではないので、無視していただいても構いません。

• 通信および認証方法に関して
  • 「事前にあなたのSSH Public Keyを共有してね」というメッセージの意味を正確に理解できるのは、かなり見込みのある優秀なソフトウェアエンジニアのみだと思われます
  • それで良いのだったら、これが一番安全で、良いと思います
• マルチユーザー vs シングルユーザーに関して
  • GISソフトウェアのセットアップの多くは、システムライブラリのセットアップなどが必要になりますよね
  • マルチユーザーにすると、ユーザー全員にシステムライブラリの状態が共有されるので、システムのセットアップ作業を体験してもらうという側面での研修やワークショップの意義が損なわれます
  • ワークショップとして、以下の二点をどう考えていますか？
    • UNIXのシステム管理運用者としての研修
    • GISの利用者・管理運用者としての研修
  • 研修がGISシステム管理者としての側面にのみフォーカスしたものであるのなら、
    • UNIXシステムのセットアップなどは既に事前に済ませてしまっておいて、GIS利用者・管理運用者としての側面にフォーカスしても良いかもしれません
      • この場合は、研修としては、ひたすら、全員にひとつ何かしらの成功を体験してもらうことにフォーカスして、「どうすればああいう体験がもう一度できるんだろう？」というところは自分で考えて学んで頂く、という設計になるかと思います

[hfu]

@yuiseki ありがとうございます！

• 確かに「公開鍵を送れ、はそれだけで敷居。」というところはありそうです。他方で、最近だと Windows でも ssh-keygen できるそうなので、この部分は修行として耐えてもらうといいなと思います。でも事前に送ってもらうことは諦めて、研修の頭で修行してもらって、公開鍵を何らかの形で送ってもらうという作り込みをした方がいいかもと思いました。
• 関連して「公開鍵さえ送れば主催者が機械的にセットアップする」とすると単に使いたい放題になってしまうので、公開鍵を受け取った時に、それがセットアップを要する公開鍵かは主催者が見極めなければならないのだなと思いました。
• 私の経験上、UNIX に対して好感を持ってくれる受講者は全体の8%以下で、残り92%以上は「UNIX を使わせる＝講師は不親切」という感情をお持ちになる傾向があります。そういうこともあり、UNIXのシステム管理運用者研修という性格は一般には持たせていません。UNIXのシステム管理運用者になるような人は、研修によらずになる、みたいな世界観です。
• 「UNIXシステムのセットアップなどは既に事前に済ませてしまっておいて、」「全員にひとつ何かしらの成功を体験してもらうことにフォーカスして、」「自分で考えて学んで頂く」というのは、私の理想としているところでした。限られた時間の中で成功体験を得てもらうためには「おまじないをすると魔法がかかった」というような体験をしてもらうことを狙うべきだ、と思っています。

[hfu]

pi-gen

@hfu 向けの備忘ですが、以前 yuiseki さんが使っておられたのは pi-gen でした：
#41 (comment)

[hfu]

Raspberry Pi Imager

私のシナリオ程度だと、Raspberry Pi Imager で authorized_keys ファイルの内容を指定する程度でニーズは満たせるのかもしれません。jump host からパスワードレスで入れるようにさえなってしまえば、バッチでのセットアップはいくらでもセットアップできそうな気もしてきました。

[hfu]

Add 'shuttle' on the workshop side

次の要件を満たす shuttle をワークショップ側に用意すればシンプルになる気がします！

• shuttle は Raspberry Pi で、ワークショップ側のネットワークにぶら下がっている。
• shuttle へのログイン情報は、ワークショップで提示する共通のものとする。
• shuttle には秘密鍵が置いてあって、その鍵は jump host に登録してある。
• ユーザはワークショップで提示されたIDとパスワードで shuttle にログインする。
• ユーザはさらに shuttle から jump host にログインするが、ここはパスワードレスになる。
• ユーザは jump host からそれぞれの研修環境にログインする。ここもあらかじめ設定してあるので、パスワードレスになる。

shuttle のイメージは、airport shuttle bus です。

セキュリティの検討

• ユーザが shuttle から秘密鍵を引き出してしまった場合、そのユーザは世界中のどこからでも jump host に入ることができるようになってしまう。
• 鍵ペアは定期的に交換することにして、ユーザとは信頼関係があるであろうから、上記のリスクは差し当たり甘受することにするか。

[hfu]

いまのところ、次のやり方なら手軽だなと思っています。

• jump host にはパスワードで入る
• jump host から各ホストには、jump host においた秘密鍵を共用して入る
• jump host のパスワードは頻繁に変更する
• jump host が使う鍵ペアもまずまずの頻度で取り替える

これである程度の安全は確保でき、参加者に共有するアカウント情報を一つにできるかな、と思っています。

[hfu]

#272 で実装中。
#274 によりクローズ。