Monday, December 31, 2012

LinuxでNIC番号が思った通りにならない

よくあるトラブルのためのTIPSを1つ。

ディストロはRHEL系/Ubuntu系を問わず、表記のようなトラブルは多いと思う。

例えば、オンボードにEthernetが2port、拡張カードで 2port が搭載されているマシンにLinuxディストロをインストールするケースを考えよう。

この場合、ifconfig -a (等)でOSから見えるオンボードの2 port はそれぞれ eth0とeth1に、拡張ボード側は それぞれ eth2 と eth3 になってほしいと思うのが普通だと思う。

しかし、インストーラに任せておくと、往々にして以下のようなことが起こり、気付かないでいると、
正しく IP address 等を設定したはずなのに疎通がとれず、ハマることになる。

                               期待   実際
   オンボード1port 目   eth0   eth1
   オンボード2port 目   eth1   eth3
   拡張ボード1port 目  eth2   eth0
   拡張ボード2port 目  eth3   eth2

この場合、初期インストール時に udev が検出して ethX 等の名前を割りつけた順番がおかしいので、以下のファイルを直せばよい。

--------------------
認識順序がおかしかったものを手で修正後のサンプル。
[root@host08 ~]# cat /etc/udev/rules.d/70-persistent-net.rules
# This file was automatically generated by the /lib/udev/write_net_rules
# program, run by the persistent-net-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single
# line, and change only the value of the NAME= key.
# PCI device 0x8086:0x105e (e1000e)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:15:17:96:fe:42", ATTR{type}=="1", KERNEL=="eth*", NAME="eth2" ★インストール直後は "eth0" になっていた。

# PCI device 0x14e4:0x165a (tg3)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:22:19:b0:ce:e6", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0" ★インストール直後は "eth1" になっていた。
# PCI device 0x8086:0x105e (e1000e)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:15:17:96:fe:43", ATTR{type}=="1", KERNEL=="eth*", NAME="eth3" ★インストール直後は "eth2" になっていた。
# PCI device 0x14e4:0x165a (tg3)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:22:19:b0:ce:e7", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1" ★インストール直後は "eth3" になっていた。
--------------------

ところで、ここで問題になるのが、オンボードNICに対応するデバイス(ドライバ)がどれなのかを確認する方法。

完璧ではないのだが、私はこんな感じでやっている。

まず、OSから認識されている Ethernet Controller の一覧を調べる。
lspci コマンドを使い、以下のように grep で適当にフィルタする。

----
[root@host08 ~]# lspci | grep Ethernet
01:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5722 Gigabit Ethernet PCI Express
02:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5722 Gigabit Ethernet PCI Express
05:00.0 Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet Controller (rev 06)
05:00.1 Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet Controller (rev 06)
先頭がバス番号/デバイス番号。
----
このケースではオンボード+拡張ボードで合計4portの Ethernet port があり、バス/デバイス番号が若いもの(≒オンボード)は Broadcom のチップ、増設は Intel のチップだということが分かる。

特に、例えばIntel等、同じベンダ製のNICが6portとか付いている場合、へたをするとデバイスドライバが全部一緒になってしまい、判別に困ることになるが、現在OS上で認識されている ethX デバイスが、物理的にどのバス/デバイス番号に対応しているのかは、以下のように ethtool で
調べることができる。

----
[root@host08 ~]# ethtool  -i eth0
driver: tg3 ★デバイスドライバ
version: 3.124
firmware-version: 5722-v3.08, ASFIPMI v6.02
bus-info: 0000:01:00.0  ★バス番号
supports-statistics: yes
supports-test: yes
supports-eeprom-access: yes
supports-register-dump: yes
supports-priv-flags: no

[root@host08 ~]# ethtool  -i eth1
driver: tg3 ★デバイスドライバ
version: 3.124
firmware-version: 5722-v3.08, ASFIPMI v6.02
bus-info: 0000:02:00.0  ★バス番号
supports-statistics: yes
supports-test: yes
supports-eeprom-access: yes
supports-register-dump: yes
supports-priv-flags: no

