【最新ITトピック】 googleドライブの利用規約に注意

5GB無料提供で話題のgoogleドライブですが、現行のgoogleサービスの利用規約を巡ってちょっとした盛り上がりを見せているようです。

IT media オツタナティブ・ブログ: GoogleはGoogleドライブに置かれたファイルのライセンスを取得したことになります

結局はサービス開始前に他社のサービスと同様のライセンスに置き換えられるのではないかと予想しますが、先に騒がれてしまえば、「はやり」という声があちらこちらから囁かれてしまうのも仕方のない事かもしれません。

Kinesis キーボードについてのメモ

当社では、かつてKinesisキーボードの輸入販売を行っていました。
正式な代理店ではありませんが、パーツ単位での供給も受け、簡単な修理も行っていました。

ただ、日本で誰が最初にKINESISキーボードを紹介したのか、ということに関しては、記録が見つかりません。
今分かっているのは、当社が最初に取り扱ったきっかけは自分ではなく、当時の店舗に来て頂いていた、とあるISPに所属される方からの依頼であるということです。
その方から腱鞘炎のために指を下げた状態で使うキーボード、つまりはKINESISが手に入らないかという話を聞き、当時は本多のオヤジさんの何でも入れてみろという方針もあり輸入を開始したのです。
おそらくその方の依頼がなければ、取り扱うことがなかったか、もしくは、取り扱いがもう少し先になったと思います。

現在は、国内に正規の代理店があります。
http://www.edikun.co.jp/kinesis/index.htm
一部の分離型キーボード(オリジナルのエルゴノミクス形状ではない)はサンワサプライでも扱いがあります。
【ぷらっとオンライン】サンワサプライ エルゴキーボード (SKB-ERG2)

ちなみに、HHK / HHK Liteについては面白いエピソードがあるのですが、それを書くことがないことを祈っています。

【最新ITトピック】 日本が技術立国であり続けるには何をすべきなのか

技術者の流出をただの人材戦略で片付けていいのでしょうか。

ロイター: 韓国サムスンが日本人技術者引き抜き加速、人材戦略弱い国内勢

日本は開発立国ですが、それは技術者のリソースを「安定した雇用」や「先端技術者としての誇り」を担保として得ていたからです。
そして、大きな資本の下で働かない限り、最先端の研究に携わることは難しく、築き上げた技術は会社あってこそとも思います。
技術開発は人の確保だけではなく、先端技術であればあるほど、コストがかかります。当然、ビジネスとして立ち上げるならば、それが将来のビジネスサイズに見合っているかの判断も必要です。技術は、単に理論や発想だけで成り立っているわけではないのです。

個人的な考えでは、研究開発に従事する人というのは、「安定した雇用」と、「人としての誇り」、を満たされることを重視していると思います。
しかし、「安定した雇用」がビジネスサイクルに合わないという判断をすれば、残った「人としての誇り」はどうやれば確保出来るのでしょうか。
それは結局、報酬であったり待遇であったりするのですが、今の日本の企業体質では非常に難しい。

実際のところ、
技術第一な人よりは、仕事は並でも趣味が多彩でスマートな人の方が人気があります。もしかすると良い評価を得てしまうかもしれません。
しかし、優秀な技術屋の多くは不器用です。本当に必要なビジネスシードを持っていても、良い評価が得られない場合が多い。

この矛盾が今の時代が作りだした不幸だと思います。

【最新ITトピック】 特許戦略は重要。しかし違和感も

日本のあるベンチャー企業の特許がクローズアップされています。

週刊ダイヤモンド: グーグルなど13社を訴えた国産ベンチャー驚異の実力

ただ、こういった利用技術は、それ以前に積み上げた様々な技術の上で成り立つものです。
多くの技術は、お互いのビジネスサイズを広げる基盤として纏められ、規格化されており、
特許も公開という形で留め、公知とする場合も多いでしょう。

ビジネス特許自体を貶める意図は全くありません。
しかし、利用技術に関しては、それら基礎を作り、踏み固めてきた経緯の上に成り立っていることを忘れて語られることは非常に残念だと思います。

【最新ITトピック】 SNSと付き合う以前の話として

現実を受け入れることは必要だと思います。

千秋日記: 134 ＳＮＳは『知らぬが仏』の世界

個人情報は何が何でも出したくない、というスタンスを取っても、結局は様々な手法で個人は特定されるし、一時的にでも取得された情報はそれが正しい手段であろうが、正しくない手段であろうが、どこかで個人を特定する情報として紐付けられているわけです。
結局のところ、個人として紐付けられて良い情報をしっかりと把握しておくこと、セキュリティ上のリスク、および有事の際のリカバリまでをシミュレーションしておくことが大事なのだと思います。

