SVX日記

　 書斎、というか、工房の照明を点けようとしたところ、点かない。あれ？ 電球型蛍光灯が切れたか？ と思ったが、自作の赤外線リモコン制御ボックスのパイロットランプ的な、ゼビウスっぽい赤い光の明滅までもが点かなくなっている……えー!? 壊れたのか!?

　 電球型蛍光灯を別のソケットに取り付けると、点かない。少なくとも、今さっき電球型蛍光灯が切れたのは間違いない。すると、切れた瞬間に何らかの負荷がかかって、回路がぶっ壊れた？ とほほ。

　 構想はあるものの、作りかけで何年も放置してあったとはいえ、自作の機器が壊れるとショックだなぁ……って、あれ？ もしかして、ヒューズが飛んだだけということはないだろうか？

　 早速、バラし……って、バラし方も忘れちまっているが、どうにかしてバラし、ヒューズを取り出してみたら、案の定。ガラス管の内面に溶けた金属が糸状に張り付いていた。新しいヒューズに取り替えたら……よっしゃ！ ゼビウス軍復活！ しかし、電球型蛍光灯が切れるのと同時にヒューズが切れるなんて、やっぱり、切れた瞬間には何らかの負荷がかかる特性があるのだ、と考えるのが妥当だろうな。よくわからんが。

　 替わりの電球はどうしようか。LEDにするべきか。調光機能を組み込んで、うっすらと白熱灯を灯すか。部屋自体は、かなり暗い程度がいいんだけどな。

　 もう何年も前から、作り付けの机でプログラミングや電子工作や艦これに励んでいるのだが、最近どうも家で作業しているより、職場で作業しているほうが効率がいいような気がしてきた。いや、効率というか、家だと疲労が大きい気がする……特に腰が……って、そりゃ、脚立を椅子代わりにしてりゃ、当然か。

　 いい椅子と言えば、アーロンチェアがブランドだが、あんな10万以上もするバカ高い椅子を買うヤツの気が知れん、と思っていた。一方で、我が職場の椅子は、以前の社長が「社員の健康のために」と、それなりのものをアテがってくれたモノなのだ、と聞いていた。はて、何年も座り続けていてイマサラなのだが、どんな仕様の椅子なのだろう？

　 改めて、椅子を調べてみると「okamura」とある。聞いたことのないメーカ名だな、とアレコレ調べると、椅子の底に取扱説明書がくっついていた。「アドフィット」とある。たかが椅子に愛称があるなんて、大げさな……と思いつつ、愛称で検索してみて驚いた……え、この椅子、定価で7万もするヤツだったの!?

　 「椅子」というか「チェア」について、調べれば調べるほどに、たくさんの事実が浮かび上がってくた。「オカムラ」がオフィス家具のトップメーカであること。椅子に座っていることは、実はかなり体に悪いこと。メーカは用途に合わせ、相当な種類のチェアを出していること。オカムラの「バロン」というチェアがジウジアーロデザインであること。多くの人がチェアにコダわっていて、ネット上にはレビューも多くあり、家具屋で長時間試座してから、結構な金額のチェアを購入している人も少なくないこと……この頃にはすっかり「バカ高い椅子を買うヤツの気が知れん」という認識は「高価なチェアにはそれに見合う性能がある」に上書き更新されてしまっていた。

　 買う気になったら座りに行く。まずは、名古屋の栗田商会。オカムラのコンテッサ、バロン、サブリナほか、アーロンほかハーマンミラー、リープほかスチールケース、コクヨなど、多くのチェアが置いてあったが、運悪くなんかのフェアをやっていて、販売員にベッタリくっつかれて閉口した。落ち着いて座ってらんないのに、買う気が起こるかっつーの。

　 その足で、大塚家具へ。なんでも、以前はイチゲンさんお断りだったそうだが、例のお家騒動のおカゲで、フラッと見に行けるようになったらしい。ここにも多くのチェアがあったが、まずはオカムラのバロンが気に入った。しっくりくるし、リクライニングが無段階だし、ヘッドレストが動くのもいい。既にNikon F3、SUBARU SVXでジウジアーロデザインにはブランドロイヤルティ感じまくりだしなぁ。こりゃレッドバロンでメカズキン全滅を目指してみることになるのかなぁ。

　 エルゴヒューマンも悪くないがちょっとデザインがファンキーすぎ。コイズミファニテックのJGは値段の割に悪くない。ハーマンミラーのエンボディチェアは背中に異次元を感じるほどだが高すぎる。大塚家具でも販売員には付かれたが、そうシツこくもなく、のんびり試座できて、悪い印象はない。