[root@host08 ~]# ethtool  -i eth2
driver: e1000e ★デバイスドライバ
version: 2.1.4-k
firmware-version: 5.6-2
bus-info: 0000:05:00.0  ★バス番号
supports-statistics: yes
supports-test: yes
supports-eeprom-access: yes
supports-register-dump: yes
supports-priv-flags: no

[root@host08 ~]# ethtool  -i eth3
driver: e1000e ★デバイスドライバ
version: 2.1.4-k
firmware-version: 5.6-2
bus-info: 0000:05:00.1  ★バス番号
supports-statistics: yes
supports-test: yes
supports-eeprom-access: yes
supports-register-dump: yes
supports-priv-flags: no


----


サーバ系では最近は Intel か Broadcom の2択になることが多いと思うが、ethtool -i の出力の
driver: 欄に表示されたデバイスドライバが、具体的にどんなベンダのデバイス(Ethernet controller)
に対応するのかは、modinfo コマンドで調べることができる。

以下のような感じ。


----
[root@host08 ~]# modinfo tg3
filename:       /lib/modules/2.6.32-343.el6.x86_64/kernel/drivers/net/tg3.ko
firmware:       tigon/tg3_tso5.bin
firmware:       tigon/tg3_tso.bin
firmware:       tigon/tg3.bin
version:        3.124
license:        GPL
description:    Broadcom Tigon3 ethernet driver
author:         David S. Miller (davem@redhat.com) and Jeff Garzik (jgarzik@pobox.com)
srcversion:     554D5ED929C129F90580555
alias:          pci:v000010CFd000011A2sv*sd*bc*sc*i*
  : 
[snip]
----
なお、キッティングまで自分で行う場合は、ボード上にMAC addressが書いてあることが多いので、ifconfig -a の出力の中に HWaddr  と表示されている MAC address をみて付き合わせるのが一番である。
余談までに、同じベンダの同じ型番のNIC(=ドライバも同じ)で清一にした場合は、この事象はおきない「はず」…なのだが、例外をご存じの方は教えてほしい…。
---- ★以下のサンプルの下位3バイトはサンプルとして手で書き換えてある。
[root@host08 ~]# ifconfig -a | grep HWaddr
eth0      Link encap:Ethernet  HWaddr 00:22:19:01:02:10 ←最下位バイト
eth1      Link encap:Ethernet  HWaddr 00:22:19:01:02:11 ←最下位バイト(上と連番になるはず)
eth2      Link encap:Ethernet  HWaddr 00:15:17:03:04:20 ←最下位バイト
eth3      Link encap:Ethernet  HWaddr 00:15:17:03:04:21 ←最下位バイト(上と連番になるはず)
----
まとめ
表記のようなトラブルが起きた場合、以下のようなコマンドを駆使しておちついて対処しよう。
 * エディタ  (/etc/udev/rules.d/70-persistent-net.rules を編集する)
 * lspci
 * ethtool -i
 * ifconfig -a
 * modinfo <driver name>
特に、「あれ?ちゃんと設定したのに通信できない…」と思った場合は、ifconfig -a をたたいてみて、HWaddress の並びを確認してみよう。サーバ機であって、2port のカードを増設している場合など、MAC address が2枚ずつきれいにそろっていない限り、この事象を疑ってみる価値がある。

Sunday, December 23, 2012

Windows でのnetstat とかps(相当)とか

Windows系の些細なメモ。

とある IP reachable でない(がトンネルは張れなくもない)環境にある ESXi に vSphere Client で接続できるようにごにょごにょしていた時のこと。

Windows7 なPCの localhost:443 (tcp) をトンネルで遠くに向け変えようとしていたら、
"Address in use" で怒られるのに気がついた。

なぜ?誰が使ってんの?

…と、思っておもむろに netstat -antp とかたたくと、もちろん Windows と unix では書式が違うので怒られて ...orz となる。

軽く調べてみたところ、

| c:\> netstat -ano

で、PIDまで表示、