そして、ソーシャルネットワークの世界でも、意識してそういった押し出しをしておき、ソーシャルネットワーク上での人格形成をしっかり考えておく必要があります。

そう考えれば、ソーシャルネットワークに限った話ではありません。表向きの顔をしっかり意識して作るのは当たり前ともいえます。

【最新ITトピック】 AR/拡張現実は必要なのか

Googleもウェアラブルコンピューティングへのアプローチを発表しました。

ITpro: Google、ARめがねプロジェクト「Project Glass」を発表

カッコイイ
先進的

そんな言葉で、これまでもウェアラブルコンピュータは何度も話題に上がってきましたが、暫くすると消えていきました。
Googleも「やってみた」で終わるような気もします。
モバイルネットワーク網の充実により、AR(拡張現実)を支える情報バックエンドは揃いましたが、現実にはARが必要な場面は限られます。限られた時間、ハンズフリーでより多くの情報を得たい、「戦場」とも呼ばれるような場所でしょう。

では、実用性は無視して、これを情報トレンドとして定着させることが出来るかといえば、それはそれで、敷居が高いのではないかと思います。

まずデバイスですが、眼鏡の横についた投射デバイス、これは明らかに目立ちます。
それも悪目立ち。一度でも、HMDを着けて外を歩いた方ならお分かりでしょう。あれはダメです。
＃そういえば、レンズ内で投射する、少し厚めのサングラスの様な製品も試作発表されていたと思いますが、あれはどうなったのでしょうか。
デバイスも小さくなったから、というならば、過去にもMicroOpticalのSV-6がありました。今だから小さく出来ているわけでもありません。

人は歩くときは、歩くことに集中すべきだと思います。
そして、今だからこそ、人は情報から開放された時間を持つべきで、Googleに限らず、人と情報システムの在り姿を分析して、ガイドライン化することに、もっと力を入れる時期に来ているのではないか、と思います。
家庭用ゲーム機でさえ、「ゲームは1日１時間」という提案をし続けたわけですから。

小野秀貴: OpenFlow Controllerを用いてマルチホーム環境を活用する

◆はじめに

前回はOpenFlowスイッチの実装であるOpen vSwitchを動かしてみまし
た。今回はOpenFlowコントローラを導入して、Open vSwitchと接続
して制御してみます。

OpenFlowコントローラにはNOX, Tremaなどいくつかのオープンソース
実装があります。今回はおもにNECで開発されているTremaを利用して
みます。Rubyで容易に記述できるらしいということから選んでみました。

今回の目標は、
「マルチホーム環境でopenvswitchの配下にあるクライアントからの
  上流へのアクセス時に、特定のTCPポート(今回はSMTP=25)の通信
  だけ異なるrouterを経由するようにする」
ということです。

前回はOpen vSwitch単体動作で上記を実現しましたが、今回はOpenFlow
コントローラ経由でこれを実現したいと思います。



◆OpenFlowコントローラTrema導入

まずはTremaの導入に必要なものをインストールします。

 # aptitude install gcc make ruby ruby-dev irb file libpcap-dev libsqlite3-dev rubygems rake arping

なおarpingはTrema導入には必要ないですが、今回利用するためイン
ストールしています。

今回、Tremaはgemを利用してインストールします。
ただ、そのまま試してみるとrake1.8がないというエラーになるため
以下の対処をしておきます。

 # cd /usr/bin
 # ln -s rake rake1.8

ようやくtremaのインストールです。

 # gem install trema

これにはOpenBlockS 600Dでは30分以上を要しました。

2012年3月11日時点ではtrema 0.2.2.1がインストールされました。

 # gem list trema

 *** LOCAL GEMS ***

 trema (0.2.2.1)

実行ファイルtremaは/var/lib/gems/1.8/binにインストールされるので
ここにPATHを通しておきます。

 # PATH=/var/lib/gems/1.8/bin:$PATH

これで準備は完了です。



◆TremaでOpen vSwitchを制御

まずはTremaを起動してみます。
Tremaにはいくつかサンプルが附属しています。
L2スイッチ機能を実現したlearning_switchというサンプルを試して
みることにします。

 # cd /var/lib/gems/1.8/gems/trema-0.2.2.1/src/examples/learning_switch
 # trema run learning-switch.rb

tremaのswitch_managerが起動して、OpenFlowプロトコルのデフォルトTCPポート
である6633でOpenFlowスイッチからの接続を待っている状態になります。

 # lsof -i:6633
 COMMAND     PID USER   FD   TYPE   DEVICE SIZE/OFF NODE NAME
 switch_ma 32074 root    5u  IPv4 11451496      0t0  TCP *:6633 (LISTEN)