　 と、ある程度「尻利き力」が付いたところで、改めてネット上の情報を漁る。バロンの後継っぽい、オカムラのコーラルが気になり始める。んが、試座してみないことにはなんとも。翌週には、名古屋港のファニチャードームに行き、改めてバロンのしっくり加減を再確認するも、コーラルは置かれておらず、モヤモヤ度が高まる。

　 こうなったら、本拠地に攻め入るしかない、と、名古屋駅ビル直上のオカムラのショールームに突撃。さすがは本拠地。ややバリエーションには不満が残るものの、コーラルを含め、大概のチェアに試座できる。天板が電動で上下する机も展示してあったので、高さを自宅の机の高さと同じ70cmに勝手に調整し、チェアと合わせてみたりもした。やはりコーラル、想像の通り悪くないが、エクストラハイバックが置かれておらず、ヘッドレストが試せない。ランバーサポートも。まーでも、コーラルに決めようかな、と思いつつ、ついでに少々下位モデルも試してやるか、とゼファー、スラート、シルフィー……って!? ナニコレ!? この左右のツマミ、チープっぽいのに、動かすとまったく別のチェアに変化すんだけど!?

　 なんでも、背もたれを背中に合わせられる、という触れ込みらしいが、個人的には、狭くしたカチッとモード、広くしたダラッとモードとして、使い分けられる機能だと受け取った。リクライニングが無段階じゃないし、ヘッドレストも動かないけど、肘掛けもボタン操作だし、前傾も採れるし、なんだかリクライニング量がスペック値より大きいように感じられる。いいじゃん、これ！

　 すっかりシルフィーに決めつつ、改めてネット上の情報を漁ると、普通にシルフィーが一番人気であることに気づいた。なーんだ、あなたってとっても人気なのね。

　 ちゅーわけで、最後まで背をメッシュにするかクッションにするか迷いつつ、昨晩クッションタイプを発注してしまった。シルフィ、おまえは……おれを裏切らない……な？

　 kugutsuスクリプトを完成する都合もあって、やたらFedora23とopenstackのインストールを繰り返していたことで、いろいろと気づいた点があったのでまとめておく。やっぱ、OSS関連の仕事をしている以上、たまにはマシンやデバイスを新調し、いろいろと気づきを得ることは重要だな。いくらソフトウェアのサポート要員とはいえ、OSだけ最新のLinuxを使っていたって気づけない点は多々ある。

　 とはいえ、ソフトウェアに関しても、角度を変えれば同じこと。何年も前にWindowsから開放されてヒャッハーな気分だったとはいえ、その反面、Windowsの操作に関しては、完全に素人以下になり下がってしまっている気がする。何度か使ってみたものの、まったく興味が湧かないAndroidも同じような状況。まぁ特段、生活にも仕事にも支障は出ていないのだからいいのだけれど。

　 それはそうと、気づきのひとつとはEFIブート。コンピュータが単細胞生物レベル(？)だった頃のピタゴラ装置的ブート機構をようやく今になって置き換えるものだ。EFIと言えば破廉恥なセキュアブート機構が話題だが、真の狙いのひとつはブート機構をスッキリさせることのはず……だったはずだが、なんだこれは。いつの間にこんなことに。

Fedora
UEFI:CD/DVD Drive
UEFI: Built-in EFI Shell
UEFI:Removable Device
UEFI:Network Device
UEFI: SanDisk SDSSDA120G, Partition 1
UEFI: SanDisk SDSSDA120G, Partition 1
UEFI: SanDisk SDSSDA120G, Partition 1
UEFI: SanDisk SDSSDA120G, Partition 1
UEFI: SanDisk SDSSDA120G, Partition 1
UEFI: SanDisk SDSSDA120G, Partition 1
UEFI: SanDisk SDSSDA120G, Partition 1
UEFI: SanDisk SDSSDA120G, Partition 1
UEFI: SanDisk SDSSDA120G, Partition 1
UEFI: SanDisk SDSSDA120G, Partition 1
UEFI: SanDisk SDSSDA120G, Partition 1

　 OSのインストールを繰り返しているうちに、ブートエントリが増殖してしまっているような……なんだこれ、消したいが、どうやって消しゃええんじゃ？