| c:\> netstat -anob

で、実行ファイル名まで表示できることが判明。

ちなみに、先に netstat -ano に気がついて、「じゃあこの PID って何?」というところで、
GUIのタスクマネージャではPIDが表示されないので困ったじゃん…ということで
またハマりかかったのだが、

| c:\ tasklist

で一覧表示ができるらしい。/? で出てくるヘルプをながめてみると、
ローカルだけでなくリモートにも使えるらしい…とか、
/SVC で(プロセスだけでなく、そのプロセスがサービスに属する場合は)サービスの情報なんかも
出るらしい。

コマンドプロンプトばんざい!w

さらに余談だが、「Windows Note なのに、いったい誰が TCP 443 なんか使ってるんじゃ!?」という問いの答は、実は「Skype.exe」なのだった...orz

こんな感じ。

c:\> netstat -anob

アクティブな接続

  プロトコル  ローカル アドレス          外部アドレス        状態           PID
  TCP    0.0.0.0:80             0.0.0.0:0              LISTENING       5488
 [Skype.exe]
  TCP    0.0.0.0:135            0.0.0.0:0              LISTENING       636
  RpcSs
 [svchost.exe]
  TCP    0.0.0.0:443            0.0.0.0:0              LISTENING       5488
 [Skype.exe]

# なんとなく理解できるような、やめてほしいような...w

Thursday, December 20, 2012

VMare Player 上での ubuntu 12.04 のハング

VMware Player で Ubuntu 12.04 LTS を動かし、かつ libvirt を使う場合に微妙にハマる件のメモ。

なんたらStackとか、ぷた☆すーをこの条件で動かす場合や、そこまでいかなくてもVMを動かす場合、以下のような現状に出くわすことがある。
  • virsh がハングする
  • shutdown がハングしていつまでもOSが落ちない
  • なんたらStackのような libvirt を呼び出すサービスの処理が途中で固まる
  • などなど
この場合、ps で調べてみて、実行中のまま終わらない dmidecode のプロセスがいたら
この件↓に該当するようだ。

http://askubuntu.com/questions/141720/why-is-sudo-virsh-hanging-in-the-console


RedHatでは先に直っていて、

https://bugzilla.redhat.com/show_bug.cgi?id=796451

libvirt側の問題らしい。
対処方法は、端的に言えばこのプロセスを殺せばよく、
$ killall dmidecode
等。
しかし、update package って出ないのかなぁ?(もしかして、もう出てたりしてw)

余談だが、書いておくかと思ってぐぐり直してみたら、日本語でも同じ内容の記事を書いている人がいたらしい。みんなハマるのねw


一般人の、一般人による、一般人のためのくら☆すた

これは、CloudStack Advent Calendar JP: 2012 の 12/20分エントリです。


みなさんこんにちは。
普段は CloudStack ではないナニカを触っていることが多い私ですが、CloudStack のことも、ずっと気になっていました。
なにせ、これだけ商用実績があるわけですから。

また、年度末に向けて絶賛デスマ^H^H^H活動中のオープンクラウド実証実験(OCDET)の活動の一環で、最近「基盤統合検証(オーケストレーション)WG」というのが発足しました。
端的に言うと、CloudStackなクラウドとOpenStackなクラウドをつないで運用できないか?という試みです。
私はこれにかかわっている事情もあり、いよいよ CloudStack に挑戦してみることにしました。

実は、初めて CloudStack をインストールしてみたときに驚いたことがあります。
私も遠巻きに眺めながら CloudStack が Java で開発されていることは知っていたのですが、CloudStack の Management Server(MS) が Tomcat のServlet Container の上で動いていることは知りませんでした。

どんな実装を使うにしても、運用する以上は、システム全体からSPOFになりうるコンポーネントを除去することは、誰でも考えると思います。

Management Server が Tomcat だということを知った時、「ああ、仕事でクラウドをやり始める前にかかわっていた、Web3層系システムのノウハウがそのまま使えるのだな」と思ったのを覚えています。