通常はOpenFlowスイッチとOpenFlowコントローラは別ホストですが、
今回は同一ホスト(OpenBlockS 600D)でOpen vSwitchとTrema両者を実行します。
なお、tremaを起動したコンソールはアタッチされたままなので、別
コンソールでOpen vSwitchの作業を行います。

Open vSwitchは起動している状態になっているとします。
Open vSwitchからOpenFlowコントローラ(Trema)への接続はovs-vsctlの
set-controllerコマンドで行います。同一ホスト内なのでlocalhost(127.0.0.1)
に接続します。

 # ovs-vsctl set-controller br0 tcp:127.0.0.1

なお、コントローラからの離脱は

 # ovs-vsctl del-controller br0

で行います。

前回と同様に以下のようなネットワークを構成します。

tremaとopenvswitchはobs600-3で動いていて、openvswitchはtremaに
接続している状態になっているとします。

ここでobs600-1上でrouter-1へのpingを実行します。

 obs600-1# ping -c 1 192.168.100.1

このときtremaからopenvswitchへはARP REPLY, ICMP ECHO REQUEST,
ICMP ECHO REPLYの3つのフローが登録されています。なお、ARP REQUEST
についてはtremaのlearning-switch.rbでは出力先のポートが未定
なためこの時点ではフローは登録されません。

 # ovs-ofctl dump-flows br0
 NXST_FLOW reply (xid=0x4):
  cookie=0x2, duration=4.156s, table=0, n_packets=1, n_bytes=98, priority=65535,icmp,in_port=2,vlan_tci=0x0000,dl_src=00:0a:85:04:93:99,dl_dst=00:00:00:00:00:01,nw_src=192.168.100.123,nw_dst=192.168.100.1,nw_tos=0,icmp_type=8,icmp_code=0 actions=output:1
  cookie=0x3, duration=4.146s, table=0, n_packets=1, n_bytes=98, priority=65535,icmp,in_port=1,vlan_tci=0x0000,dl_src=00:00:00:00:00:01,dl_dst=00:0a:85:04:93:99,nw_src=192.168.100.1,nw_dst=192.168.100.123,nw_tos=0,icmp_type=0,icmp_code=0 actions=output:2
  cookie=0x1, duration=4.17s, table=0, n_packets=0, n_bytes=0, priority=65535,arp,in_port=1,vlan_tci=0x0000,dl_src=00:00:00:00:00:01,dl_dst=00:0a:85:04:93:99,nw_src=192.168.100.1,nw_dst=192.168.100.123,arp_op=2 actions=output:2

これでlearning-switch.rbが期待通りに動作しているのが確認できました。

Trema確認中に少し気になった点があります。TremaはCtrl-Cで終了
するのですが、switch_managerプロセスが動作したままで、次回の
trema起動がうまくいかない状況になりました。とりあえずtrema run
の前にkillall switch_managerを行うことで暫定対処としました。



◆コントローラ用コード作成

今回の目的の
「マルチホーム環境でopenvswitchの配下にあるクライアントからの
  上流へのアクセス時に、特定のTCPポート(今回はSMTP=25)の通信
  だけ異なるrouterを経由するようにする」
を実現することを考えます。