　 調べると、どうもEFIブートでは、ブート関連の設定情報をマザーボード上の不揮発性メモリ上に記録するようになっており、OSが起動した後も、その不揮発性メモリへのアクセスは可能らしい。いわゆる稚拙なBIOS画面でゴチャゴチャと操作しなくてもよくなったということか。具体的にいうと、Linuxでは擬似ファイルシステムとしてアクセスが可能であり、Fedoraでは/sys/firmware/efi/efivars/にmountされている。

　 んが、ディレクトリの中身をlsで見てもほぼハナモゲラだ。エントリ数も妙に多い。何をどうすればいいのかよくわからんが、ブートエントリを操作するために、efibootmgrというツールがあるらしい。試してみたところ「efibootmgr」でリスト表示をさせて「efibootmgr -b 0000F -B」のようにしたら重複エントリを消すことができた。

　 このefibootmgrがエントリを消す際、具体的には何をしているのか気になったので、straceで処理内容を覗いてみたところ、普通に擬似ファイルシステムに対して、削除や書き換えを行なっているだけだった。ふむん。EFIってそんなモンなのね。

　 んが、消したそばからまた増える……もぉええわ。

　 さて、もうひとつの気づきはLinux OSのキックスタートインストール。この機能を使えば、最初に設定内容を渡すだけで、インストール完了までのすべての操作を自動化できるというシロモノ。openstackの環境用には2台のマシンを用意していることもあり、省力化の程度は大きい。

　 具体的には、インストールDVD-ROM等からブート、直後に表示されるメニューの「Install Fedora 23」に移動し「e」キーを押下、以下の★部分の後ろにパラメータを追記することにより行う。

setparams 'Install Fedora 23'
linuxefi /images/pxeboot/vmlinuz inst.stage2=hd:LABEL=Fedora-S-23-x86_64 quiet ★
initrdefi /images/pxeboot/initrd.img

　 追記内容は以下。

selinux=0 inst.ks=http://server/anaconda-ks.cfg

　 ちなみに「selinux=0」は、インストール開始時点からSELinux機能を無効化する指定で、これによりハナから各ファイルに拡張属性が付与されることを完全に防ぐことができる。

　 続く「inst.ks=http://server/anaconda-ks.cfg」が、キックスタート機能に渡す設定内容。いったんキックスタートを使わずにインストールした場合に/rootに生成されるanaconda-ks.cfgを再利用する。読み込む場所はいろいろと選べるようだが、今回は手持ちのウェブサーバ上に置いて読み込めるように取り計らったので、冒頭がhttp://となっている。

　 追記が完了したところで「Ctrl-x」を押下すれば、完全自動イントールの開始……かと思ったが、なんだかネット上のFedoraリポジトリを見つけられない様子で、そこから先に進まない。特にマズってるところはないはずなのだが……と思ったら、なんと不具合とのこと。

　 普通、OSの導入後の不具合ならば修正パッケージで対応されるのだが、この問題は導入後に起きてるんじゃない……導入前に起きてるんだッ！……ということで、一体どうすんのかと思ったら、なるほど、そういう場合のための機構があるのね。キックスタート機能と同様に、修正内容を渡すことができる機構が。つまりこう。

selinux=0 inst.ks=http://server/anaconda-ks.cfg inst.update=http://server/1277638.img

　 これで完全自動インストール、いっちょ上がり！

　 どうも本格的に使う前に、味見するだけで相当かかりそうなopenstackであるが、イメージサービス「Glance」が、オブジェクトストレージ「Swift」を利用していないことに気づいてしまった。せっかくなので上に載せてみたい。

　 んが、どうもpackstackによりインストール時からその状態にすることはできないようで、インストール完了後に設定を行う必要がありそうな感じ。openstackについては、まだ右も左もわからない状態なので、そのまんま「glance swift」としてググってみる。すると、容易に「ObjectStorage Service をイメージの保管に使用する方法」などという、ほぼそのまんまっぽい情報が見つかった。

　 ところがその通りに設定してもダメ。glance-apiが「ERROR: Store forscheme swift not found」とかいって起動しない。なんじゃこりゃ。

　 そもそも認証とかエンドポイントの概念について、ほとんどわかってないんだよな。コマンドラインからkeystoneでトークンをもらってみたり、telnetでhttp://xx.xx.xx.xx:5000/v2.0/につないでみたりしてみる。なるほど。エンドポイントとはURIであり、httpのPOSTで認証情報と命令を送り、結果を受取るわけか。

　 と、極めて初歩的な気付きが得られたものの、Glanceのエラーについてはサッパリわからず。manページを眺めたり、confをgrepしたり……って、ん？ schemeって、storeのタイプってこと？ もしかして、こうか？