…と、いうわけで前置きがだいぶ長くなりましたが、CloudStack初心者の(でもTomcatを使ったwebシステム位はやったことがある) 一般人が手持ちの知識だけで頑張ってみるとどうなるか?

題して、
  「一般人の、一般人による、一般人のため CloudStack」
です。 :)

Management Server の冗長化のやり方はいろいろなノウハウがあるのだろうと思うのですが、そういう先人の知恵はこれから勉強するとして、Management Server を単純にTomcatとしてとらえた場合、素直に冗長化を考えると図1のようになるかと思います。(もちろんバリエーションはいろいろ考えられますが...)

今回は、Apache-Tomcat コネクタとして mod_jk を使って図1の赤い点線の中身を試してみます。
mod_jk と mod_proxy_ajp を比較すると宗教戦争になってしまうかもしれません(笑)し、nginxとかいろいろあるわけですが、私が mod_jk 選択した理由は単純に仕事で使ったことがあるからです。
冷静に見てみると、mod_proxy_ajp はなんといっても apache 本体に含まれていて安心な一方、
リカバリ処理の丁寧さでは mod_jk に一日の長があるようです。(と、私の周りの人間は言っていました...)

1. 準備

ベースOSとしては、Ubuntu 12.04 LTS(amd64)を使い、VMware Player で2台用意しました。
RedHat系のdistributionと比較すると、今回関連する範囲では Apache まわりで若干環境設定の癖に違いがあるとおもいます。

既に長くなってきているので、CloudStacker(?)の皆さんが良くご存じの部分ははしょって書きます。
  1. OS(Ubuntu 12.04 LTS(amd64))を入れます
  2. cloudstack 4.0 の apt line を設定します
    • 私は /etc/apt/source.list の末尾に以下の2行を足しました。
      • deb http://cloudstack.apt-get.eu/ubuntu precise 4.0
      • deb-src http://cloudstack.apt-get.eu/ubuntu precise 4.0
  3. Management Server をインストールし、単体で初期設定します。
    •  sudo apt-get install cloud-client
    • 通常の初期設定!設定!設定!
      • DBはもちろん片側に寄せておきます。
    • とりあえずWeb UIからログインできるところまでたどりついてください。
以下、私の場合のIPはそれぞれ Management Server #1 が 192.168.174.137、Management Server #2 が 192.168.174.129 です。

余談ですが、Management Server の起動スクリプトの /etc/init.d/cloud-management を良く見てみると、CATALINA_HOME 等が素の Tomcat とは違うところに向けられていることがわかります。

2. Tomcat 側の設定

 先にApacheからつなぎに行く先の Tomcat (=Management Server)の設定をしておきます。
  1. Apache-Tomcat 連携用の設定
    • Management Server #2 の /etc/cloud/management/server.xml に、以下のサンプルのような箇所があります。Management Server #2のほうは、jvmRoute プロパティのデフォルト値 jvm1 から jvm2 に書き換えておきます。この jvmRoute は、後で設定する mod_jk から見た、Tomcat の識別名になります。

      <Engine name="Catalina" defaultHost="localhost" jvmRoute="jvm1">
  2. Tomcat Cluster の設定
    • Management Server の片系ダウン時にログインセッションを引き継ぐために、セッションレプリケーションの設定を行います。これには、LBから apache/mod_jk のどちらにくるのかわからないため、セッション情報を知らない mod_jk にリクエストが渡されてしまうことがあるのに対応する意味もあります。
      …が、これは別途説明します。