基本的にはL2スイッチなのでtremaサンプルのlearning-switch.rbを
ベースにします。
上記を実現するためのコードを少し加えます(modified-learning-switch.rb)。
なお、既存部分で変更を加えていない箇所は掲載を省略しています。

 class ModifiedLearningSwitch < Trema::Controller

  add_timer_event :age_fdb, 5, :periodic

  add_timer_event :periodic_arp_request, 10, :periodic

  def start

    @fdb = FDB.new

    @target_routes = []

    @target_routes.push({ :route_dst => "192.168.100.1",

                          :route_dst_modified => "192.168.100.2",

                          :ip_src => "192.168.100.123",

                          :port => 25})

    periodic_arp_request

  end

  def packet_in datapath_id, message

    @fdb.learn message.macsa, message.in_port

    matched_route = nil

    @target_routes.each do |route|

      if message.tcp? &&

         message.tcp_dst_port == route[:port] &&

         message.ipv4_saddr.to_s == route[:ip_src] &&

         message.macda.to_s == route[:mac_dst]

        matched_route = route

      end

    end

    port_no = @fdb.port_no_of( message.macda )

    if matched_route.nil?

      if port_no

        flow_mod datapath_id, message, port_no

        packet_out datapath_id, message, port_no

      else

        flood datapath_id, message

      end

    else

      if port_no

        flow_mod_dstmac datapath_id, message, port_no, matched_route[:mac_dst_modified]

        packet_out_dstmac datapath_id, message, port_no, matched_route[:mac_dst_modified]

      else

        flood_dstmac datapath_id, message, matched_route[:mac_dst_modified]

      end

    end

  end

  ##############################################################################

  private

  ##############################################################################

  def periodic_arp_request

    @target_routes.each do |route|

      reply=`arping -0 -c 1 -w 100 #{route[:route_dst]}`

      if /from (\w{2}:\w{2}:\w{2}:\w{2}:\w{2}:\w{2}) \(([\d\.]+)\)/ =~ reply

        info "arping " + $1 + "=" + $2

        route[:mac_dst] = $1

      end

      reply=`arping -0 -c 1 -w 100 #{route[:route_dst_modified]}`

      if /from (\w{2}:\w{2}:\w{2}:\w{2}:\w{2}:\w{2}) \(([\d\.]+)\)/ =~ reply

        info "arping " + $1 + "=" + $2

        route[:mac_dst_modified] = $1

      end

    end

  end

  def flow_mod_dstmac datapath_id, message, port_no, new_mac_dst

    send_flow_mod_add(

      datapath_id,

      :match => ExactMatch.from( message ),

      :actions => [

                Trema::ActionSetDlDst.new( :dl_dst => Mac.new( new_mac_dst )),

                Trema::ActionOutput.new( :port => port_no )

        ]      

    )

  end

  def packet_out_dstmac datapath_id, message, port_no, new_mac_dst

    send_packet_out(

      datapath_id,

      :packet_in => message,

      :actions => [

                Trema::ActionSetDlDst.new( :dl_dst => Mac.new( new_mac_dst )),

                Trema::ActionOutput.new( :port => port_no )

        ]      

    )

  end

  def flood_dstmac datapath_id, message, new_mac_dst

    packet_out_dstmac datapath_id, message, OFPP_FLOOD, new_mac_dst

  end

 end

ざっくり動作を説明します。

まずは変更点として、periodic_arp_request methodで定期的にarp requestをrouter-1
とrouter-2に送信してMACアドレスを解決しておきます。これは処理するパケットのDST MAC
がrouter-1のMACにマッチした場合にrouter-2のMACに変更するということを実現する
ために必要になるためです。

openvswitchでフローが未解決パケットが到着したときには、OpenFlow プロト
コルでtremaに送信します。そしてtremaではpacket_inメソッドが呼ばれます。
learning-switch.rbではpacket_inでは通常は宛先MACアドレスを学習している
場合は、
 1. フローをOpenFlowスイッチに登録(flow_mod)
 2. 受信したパケットを該当ポートへ出力(packet_out)
という処理を行います。

今回の変更点として、特定の条件(ip_src = 192.168.100.123, dst_port = 25)
にマッチする場合は、
 1. フローをOpenFlowスイッチに登録
    ただし、DST MACアドレスをrouter-2のものに変更(flow_mod_dstmac)
 2. 受信したパケットを該当ポートへ出力
    ただし、DST MACアドレスをrouter-2のものに変更(packet_out_dstmac)
という処理を行うように修正しました。



◆動作実験

上記で作成したmodified-learning-switch.rbを実行します。

 # trema run modified-learning-switch.rb

Open vSwitchをTremaに接続します。

 # ovs-vsctl set-controller br0 tcp:127.0.0.1

obs600-1から外部のホスト(10.0.0.1)にsmtp接続します。

 obs600-1# telnet 10.0.0.1 25
 Connected to 10.0.0.1.
 Escape character is '^]'.
 220 smtp.example.org. ESMTP Postfix

このときのOpen vSwitchのフローの状態を確認します。

 # ovs-ofctl dump-flows br0
  - 省略 -
  cookie=0x9, duration=5.993s, table=0, n_packets=5, n_bytes=336, priority=65535,tcp,in_port=2,vlan_tci=0x0000,dl_src=00:0a:85:04:93:99,dl_dst=00:00:00:00:00:01,nw_src=192.168.100.123,nw_dst=10.0.0.1,nw_tos=16,tp_src=50729,tp_dst=25 actions=mod_dl_dst:00:00:00:00:00:02,output:1
  - 省略 -

dump-flowsでの確認結果には、mod_dl_dstが表示されています。
また、10.0.0.1のmailログでもrouter-2経由でアクセスされたログを
確認できので期待通りの動作を実現できました。



◆まとめ
今回はOpenFlowコントーラのTremaを利用し、Open vSwitchをTremaに
接続してOpenFlowプロトコルでフローが設定されることを確認しました。

また、Tremaのコードに修正を加えることで、特定の条件にマッチする場合
には異なるノードへ転送するようなフローをOpen vSwitchに設定する
ことができることを確認しました。