# vi /etc/glance/glance-api.conf
  :
# List of stores enabled (list value)
stores=swift,file,http
  :

　 おぉ、glance-apiが上がるようになった。なんだよ、一番大事な設定が抜けてたんじゃねぇか。ちゃんと書いておけよな。ブツブツいいながら、Horizonのadmin権限で、Fedora23のイメージをGlanceに登録してみた。成功。これで、オブジェクトストレージを見に行けば、イメージがオブジェクトとして登録されているはず……と思ったら、登録されてない。なんで？

　 fileとして登録されているFedora23のイメージが/var/lib/glance/imagesの下に存在していることはわかっている。加えて、swiftとして登録されているであろう同程度のサイズのファイルが、/srv/node/device1/objectsの下にも存在していることもわかっている。

　 もしかして、Glanceユーザのテナントに配置されている？ Glanceユーザでなんて、ログインできるのかしらん。Horizonにログインするにはパスワードいるよな。設定した覚えはないが……って、もしかしてアレか。/etc/glance/glance.conf的な設定ファイルの中に自動設定されているとか？ ビンゴ！

# cat /etc/glance/glance-api.conf | grep -i password
admin_password=****************

　 HorizonにGlanceユーザとしてログインしオブジェクトストレージを見に行ったら……あった！ glanceコンテナの中にそれっぽいサイズのオブジェクトが。なるほど、そういう仕組みなのね。

　 で、この設定もkugutsuスクリプトに起こしてみた。こうだ。

#===========================================================================
#
#   glance のバックエンドを swift に変更
#
kgt.execs([
    kgt.systemctl(%w!status openstack-glance-registry!),
    kgt.systemctl(%w!status openstack-glance-api!),
])
 
swift_store_auth_address, swift_store_key =
    kgt.get_params('/etc/swift/proxy-server.conf', ['auth_uri', 'admin_password'])
 
kgt.modify(
    '/etc/glance/glance-api.conf', [
    kgt.ss_set_param('stores=',                                 'swift,file,http'),
    kgt.ss_set_param('default_store=',                          'swift'),
    kgt.ss_set_param('swift_store_auth_address=',               swift_store_auth_address),
    kgt.ss_set_param('swift_store_create_container_on_put=',    'True'),
    kgt.ss_set_param('swift_store_user=',                       'services:swift'),
    kgt.ss_set_param('swift_store_key=',                        swift_store_key),
])
 
kgt.execs([
    kgt.systemctl(%w!restart openstack-glance-registry!),
    kgt.systemctl(%w!restart openstack-glance-api!),
])

　 ならばよし！

　 ウェブサービスなどを構築する場合、メールをトリガに処理をさせるのは良いアイデアだと思っており、事実、多用している。

　 なにが良いって……

・メールを送信できる端末はどこにでもあり、どこからでも要求を送信できる
・メールというインフラは、概ね信頼性が高く、障害でメールが消失しにくい
・任意のタイミングで(周期的に)要求を受信(POP)し、処理できる
・必要なら即座に応答を送信(SMTP)できる
・処理に失敗したら、メールを削除しなければ、再度要求を受信(POP)できる

　 ……などといっても、普通の人にはまったく実感できないことであろうが。要するに、汎用のキュー機構として使い勝手がいいってことだ。

　 ひとつのメールアカウントに到着した要求を、複数のサービスで処理することもできる。fetchmailとprocmailを使い、複数のメールアカウントに転送するのである。各々のサービスは、各々のメールアカウントに到着したメールをトリガとし、メールの内容を見て、自分が処理すべきメールであれば処理し、そうでなければ単に読み捨てればいい。

　 んが、ここで問題。ひとつのメールアカウントに到着した要求を「ホストをまたがった」複数のサービスで処理することが難しいのだ。

　 そんなの、メールアカウントAから、ホストBがメールを受信し、ホストB上のサービスC, D、および、ホストE上のサービスF, Gにメールを転送すればいいじゃん、procmailには、ホスト間のメール転送機能もあるでしょ？ といわれればそのとおりなのだが、それはイマイチなのである。

　 なぜならば、ホストBが死んでしまった場合、ホストEのサービスも止まってしまうからである。そもそも、ホストBとホストEとは対等な立場なのだから、実装も対等にするべきなのである。