設定の変更を行ったら、Management Server の再起動を忘れずに。
3. mod_jk のインストールと設定
  1. mod_jk (とapache2)をインストールします
    • sudo  apt-get libapache2-mod-jk
      • apache2 本体もインストールされます
      • また、以下の例ではノード数の節約のため、Management Server に Apache を同居させていますので注意してください。
  2.  mod_jk の有効化
    • sudo  a2enmod mod_jk
  3. mod_jkの環境設定
    • /etc/apache2/mods-enabled/jk.conf
      • 最低限、以下の2行を追加します。
        • JkMount   /client/*   wlb
        • JkMountCopy  All
      • また、トラブルシューティング用に状態表示用URLの jk-status を有効にしておくと良いでしょう。
        • 以下のサンプルのように、Location /jk-status に 適当にアクセス許可を追加しておきます。
        • <Location /jk-status>
                  JkMount jk-status
                  Order deny,allow
                  Deny from all
                  Allow from all ★ここ
          </Location>
    • /etc/libapache2-mod-jk/workers.properties
      • Management Server #1 と #2 用の定義を行います。マニュアルはここ
        http://tomcat.apache.org/connectors-doc/reference/workers.html
        から参照できます。
      • 私はこんな感じで設定しました。(コメント/空行を除く)
        以下に出てくる、jvm1 と jvm2 はTomcat の server.xml の jvmRouteで指定した値とあわせ、振り分け先の Tomcat の分は全部書いておきます。(重要)
      • workers.tomcat_home=/usr/share/cloud/management 
           ★/var/lib/tomcat6から変更(CATALINA_HOME)
        workers.java_home=/usr/lib/jvm/default-java
        ps=/
        worker.list=wlb,jk-status
        worker.jvm1.port=20400
           ★通常は 8009 だが、MSの servers.xml にあわせる。
        worker.jvm1.host=192.168.174.137 ★ MS #1のIP
        worker.jvm1.type=ajp13
        worker.jvm1.lbfactor=1
        worker.jvm2.port=20400
           ★通常は 8009 だが、MSの servers.xml にあわせる。
        worker.jvm2.host=192.168.174.129 ★ MS #2のIP
        worker.jvm2.type=ajp13
        worker.jvm2.lbfactor=1
        worker.wlb.type=lb
        worker.wlb.balance_workers=jvm1,jvm2
           ★MS 3台なら3台分書きます。
        worker.wlb.sticky_session=1
          ★スティッキーセッションの有効化
        worker.wlb.sticky_session_force=0
        worker.jk-status.type=status
        worker.jk-status.read_only=TRUE
         ★FALSEにすると worker のON/OFF等の制御も
           Web UIからできます。
        
        
  4. Apacheの再起動
    • 設定が終わったら Apache を再起動します。
      • sudo /etc/init.d/apache2 restart
4. mod_jk の管理画面にアクセスしてみる
    • 例えば、Apache #1(今回は同居させているので Management Server #1)の http://192.168.174.137/jk-status にアクセスすると、以下のような画面が表示されます。
    • ここで、URLにポート指定がなく、Management Server (Tomcat)が待っている tcp 8080 ではなく、Apache/mod_jk が待っている tcp 80 にアクセスしていることに注意してください。
    • 画面の中段に、Management Server #1 と #2に対応する worker の jvm1 と jvm2 がそれぞれどんな状態なのか表示されています。ACT と State が、両方とも ACT OK になれば正解です。
    • また、最下段に、tcp 80 (8080ではなく)の /client/ にアクセスされた場合の転送設定(JkMount) が表示されています。
5. Management Server にアクセスしてみる
    • 今回は、Management Server の jsp に以下のような一時的な細工を施し、mod_jk 経由で round robin でアクセスされた場合、どちらのサーバが反応しているのかわかるようにしました。
    • /usr/share/cloud/management/webapps/client/index.jsp の <body>部の先頭に、以下のホストの名前をベタ書きする。
      <body>
         <center><font size=20>
         Management Server #1 (または #2)
         </font></center>
           つづく… 
    • こうしておき、http://192.168.174.137/client/ にアクセスして何度もリロードすると、(ログインしてセッションが発生する前は)以下のように round robin で処理サーバ(Management Server)が切り替わることがわかります。
    • また、いったんログインしてしまうと(同じ Apacheにアクセスし続ける限り)Sticky Session の効果で、正しく同じ Management Server (Tomcat)で処理を続けられることがわかります。

ここまでできたら、もう一台 Apache を同じ設定で作成し、Apache側は完成です。
もちろん、mod_jkのもっとチューニングや、static contents の Apache側への配置などは、それはそれで深遠なノウハウがありますし、SSLの終端をApache/mod_sslでやるのか?L7バランサでやるのか、はたまた箱モノでやるのか…など、議論のあるところではありますが、それは別の話。

さて、Apache-Tomcat コネクタの設定が終わった後は、
  1. Tomcat Clusterの設定
    • これによって、Management Server 間でセッション情報を持ちまわれるようになり、どちらかが倒れた時もログインセッションを引き継げます。(はずです)
  2. フロントのバランサの設定
をするのですが、今日は時間切れということで、次回挑戦してみたいと思います。
#近日更新予定!

なお、図2は今回説明した範囲を示しています。

いかがでしょうか?
web3層系の知識だけでも、けっこう頑張れるということが分かるかと思います。

それではまた!

おぷ☆すた女子部の設計と実装

これは OpenStack Advent Calendar 2012 JP の12/20分のエントリです。

昨日の岡さんのJOSUG 2012年のニュースベスト5!でも第二位に入っていましたが、日本OpenStackユーザ会にも女子部ができました :)

その顛末を研究発表スライド風にまとめてみましたw


Wednesday, December 19, 2012

Dell PowerEdge R300 におけるIPMIの罠

非常に些細な話なのだが、ハマる人がいるかも知れないのでメモ。

Dell PowerEdge R300 という、比較的ローエンドなサーバ機がある。
リモート管理のためには拡張ボードを買わなければいけないことになっているのだが、
基本的なIPMI機能だけならオンボードで使えるようになっている。

IPMI用のEthernetのポートは、通常は専用のポートがあるわけだが、R300の場合はオンボードと共用で使うことになる。

さて、問題は、SOL (Serial-on-LAN)でBIOSやコンソールを取りたい時に、COM1 (ttyS0) と COM2(ttyS1)のどちらを使うべきかということ。


デフォルトは COM1 になっているのだが、文字化けがどうしても回避できないのでCOM2 を使うこと。

以下、参考リンク。


http://helvick.blogspot.jp/2010/08/ipmi-serial-over-lan.html

http://bgoglin.livejournal.com/13317.html



Saturday, December 15, 2012

ipmitool のエスケープキャラクタ変更

多量のサーバを取り扱う場合、いちいちマシン室に走ってディスプレイをつないで…なんてやっていられないので、IPMIはとても便利に使える機能だ。
電源On/Off だけでなく、BIOSやOSコンソールも使えるほか、各種の情報取得もできる。

実際の操作には、自分は ipmitool を利用している。

ところが、特にSOL (Serial-Over-LAN)でコンソールに接続して作業する際に困ったことがあった。
各所のDC等を利用していると、多段sshで乗り込まざるを得ないことも多いわけだが、
コンソールセッションの終了のキーシーケンスが、デフォルトでは

  ~.    (チルダを押した後、ピリオドを押す)

で、これがsshとかぶってしまっているため、コンソールセッションを終了しようと
すると、sshのセッションまで道連れに終了してしまう。

この場合の回避策として、ssh か ipmitool のいずれかのエスケープキャラクタを変更してしまえばよい。

参考までに、man ssh より。
|  -e escape_char
|         Sets the escape character for sessions with a pty (default:
|        ‘~’).  The escape character is only recognized at the beginning
|         of a line.  The escape character followed by a dot (‘.’) closes
|         the connection; followed by control-Z suspends the connection;
|         and followed by itself sends the escape character once.  Setting
|         the character to “none” disables any escapes and makes the
|         session fully transparent.

man ipmitool より。
| -e sol_escape_char
|          Use  supplied  character  for SOL session escape character.  The
|          default is to use ~ but this can conflict with ssh sessions.

ということで、見事に default が '~' (チルダ)で被っているが、これはいずれかを -e で
変更すればよい。
ssh側は各種の理由からデフォルトで使いたいので、ipmitool 側で ~ (チルダ)から & (アンパーサンド)に変更するとして、こんな感じ。

 $ ipmitool -U admin -P PASSWORD -I lanplus -h IP_ADDRESS -e \& sol activate

余談だが、-e ¥&の¥はもちろん、shell 上におけるエスケープ。

Wednesday, December 12, 2012

Santa Claraの思い出~東日本大震災とOpenStackコミュニティ~

OpenStack Advent Calendar 2012 JP の 12/12分です。

今日はコミュニティネタです。
技術ネタを期待していたみなさん、ごめんなさい。

話は東日本大震災の一ヶ月後にさかのぼります。
OpenStack第4版 Diablo リリースに向けた Design Summit が、カリフォルニア州サンタクララで開催されていました。
こんな↓感じです。

http://www.openstack.org/blog/2011/04/openstack-conference-and-design-summit-day-4-recap/

あまり国内では知られていないように思うのですが、本家OpenStackコミュニティでは、東日本大震災の直後、

http://www.openstack.org/blog/2011/04/openstack-community-supports-japan-tsunami-relief-efforts/

に写真があるようなTシャツをつくってDesign Summit/Conferenceの会場で販売し、赤十字経由で東日本大震災の被災者に寄付を行っています。私も総額は聞いていないのですが、Tシャツ本体分以外の寄付もあわせてけっこうな金額になったとのこと。
感謝です... :)

余談ですが、現地でのお礼の挨拶は、NTTデータ(当時)の木原洋一さんがされています。
http://techtarget.itmedia.co.jp/tt/news/1106/23/news03.html (要・会員登録)


さて、渡米前の当時、テレビや新聞で刻一刻と流れていく被災地の情報をみながら、私の心をとらえた新聞記事がありました。
東北には「津波てんでんこ」という言い方があるというのです。
Wikipedia によると、こんな感じ↓の意味のようですが、
  http://ja.wikipedia.org/wiki/%E6%B4%A5%E6%B3%A2%E3%81%A6%E3%82%93%E3%81%A7%E3%82%93%E3%81%93

私は以下のように理解しました。

津波がくるとわかったら、家族のことも大事な人のことも構わず逃げなさい。
てんでばらばらに。
なぜなら、彼らを助けに行く時間はないから。
彼らもあなたと同じように行動すると信じなさい。
それが、家族やあなたの大事な人々がともに生き残る唯一の手段なのだから。

ここからが本題です。

ぶっちゃけて言うと、当時、とある事情により、本家 OpenStack コミュニティの雰囲気はとても悪かったように思います。一日に何通もケンカ腰のメールが飛び交っていました。

本家コミュニティからの東日本大震災支援に日本のユーザ会から何かお礼ができないか?と考えていた私は、ふと、この本家コミュニティの状況下、「津波てんでんこ」の話を紹介したらどうかと考えました。

そこでこんなLT↓をつくってみたのでした。



英語の添削は Community Manager(当時)の Stephen Spector さんが引き受けてくれました。:)


表紙・裏表紙あわせて13枚しかありませんので、ぜひ上のLTを観てみてほしいのですが、忙しい人のために流れをまとめるとこんな感じです。

スライド7までは上に書いた「津波てんでんこ」の説明です。
「家族全員が生き残る」という目標のためには「てんでばらばら」にでも逃げなくてはいけないよ…と。

スライド8は、ところで「家族ってGENE (遺伝子) を共有する集団だよね」と。
スライド9で「コミュニティって MEME を共有する集団だよね」と、方向を切り替えます。
スライド10は、端的に言えば「1つのコミュニティの中でも意見の相違(や時には争いも)はあるよね…」
と持っていき、最後にスライド11~12で
「でも、目標を共有して、(ばらばらでも)ベストを尽くせば、ゴールは達成できるよね!」
と、まとめてみました。

いかがでしょうか?

LTも、硬軟おりまぜつつも、通常はほぼすべて技術ネタなので、(しかも英語なので..)かなり緊張しましたが、趣旨は伝わったようでした。:)


こんなコミュニティ活動もあるんだ…という参考になれば幸いです。