　 そうなると、ホストBとホストEが、等しくメールアカウントAにアクセスする構成を採らざるを得ないのだが、ホストBがメールを受信して削除してしまうと、ホストEがメールを受信できなくなってしまう。その逆も起こりうる。片手落ちこの上ない。ならばと、メール受信後もメールを削除しなければ、双方でメールを受信させることが可能になるのだが、今度はメールボックスを溢れさせることになる。

　 んが、この解決は別に難しいことではない。

　 メール受信後も即座にはメールを消さないが、しばらく経ったメールは消す

　 ……という動作ができればいいのだ。しかし、fetchmailにはそのような機能がないようなのである。

　 これ、ニッチな機能のようであって、実はかなり有用な機能なのだ。というのも、複数の環境でメールを処理する場合、例えば、本宅と別宅で同じメール環境を持ちたい場合に「しばらく」の長さを、双方のPOP間隔より長めにすることにより、双方に同じ内容のメールボックスを維持できるようになるからである。

　 というか、それって拙作のメールクライアント「mave」で既に実現されている機能じゃねぇか……というワケで、POP機能の部分だけ切り出し、パイプでprocmailに渡すコードだけ追加してみた。その名も「pinchmail」。「fetchmail」の代わりとなる物件だから、敢えて名前も似せてみた。

　 この「pinchmail」を、ホストB, E の両方に導入し、crontabで周期動作するように設定すれば、両者は対等であり、すべてのメールを処理することができるようになる。

　 パッケージを置いておく。

　 というわけで注文したシルフィが届いた。どうやって届くのかと思ったら、配達員がトラックの荷室内で梱包を解き「そのまま」の形を担ぎ上げ玄関の中に納品してくれた。

　 既にウレタンキャスターに交換してもらってあるので、そのままフローリングへ。必要ならチェアマットを敷こうと思ったが、必要なさそうな印象。

　 パッと座った感じは、当然ながらショールームと同じ。レビューするにしろ、何ヶ月かは座ってからのが適当だろうから、今日はここまで。

　 ……と、それとは別に、実は前から興味があった「BC-101」というバランスチェアも購入していたのであった。座ってみると、確かに腰が伸びてラクな感じを受けるのである。

　 小学生の頃などには、椅子をナナメに前に倒して座っていて「行儀が悪い」などと怒られるシーンはありがちだが、よく考えれば、ある意味、あの座り方こそが「腰を伸ばしたい」という、身体の自然の要求に基づくものなのである。

　 嘉門達夫の小市民という歌には「イスでバランスをとっていて、うしろに倒れる小市民」というフレーズが出てくる。実際、皆がそれをやりがちであるというところに面白さがあるわけで、それを「行儀が悪い」などと単純に片付けてはいけないのだ。そこには商品開発のヒントとなりうる深いニーズがあるのである。

　 すると、同歌の中にある「授業中シーンとしてる時にオナラをしてしまい、イスをギーギー言わしてごまかしてる」というのも、深くニーズについて考えるべき余地がある。まさにごまかすために「ギーギー」という音をたてる機能を付けるのは合理的という事になる。むしろ、椅子を少し動かすだけで、しばしば「ぶぅ！」というオナラのような音を出す椅子なら、ごまかす必要すらなくなる。どうすか、オカムラさん！

　 別ジャンルではあるが、同歌の中にある「蚊にかまれた跡に、ツメでバツ印をつける」というのも、深くニーズについて考えるべき余地がある。要するに「カユい場所には、カウンタアタックが有効であり、むしろ痛くしてしまいたい」という事になる。悪影響がない程度に痛くしてしまう塗り薬があればいいわけだ。どうすか、製薬会社の方！

　 こういうアホな考えって、わかっちゃいるけどやめられない、あーやめられない♪

　 ちなみに、バランスチェアは、しばらくはラクだが、良い姿勢を強要されるので、長時間の作業には向かない感じだった。今はガキが食卓で勉強に食事に気に入って使っている……のだが、やはりというか、膝を当てる部分に足を置いたりしてちゃんと座らない。しかし、それを「行儀が悪い」などと単純に片付けてはいけないのだ。そこには商品開発のヒントとなりうる深いニーズが……。

　 ふと、バイナリファイルを比較する必要が生じたので、そういうツールがないものか探してみたところ、bsdiffというツールがみつかった。早速、使ってみたのだが、これは、バイナリパッチを作るためのツールっぽい。ワシがしたいんは、化けた箇所を見つけるみたいなことなんやけど。

　 しゃーないので、サクッと作ってみた。うんうん、こういうの。ワシが欲しかったんは、こういうのなんやッ！ ……って、完成した頃には、何のためにバイナリファイルを比較する必要があったのか忘れてしまっていた。うわっ……私の記憶力、悪すぎ……？

　 オマケにこの記事を書こうと思って、改めて似たようなツールがないものか探してみたところ、vbindiffというツールがみつかった。なんや、やっぱりあるやんけッ！

　 まぁ、既存のライブラリを流用したらサクッとできたし、結果をダンプ出力っぽく得られるという点では、こっちのが便利なのでいいんだけどさ……それより、何のためにバイナリファイルを比較する必要があったのか気になるわ……オレ。

　 パッケージを置いておく。

　 openstackの評価、なんてつもりはないのだが、自作のオートパイロット機構「kugutsu」のスクリプトを書いたり、走らせたりするのが楽しくなってしまい、しつこくFedora23とopenstackのインストールを繰り返してきた。んが、いいかげん、何かに活用していきたいので、一段落する意味も込めて、ひと通りの手順をまとめておくことにする。

　 まず、OSのインストールはキックスタート。安物のUSBメモリから起動し、起動パラメータに「selinux=0inst.ks=http://server/anaconda-ks.cfg」を追記してウェブ経由でキックスタートファイルを渡す。

　 OSのインストールが終わったら、再起動してデスクトップPCからopenstackインストール前の下準備。コントローラに「kugutsuprep_openstack_fed23.kgt troll」コンピュートノードに「kugutsuprep_openstack_fed23.kgt pute」を一撃ずつ、並行して実行させる。

　 完了後、コントローラにsshでログインして「packstack--answer-file=answer_file」を一撃。

　 完了後、再び、デスクトップPCからopenstackインストール後の処理。コントローラに「kugutsu prep_openstack_fed23.kgt troll -l 219-」を一撃。ブリッジの作成、glance のバックエンドの swift への変更、テナントの作成までが行われる。

　 ここからは、openstackのウェブUIで初期設定を行う。やろうと思えば、この処理もkugutsuで実行可能だろうが、ウェブUIは普段の運用で使うものだし、理解のためにも手作業で行う。

　 openstackのウェブUIであるDashboard(Horizon)は、コントローラ上のウェブサーバで提供される。具体的には、ブラウザで「http://troll0.itline.jp/dashboard/」にアクセスする。

　 まずは、管理者であるadminでログイン、パスワードはコントローラの/root/keystonerc_adminに書いてある。

[root@troll0 ~]# cat keystonerc_admin | grep PASS

　 adminユーザで操作するときに注意が必要なのは、プロジェクト(テナント)利用者としての操作か、openstack管理者としての操作かを意識して区別する必要があるってことだ。前者の場合、左のペインの「プロジェクト」の中、後者の場合、左のペインの「管理」の中の操作となる。特に「ネットワーク」は両方にあるので、これに気づかないとドツボだ。

　 一番にやるのは起動イメージのGlanceへの登録(ダウンロード)これは管理者として行うので「管理」の「イメージ」から「イメージの作成」を行う。「名前」は適当に「Fedora23」「イメージの場所」は「http://ftp.iij.ad.jp/pub/linux/fedora/releases/23/Cloud/x86_64/Images/Fedora-Cloud-Base-23-20151030.x86_64.qcow2」「形式」は「qcow2」「パブリック」と「保護」にチェックを入れる「イメージの作成」だ。当然ながら、ダウンロード完了までにはしばらく要する。

　 次にやるのはパブリックネットワークの登録。これも管理者として行うので「管理」の「ネットワーク」から「ネットワークの作成」を行う。「名前」は適当に「public」プロジェクトは「admin」プロバイダーネットワーク種別は「VXLAN」セグメントIDは「0」。「共有」と「外部ネットワーク」にチェックを入れる

　 ちなみに、プロバイダーネットワーク種別のVXLANは、packstackのanswer_fileでneutronに設定した以下のパラメータと一致させる必要があるっぽい。

CONFIG_NEUTRON_ML2_TYPE_DRIVERS=vxlan
CONFIG_NEUTRON_ML2_TENANT_NETWORK_TYPES=vxlan

　 ネットワーク名「public」をクリックして、ネットワークにサブネットの作成を行う。「サブネット名」は適当に「public_subnet」。「ネットワークアドレス」は物理マシンとして所属しているネットワークアドレスで「172.24.0.0/24」とか「192.168.0.0/24」など。「ゲートウェイIP」は大概ルータだろうから「172.24.0.1」とか「192.168.0.254」など。

　 「IPアドレス割り当てプール」はopenstackとして仮想マシンに付与するためのフローティングIPを割り当てる範囲なので、ルータのDHCPレンジを避ける必要がある。ルータのDHCPレンジが192.168.0.1〜192.168.0.99なら「192.168.0.100,192.168.0.249」とかになる。「DNSサーバ」は大概ルータだろうから「172.24.0.1」とか「192.168.0.254」など。

　 一応、管理者としての作業は一段落。次はユーザとして作業を行うので、ログアウトし、ログインし直す。もしくは、別のブラウザを開いてもいい。ホントは別のタブで管理者/ユーザの操作を並行して行えるといいのだが、cookieの都合か、同じブラウザだと並行作業ができないようだ。

　 kugutsuでユーザテナントの作成を行なっている場合、ユーザが登録済なので「ユーザ名」が「mitsu」と「パスワード」が「mitsu123」でログインできる。

　 最初にやるのは、セキュリティ関係。「プロジェクト」の「アクセスとセキュリティ」の「セキュリティグループ」から「セキュリティグループの作成」を行う。

　 openstack内で立ち上がる仮想マシン(インスタンス)には、openstackの機能として標準的にパケットフィルタが備わっており、何も考えずインスタンスを立ち上げると何のパケットも通らず、後で首をかしげることになる。そのため、まずはフィルタリングしないセキュリティグループを定義する。

　 「名前」は適当に「open」として「ルールの管理」で「ルールの追加」から「ALL ICMP」「ALL ICMP」「ALL TCP」「ALL UDP」の受信を許可するルールを加える。これで、インスタンスの起動時にこの「open」を付与することで、すべてのパケットの送受信が許容されるようになる。

　 次は、インスタンスへのsshログインに使うsshキーの登録。「アクセスとセキュリティ」の「キーペア」から「キーペアのインポート」を行う。

　 「キーペア名」は適当に「user_host」などとして「公開鍵」に「ssh-rsa AAAAB3Nz...JWgDura3 user@host」みたいなのを貼り付ける。公開鍵は、普段からLinuxで端末作業をしていれば、普段の端末から「cat ~/.ssh/id_rsa.pub」して表示されるものがそれである。Windowsなんかだとsshキーの生成ができないので「キーペアの作成」を行う必要があるかもしれんが……以下、このエントリを参照のこと。

　 最後に、フローティングIPをいくつか確保しておく。「アクセスとセキュリティ」の「Floating IP」から「Floating IPの確保」を行う。「プール」は「public」のはず。「IPの確保」を行うと、上述した「IPアドレス割り当てプール」の範囲から、ユーザにフローティングIPが貸し出される。たぶん「172.24.0.201」とかが確保されたはず。これをインスタンスに付与することで、外からインスタンスに直接アクセスが可能になるという寸法だ。ついでなので「172.24.0.202」「172.24.0.203」と余計に確保しておく。

　 次にやるのはテナント内ネットワークの構築。「ネットワーク」の「ネットワーク」から「ネットワークの作成」を行う。最初から存在している「public」は、先ほどopenstack管理者として作った外部ネットワークだ。

　 「ネットワーク名」は適当に「private1」。「サブネット名」は適当に「private1_subnet」「ネットワークアドレス」は完全に好みなので「192.168.0.0/24」など。「ゲートウェイIP」は後に仮想的に設置するルータのアドレスなので「192.168.0.1」などにしておく。

　 「IPアドレス割り当てプール」は内部的に割り当てる範囲なので、適当に「192.168.0.100,192.168.0.199」とかになる。「DNSサーバ」は大概ルータだろうから、上と同じく「172.24.0.1」とか「192.168.0.254」など。

　 ネットワークが複数あるのだから、ルータでつなぐ必要がある。「ネットワーク」の「ルータ」から「ルータの作成」を行う。「ルータ名」は適当に「router1」。「外部ネットワーク」は当然「public」。これにより「public」側につながったから、次は「private1」側につなぐ。

　 ルータ名「router1」をクリックして「インタフェイス」から「インタフェイスの追加」を行う。「サブネット」は「private1」。「IPアドレス」は「192.168.0.1」。これにより、「private1」が「router1」を介して「public」につながったことになる。先ほど「ゲートウェイIP」として登録したのは、このルータのインタフェイスだったわけだ。この様子は「ネットワーク」の「ネットワークトポロジ」で確認できる……んが、この表示、ちょっと凝り過ぎではないか。ネットワークがゴムひものように表現されており、機器をドラッグするとビョ〜ンボョ〜ンと動く。面白いが、必要性がわからんわ。

　 ネットワークが完成したところで、次はストレージ。USBのポータブルハードディスクを買ってきて接続するイメージ。「コンピュート」の「ボリューム」から「ボリュームの作成」を行う。「ボリューム名」は適当に「volume1」。「容量」は「1GB」でいいだろう。

　 ボリュームも用意できたところで、いよいよインスタンスの立ち上げ。「コンピュート」の「インスタンス」から「インスタンスの起動」を行う。「インスタンス名」は適当に「carmilla」。「フレーバー」は「m1.small」。「インスタンスのブートソース」は「イメージから起動」。「イメージ名」は「Fedora23」。一番最初にGlanceへ登録した起動イメージ名だ。

　 まだ起動はできない。「アクセスとセキュリティ」の設定が必要だ。「キーペア」は「user_host」。「セキュリティグループ」は「open」。いずれも、上記の作業の中で定義したものだ。最後に「ネットワーク」の設定。「private1」を上の「選択済みネットワーク」にドラッグアンドドロップする。そして、ようやく「起動」。

　 インスタンス「carmilla」が起動したら「Floating IPの割り当て」を行う。「IPアドレス」は「192.168.0.101」を選択して「割り当て」。これでようやく仮想マシンが利用可能な状態になったわけだ。ついでなので同様にインスタンス「chun-en」「yukikaze」を余計に起動しておく。

　 ここで、さっき作ったボリュームをyukikazeに装備してみる。「コンピュート」の「ボリューム」に並ぶ「volume1」の「接続の管理」を行う。「yukikaze」を選択して「ボリュームの接続」だ。

　 「ネットワーク」の「ネットワークトポロジ」を見るとなかなかおもしろい状況になっている。

　 さて、各インスタンスにログインしてみる。登録した公開鍵を持つ、普段の端末から「

　 ちょっと前に存在を知ったのだが「てのりちゅっちゅ」というおもちゃがある。

　 チュンチュンと鳴いて、首をクリクリと動かし、音に反応する。複数並べると合唱する、という仕様なのだが、首の動かし方が機敏で、思った以上にリアルな小鳥を感じるのだ。オマケに合唱の時は、個体同士が事前に「声(トーン)と耳(マイク)」でタイミングを取るという、ちょっとアレゲなテクノロジを有しているのもいい。

　 以前に出ていた「ポップンステップ」という、複数並べると同期してタップダンスを踊るというディズニー関係のおもちゃの発展形という気もするが、個人的には圧倒的に小鳥の方が好きだ。

　 というのも、子供の頃に白文鳥やインコを、そして実家で手乗りの白文鳥を飼っていたこともあり、単に鳥類が好きなのだ。なんであいつらは、空を飛べるというモノスゴイ能力を有しているのに加え、あんなに愛らしかったり、カッコよかったりするんだ。デザインとしても秀逸すぎるだろ。

　 で、私の中では小鳥と言えば白文鳥なのだが、てのりちゅっちゅには、白文鳥のラインナップがないのである。というか、南国系のケバケバしいのばかりだ。ちがうだろ。小鳥と言えば、白文鳥だろ。

　 というわけで、バラして塗ってみた。

　 実家のかーちゃんにプレゼントし「群れ」に加える予定だったので、製作を急いでおり、バラしたところの写真を撮る余裕がなかったが、3本のネジを外し、腹部装甲を外し、左右の翼を外し、2本のネジを外し、メカ部分を外し、クチバシへの配線をいったん切断、頭部の裏の2本のネジを外し、下クチバシと目玉を外すと、ほぼ完全にバラすことができる。

　 なるほど、機敏な首の動きは既製のモータでなく、コイル駆動だったわけか。うまく作ってあるなぁ。

　 再塗装で失敗したのは、スイッチのマーキングや、上のクチバシ、翼の模様が塗装だってことに気づかず、上塗りしてしまったってことだ。再塗装するなら、溶け出さないよう、これらをシンナーで事前に落としておく必要がある。それと下クチバシは、再塗装後に頭部にセットしようとすると、コスれて塗装がハガれるので、外側はセットしてから塗ったほうがいい。それと白文鳥なら、つや消しの白で塗るべきだったな。先に、白サフェーサも吹いておくべきだった。

　 メカ的にもS2機関は無理としても、アンビリカルケーブルで電源供給ができるようにしたかったところだ……なんだか、2号機を作りたくなってきてしまったなぁ。もうひとつ買っておくか……。