2015/12/11

VMware, GitHub, vca-cli

この投稿は vExpert Advent Calender の一環です。


● GitHub

正規に出荷されている製品以外にも、VMware はさまざまなソフトウェアを作って世に提供していたりします。その一つとして有名なのが flings で、AutoDeploy のGUI Nested ESXi 向けの VMware Tools などが公開されております。

一方、最近になって活発になってきたのが、今回紹介する GitHub での活動です。
VMware 社の GitHub アカウントにはすでに100近いプロジェクトが登録されており、日々活発にアップデートされております。新規のプロジェクトもあれば、open-vmtools のように、以前 SourceForge にて公開されていたものが引っ越してきたとか、何故か Docker のブランチを作っていたりとか、様々なものがあります。

SourceForgeの open-vm-tools のページには、
ただ「引っ越した」の記載だけが残っています

今話題?の Photon についても、GitHub に登録されているのでどういったものかとか、今どこら辺の開発が進んでるのかなどが確認できます。何でしたら、github から clone (checkou)して自分でも弄ってみて、改善点を pull request で上げてみる、なんてこともできてしまいます。


GitHub Photon のページより



今回はこの中から、vCloud Air のコマンドラインツールである vca-cli を紹介したいと思います。



● vca-cli : インストール

vCloud Air のコマンドラインツールとしては、PowerCLI が有名です。6.0 Release1 より限定的に vCloud Air がサポートされ、直近の PowerCLI 6.0R3 では vCloud Air On Demand もサポートされております。

PowerShell は現在この世に存在する中で最高のシェルでありスクリプティング環境(個人の意見です)ですが、世の中には光が届かず PowerShell の恩恵にあずかることができない暗闇、というのもまだまだ沢山あります。Mac とか。

そうした環境でも利用できるのが vca-cli です。vca-cli は Python で記述されたコマンドで、Python が動作するところならどこでも、非Windows 環境でも動作致します。

インストールは github clone で GitHub からコピーして...、ではなく、Python 標準の pip コマンドからインストールできます。GitHub にソースが公開されているだけではなく、Python のパッケージとしてPyPI にもちゃんと登録している次第です。

https://pypi.python.org/pypi/vca-cli/14

具体的な手順も GitHub の該当ページに記載されおてります。今回はまず試しに Ubuntu Linux 14.10 を使用しましたが、この場合は以下になります。

$ sudo apt-get update 
$ sudo apt-get install -y build-essential libffi-dev libssl-dev libxml2-dev libxslt-dev python-dev
$ wget https://bootstrap.pypa.io/get-pip.py
$ sudo python ./get-pip.py

$ sudo pip install vca-cli

$ sudo pip install pyopenssl ndg-httpsclient pyasn1$ sudo pip install six --upgrade
$ sudo pip install cloud-dsl-parser --upgrade

1行目でまず既存パッケージを最新にアップデート、2行目で必要となる外部パッケージをインストールします。

3行目は、pip を使うため初期処理を行うスクリプトをサイトからダウンロードしております。
4行目でそのスクリプトを実行、pip コマンドが使えるようにしております。
5行目にて、pip コマンドで vca-cli をインストールしています。

Ubuntuでの vca-cli のインストール


インストールの過程で依存するパッケージのインストールもまた行われます。
しばらく待つと上図のように Successfully installed と表示され、インストールには成功するのですが、なにやらSSLの警告もまた出ております。どうも、SSLのライブラリが証明書の正当性の検証をしていないことから来る警告のようです。

これの解決が6行目で、pyopenssl ndg-httpsclient pyasn1 という三つのパッケージを追加しております。

最後に、six と cloud-dsl-parser というパッケージのアップグレードをかけてます。apt-get update で Ubuntu 的なパッケージは最新にしているはずなのですが、この二つのPythonのパッケージのバージョンが古いため vca-cliの実行に失敗していたためです。


Python パッケージが古いと、コマンドの実行時こういう形で警告が出る
警告に従いそれぞれをアップデートしました。


● vca-cli : 使ってみる

さて、では vca-cli を使ってみます。vca-cli のコマンド名は「vca」です。何も引数をつけず実行すると、(全てのパッケージが正常ならば) 以下のようなヘルプが表示されます。
vca コマンド
vca コマンドにはいくつものサブコマンドがあり、サブコマンドに -h オプションをつけて実行するとサブコマンドごとのヘルプも確認できます。ここら辺の使い勝手は ESXCLI とほぼ同じです。
(なぜコマンド名を vcacli なかったのか不思議ですが)
login サブコマンドのヘルプ

上記のヘルプから分かるように、vca コマンドは vCloud API の 5.1および5.5~5.7 までをサポートします。

vCloud API 5.6 では vCHS Platform API を使って DC, VDC の操作が可能です。
vCloud API 5.7 では vCA Platform API が使えますので OnDemand と VDC が操作できます。

面白いのは vca コマンドが vCloud API 5.1/5.5 をサポートする、と言うことです。これは vCloud Director としか通信できない、WebConsole (ポータル)へアクセスする拡張がないバージョンです。
DC, VDC の vCloud Director を直接指定して使うという使い方や、プライベートクラウドで動作している vCloud Director へもアクセスできる、と言うことです。

さて、ログインしてみます。vCloud Air にログインする場合はユーザ名だけを指定します。

$ vca login <username>

パスワードを聞かれますので、正しく入力するとログインできます。なお、このときプロファイルにパスワードが保管されます。好まれない場合は --do-no-save-password オプションをつけて vca login を実行します。

アクセスできるインスタンスの一覧は vca instance ないし vca instance list コマンドで取得できます。
$vca instance
結果は以下の通りです。

ログイン後、VDCの一覧を確認
vCA Platform API で動作しているため、VPC, OnDemand, ObjectStorage が表示されます。

また、vca instance info コマンドで各インスタンスの概要を確認できます。
$vca instance info -i <Instance ID>
結果は以下の通りです。

vca instance コマンド実行結果
URLが長いため少々表示が崩れてますが、大まかな状況は確認できると思います。

実際にアクセスするインスタンスは vca instance use コマンドで指定します。
$vca instance use -i <Instance ID> -v <VDC Name>
以下が実行結果です。今回はインスタンスが Virtual Private Cloud On Demand のため、VDCが一つしかなく、指定を省いてます。Dedicate Cloud のように複数VDCが存在しうる場合は、明示的に指定しておくべきでしょう。

Instanceを指定
上図では OnDemand を選択した後に、vca vm list で仮想マシンのリストを得ております。

なお、ca login 時に -i <Instance ID>, -v <VDC Name> を指定、最初っから use しておくこともできます。二度目のログインなどでもう InstanceID が分かってる場合はその方が手っ取り早いでしょう。

自身が何を use しているのか、などは vca status で確認できます。

状態を確認
仮想マシンの作成、起動は vca vm ではなく、vca vapp を使用します。vCloud Director がベースのため、1vApp 1VM で簡略化されても、あくまで vApp という枠を使用することになります。

vca vapp には create, deploy, customize, power-on, power-off, insert, eject 等々、多彩なサブコマンドが用意されております。実際、操作はこの vca vapp をひたすら使うことになります。
$ vca vapp power-on -a <vApp名>
ここでは単純に、既存の仮想マシンを起動してみました。

vApp を確認、起動
vca-cli の使い勝手はこのような感じです。

●プロファイル

接続先ホストやログオンの状態、use したインスタンスなど vca-cli での現在の状態(context)はプロファイルと呼ばれており、 ~/.vcarc に格納されます。既定では Default というプロファイルが指定された状態になっています。

プロファイルについては vca profile サブコマンドで確認ができます。

現時点では、vca profile にはさらなるサブコマンドがありません。新しいプロファイルを作ったり、プロファイルを切り替える機能は未実装であるといえます。

表示についてだけは複数プロファイルに対応しており、.vcarc ファイルを編集することで複数プロファイルの作成、vca-cli が使用するプロファイルの選択ができます。

プロファイル一覧、vcarc を編集して無理矢理増やしている
プロファイルは [] からなる項目名で分けられ、各項目は「設定名 = 値」の繰り返しになります。
ちょうど WIndows の INI ファイルににてますね。

vcarc []のセクションごと一つのプロファイルになる
ここにパスワードの難読化がかかったものが格納されます。初戦は難読化、デコードできないわけじゃないので、このファイルには気をつけた方がいいでしょう。

● Windows だって vca したい!(失敗編)

さて、vca は Python のスクリプトの集まりで、Python 2系統の処理系があれば動作するはずです。ということで、Windows でも試してみました。

Python の公式サイト( http://python.org )では、ソースコード等に加えて Windows 版のインストーラも提供されております。
Python for Windows
Python 2.7.11 の方をダウンロード、インストールします。C:\Python27 にインストールされますので、このフォルダと、C:\Python27\Scripts を環境変数PATHに追加詩と絵来ます。

あとは Ubuntu での手順と同じで、https://bootstrap.pypa.io/get-pip.py をダウンロードし、実行、pip install vca を実行してみました。

ところが、依存のあるコンポーネントの一つがどうも Cでのソースコードがありビルドする必要があるようで、Visual C++ 9.0 がない、という理由で Fail してしまいました。




lxml でビルドが走り, Fail
さすがに VisualStudio はいれていなかったのでここで失敗となりました。Azure の管理をおこなう端末に VC++ が入っているという前提は厳しいので、普通の端末では vca の使用は厳しい、という結論となりました。

次回は、Visual Studio をインストールして試してみたいかと思います。



2015/11/09

vCloud Air の vCloud API

vCloud Air は VMware のクラウド管理ツールである vCloud Director を利用して構築されている。 vCloud Director は REST ベースの vCloud API を通じて操作や連携が可能になっている。
( むしろ、vCloud Director 標準の FLEX UI は REST API のサンプル実装で実際には REST での操作でUIを構築するべきものと vCloud Director リリース前には聞いていたのたが、そこまで頑張るクラウドベンダーも少なく、"サンプル"がそのまま使われ続けてサポートせざるを得なくなったというのが事実ではないかと思われる。 )

vCloud Air でも vCloud API で操作できるか? と言われるとこれが実は微妙なところだった。 vCloud API は vCloud Director を指し示すURLに対して送付することになっていたが、vCloud Air では各リージョンで多数の vCloud Director が動作しており、利用者の仮想データセンター(VDC)はそのどれかにマッピングされる。vCloud API でアクセスすべきURLが仮想データセンターに接続してみないと分からないのだ。


標準の Web Console は一カ所で稼働しており、これは各ユーザのVDCがどのリージョンのどの vCloud Director にマップされているかを把握している。しかし、この WebConsole はvCloud Director の範囲外で動作しており、システマチックにVDCのリストを得ることがこれまでできなかった。

複数のVDCを利用する場合、どのVDCがどのURLかは利用者が管理し続けることになり、これはとうていクラウドらしいAPIとはいえない。

この点は VMware 社も把握しており、vCloud API の拡張が続けられていた。

最初の改善は、vSphere 6.0 に付属の PowerCLI 6.0R1 に見られる。このバージョンでは vCloud API 5.6 を使用して、https://vchs.vmware.com/api/vchs/sessions へ接続、VDCのリストを得て、VDCへのセッションを張ることが可能となった。
PowerCLI ではこの接続を「Connect-PIServer」 というコマンドレットでサポートしている。このコマンドレットを含むモジュールが VMware.VimAutomation.PCloud (PICloud でないのに注意)なので、おそらくPublic の P なのだろう。

Connect-PIServer で接続後、Get-PIDataCenter コマンドレットを使うことで、ログインした権限で利用可能な全ての仮想データセンターがオブジェクトとして渡される。-Name オプションで名前を指定、あるいは取得したオブジェクトを Select-Object などを使って選択後、Connect-CIServer コマンドレットに渡せば vCloud Director への接続が得られる。

ただし、このバージョンの vCloud API は Dedicate Cloud (DR), Virtual Private Cloud (VPC),  Disaster Recovery (DR) といったサブスクリプション制のサービスにのみ対応し、従量課金制の Virtual Private Cloud On Demand や、Google のOEMである Object Storage には対応していなかった。


これら新しいサービスへの対応は、PowerCLI 6.0R2 とそれに対する fling のリリースによって行われた。fling 、すなわちまだプロダクションレベルのサポートではない、評価版という形だが、ここで vCloud API 5.7 with vCloud Air Extension をサポートし、これまでのAPIを vCHS Platform API 、5.7 でサポートされた vCloud Air の拡張を含む API を vCA Platform API と呼ぶようになった。
(vCHS は vCloud Hybrid Service の略で、vCloud Air の旧称)

vCA Platform API は VPC および DR、それから Virtual Private Cloud On Demand 、Object Storage をサポートするが、一方で DC をサポートしない。どちらのAPIがどれをサポートするかはこちらのドキュメントに記載がある。どちらのAPIセットを使うかは Connect-PIServer のオプションで決まる。「-vCA」オプションを追加すると新しい vCA Platform API で、そうでない場合は従来の vCHS Platform API となる。

Virtual Private Cloud On Demand の取得には Get-PIDataCenter ではなく Get-PIComputeInstance コマンドレットを使用する。帰ってきたオブジェクトを Connect-CIServer に渡す点は同じだ。



そして、PowerCLI 6.0 R3 にて fling 部分のコードも統合された。すなわち、 PowerCLI 6.0 R3 さえインストールすれば追加のインストールコンポーネントなしに vCA Platform API が利用できる。


2015/10/25

Windows 10 でキーボードレイアウトを変更する

Fusion 8 では Windows 10 を正式にサポートしており、光学ドライブやISOイメージからの簡易インストールも可能になっている。

簡易インストールは メディアを指定して仮想マシンを作成、ユーザ名、パスワード、プロダクトキーを入力しておけば、あとは自動的にインストールを行い、VMwareTools まで入れてくれるというものだ。インストールの時間はかかるが、細々とした入力のために画面を見ておく必要がない、ほったらかしで構わないというのは便利だ。

さて、簡易インストールした仮想マシンを試しに使ってみていたら、キーボードレイアウトが 106 になっていることに気がついた。ほとんどのユーザはその方が便利なのだが、私の Mac はいずれも英語配列のため、106 配列だと少々面倒なことになる。

これまでの Windows では、キー配列を変更する最も手っ取り早い方法はデバイスマネージャからキーボードの項目を展開、標準106キーボードになってるドライバの更新をかけ、手動で101キーボードを指定することだった。この方法自体は Windows10 でも可能だ。

しかし、もっと簡単な方法が用意されていたのでここに記録しておく。

まず、Windows 10 の「設定」アプリを開く。「設定」はスタートメニューから開いてもいいし、アクションセンターのボタンをタップしてもいい。



「設定」を開いたら「時刻と言語」を選択する。



「時刻と言語」を開いたら、左側のメニューから「地域と言語」を選択する。


ここで、「日本語」となっているアイコンのあたりをクリックする。するとボタンが現れる。出てきたボタンの中から「オプション」を選択する。



表示された言語のオプションの真ん中あたり、ハードウェア キーボード レイアウトの項目で「レイアウトを変更する」のボタンがあるのでこれを押す。



するとキーボードレイアウトを選択できるパネルが表示されるので、ここで「日本語キーボード(106/109キー)」から「英語キーボード(101/102キー)」に変更する。あるいは日本語キーボードにしたい場合はその逆を選択する。



ただ、サインアウトするとレイアウトが変わると表示されているが、私の仮想マシンではサインアウトしたあとサインインしただけではレイアウトは変わっておらず、仮想マシンの再起動が必要だった。

ともあれ、危険の伴うドライバの更新ではなく、もっと簡単で安全な設定手順が用意されたのは喜ばしいことだ。



2015/10/07

Fusion 8.0 での vCloud Air

9月は仕事が一杯一杯だったためすっかりご無沙汰してしまった。

さて、前回も話したように VMware Fusion 8.0 ではこれまでも接続できた ESXi や vCenterServer, VMware Workstation のサーバモードに加えて、vCloud Air へも接続できるようになった。

vCloud Air についてはこちらの一連の記事を読んでいただくとして、Fusion 8.0 での接続についてのみ見ていこう。

Fusion を起動し仮想マシンのライブラリをみると、左側の一覧に「VMWARE VCLOUD AIR」という項目ができているのに気がつく。これをクリックすると、ユーザ名とパスワードを入力する欄が表示される。

Fusion 8 の 仮想マシンのライブラリ画面
vCloud Air のユーザ名はアカウント登録時に用いたメールアドレスのため、これを入力、アカウント登録時、最初のログイン時に設定したパスワードを入力する。

認証に成功すると、左側に契約している仮想データセンター(VDC)が表示される。共有型クラウド(Virtual Private Cloud)ならば一つ、占有型クラウド(Dedicated Cloud) なら作成したVDCの数だけ表示される。また、日本以外のリージョンの契約している場合は、権限のあるリージョンのVDCもあわせて表示される。

vCloud Air に接続。VDCと仮想マシンの一覧が追加される

vCloud Air on Demand の場合、アカウント作成時に作成したVDCが表示される。通常は一つだが、複数のリージョンで作成していれば複数になる。

VDCを選択すると、そのVDCに配置されている仮想マシンが表示される。仮想マシンを選択すると、ローカルの仮想マシンと同じく画面のサムネイルが表示される。

ここから、仮想マシンを起動/終了、リセット、サスペンドさせることができる。

vCloud Air の仮想マシンを選択している場合
メニューの1行目は「仮想マシン」としか表示されず、
サスペンド、リセット、パワーオンかパワーオフを選択

ローカルの仮想マシンを選択している場合
Linux/Windows/MacOSなどOS種類が表示される
再起動、シャットダウンと安全な手法を選択

VMware Tools を入れていても、シャットダウンや(安全な)再起動は選択肢に出てこないので注意だ。

別ウィンドウでコンソール画面を開くことができる。

仮想マシンのコンソール画面、割ときびきびしている
ブラウザでは無く専用のアプリケーションだけあって、動作は割ときびきびしている。それでもローカル仮想マシンに比べれば反応は鈍いが、遠隔地にあってネットワークの遅延があるのでこれは致し方ないだろう。
(vCloud AirのWebUIの仮想コンソール、あるいは FLEXの vCloud Director 画面の仮想コンソールはどちらもあまり応答速度が良くない。)

ローカルの仮想マシンを VDCのアイコンにドロップすると仮想マシンをアップロードすることができる。
仮想マシンのアップロード画面

これは内部的には OVFでの出力と、ovftool を使った転送をおこなっていると見受けられる。なお、逆に vCloud Air の仮想マシンのアイコンをローカルの仮想マシンのフォルダにドロップしてもダウンロードは発生しない。どうしてもと言う場合は、アプリの中に格納され居てる ovftool を使うことになるだろう。

仮想マシンの起動、終了、リセット、スナップショット(vCloud Airでは1段のみ)、仮想コンソールの利用、そしてアップロードでできることは一通りのようだ。

一見仮想マシンの構成変更ができるようにも見えるが、現時点ではディム表示で選択ができない。今後のアップデートに期待、と言うことだろう。

仮想マシンの設定。一般は名前などを表示するのみ、後の設定は選択できない

また仮想ネットワークの構成変更などの基盤環境の構成や、vCloud Air 側テンプレートからの新規仮想マシンの作成はできない。Mac側の仮想ネットワーク(NAT)と vCloud Air 側 EdgeGateway とでVPN接続ができたら面白いのだが、そこも用意されていない。
(IPsec/L2TPのため、Mac のVPNクライアント機能で接続できるかも知れないが、未検証)

あくまで、Macでの仮想マシンの実行の補助的なもので、vCloud Air との連携を主力にしてというものではなさそうだ。

vCloud Air の WebUI は、HTML5としては割と良くできてるがしかし仮想マシンの管理には少々不便なところがある。せっかくのローカルアプリケーションなのでこちらに管理能力をもたせれば使い勝手はあがるのだが、どうもそこまでやるつもりはないようだ。

ただ、割り切って使えばこれはこれで面白い。MacBook Air や今度の MacBook のように、仮想マシンを多数動かすことが性能やコンセプト的に厳しい Mac で、リモートの仮想マシンをローカルの仮想マシンと同じように扱えるのは何かと便利だろう。

2015/08/26

Fusion 8.0

2015年のベータプログラムも始まってるし進んでるなと思ってたら、唐突に Fusion 8.0 がリリースされた。

リリースノートからわかる内容は以下の通り。

  • Windows 10 のフルサポート
    • Windows10をゲストOSとする仮想マシンを実行可能(Fusion 7に引き続き)
    • Windows10のメディア認識と簡易インストール
    • Unity が利用可能
    • Windows10の実機から仮想マシンへの移行
    • Windows10の BootCamp領域からの仮想マシンのインポート
  • OS X El Capitan のサポート
    • El Capitan を仮想マシン上で実行可能
    • El Capitan をホストOSとする Mac での Fusion 8 の利用が可能
  • その他、新しいゲストOSのサポート
    • Ubuntu 15.04, Fedora 22, CentOS 7.1, RHEL7.1, Oracle Linux 7.1
    • Project Photon
  • グラフィックサポートの強化
    • DirectX 10, OpenGL3.3 を利用可能
  • 暗号化された仮想マシンでのサスペンド、レジュームの高速化
  • Retina ディスプレイの解像度サポートの強化
  • 最新の Mac のサポート
    • 5k iMac でのフルスクリーンなど
  • Skype および Skype for Business(旧Lync)でのエコーキャンセラレーション
  • Windows 7 をゲストOSとする仮想マシンでのUSB3.0サポート
    • 最新のIntelUSBドライバを利用すること
  • UIの改善
    • スタートメニューの改善と新しい仮想マシン作成画面
Pro 版ではさらに以下機能が追加されている

  • vCloud Air との統合
    • vCloud Air サービスへの接続
    • 仮想マシンのインベントリの確認
    • 仮想マシンのコンソール画面へのリモート接続
    • Mac上のFusionでの仮想マシンを vCloud Air へアップロード
    • vCloud Air 上の仮想マシンの電源オン/オフ
  • リモート環境のサポート強化
    • vSphere (vCenterServer管理下ないしは ESXi直接)での仮想マシンの作成
    • VMware Workstation へのリモート接続と仮想マシンの作成
    • 1つのDashboard 画面で複数の ESXi ホストの状況を確認
  • IPv6 NAT


これまで vCloud Air は月額定額制しかなく、それなりの企業でないと導入は難しかったが、つい最近、On Demand サービス、つまりは仮想マシンの稼働分だけの従量課金制が日本国内でもサポートされた。

90日間、一定金額までのサービスクレジットがあるので、Fusion 8 Pro とあわせて試してみるのもいいかもしれない。


2015/08/04

【余談】Karabiner でのカスタムセッティング

Karabiner のおかげで Office アプリでも Emacs Keybinding が使えるようになった。

しかし、Karabiner を入れると、Office アプリ以外でもキーバインドノリマップが発生してしまい、Karabiner があるときとないときで挙動が変わってしまう。

例えば、OmniGraffle でテキストフィールドを選択、テキストを範囲選択した状態で「Ctrl-A」を押したときの挙動が、Karabiner なしだとそのテキストフィールド内での先頭位置になるが、Karabiner を有効にしていると別の(一つ前の)テキストフィールドに移動してしまう。

私がやりたいのは MS-Office (PowerPoint, Excel, Word, Outlook, OneNote) のみで Emacs Keybinding を効かせたいだけなので、他のアプリには影響を及ぼしたくない。

ざっと XML の仕様を読んだが、replacement(要は定数定義)を上書きして、挙動させないアプリを増やすことは簡単にできそうだ。だが、私のやりたい「特定のアプリだけに設定を効かせたい」の場合、定数の書き換えだけではうまくいかない、ちょっとまじめに項目(item)を増やすしかなさそうだ。

少し早く起きてしまったし、ちょっと試してみた。
---
<?xml version="1.0"?>
<root>
  <replacementdef>
    <replacementname>XML_INC</replacementname>
    <replacementvalue>/Applications/Karabiner.app/Contents/Resources/include/checkbox</replacementvalue>
  </replacementdef>

  <appdef>
    <appname>ONENOTE</appname>
    <equal>com.microsoft.onenote.mac</equal>
  </appdef> 
  <item> 
    <name>Private Settings</name>
    <item>
        <name>Emacs Keybinding for MS Office</name>
        <identifier>private.emacs_mode_for_msoffice</identifier>
        <only> EXCEL, POWERPOINT, WORD, EXCEL, ONENOTE </only>
        <include path="{{XML_INC }}/snippets/emacsmode_controlPNBF_ex.xml" />
    </item>
  </item>
</root>
---

root タグでくくられた範囲が設定として使用される。カスタムXMLはどうもデフォルトのXML群より先に読まれるっぽいので、ここで設定したエントリがGUIでは一番上にくるようだ。

replacement は要するに定数定義。後で出てくるが、今回 アプリの中に用意されている XMLの定義を流用したかったので、そこまでのパスを「XML_INC」という定数にしてしまった。
これぐらい組み込みの定義でありそうな気もするのだが、探すの面倒だった次第だ。

appdef はアプリケーションの名称を設定している。Mac のアプリケーションは CFBundleIdentifier と呼ばれるそのアプリ独自の名称を持っているが、CFBundleIdentifier は逆DNS記法で長ったらしいので分かりやすい名前をつけている次第だ。

様々なアプリケーションがKarabiner 内の appdef.xml であらかじめ定義されており、たとえば MS-Office の場合、EXCEL, WORD, POWERPINT, OUTLOOK などはすでに定義済みだ。
しかし、今回から増えた OneNote については定義がなかったので、ここで com.microsoft.onenote.mac という CFBundleIdentifier を持つアプリを ONENOTE と定義している。なお、CFBundleIdentifier については、そのアプリ内の Info.plist に記載されているが、Karabiner 付属の EventViewer でも確認ができる。


さて、item タグからが本来の設定だ。

item タグはGUI城で現れる各設定項目を示す。入れ子にすることも可能で、入れ子にすると親の name でのグループが作成される。Karabiner 標準では「General」などのグループがあるが、これは item タグの入れ子でできている。

別にグループを作る必要性はないが、ただ見た目的に、チェックボックスがいきなり現れているのはちょっとかっこわるかったので Private Settings というグループを作成した。

その中の item タグの Emacs Keybinding for MS Office が今回やりたかった設定項目だ。identifier はこの項目固有の名称、name は表示される項目名になる。
appendix タグでテキストを書いておくと説明書きを追加できるらしいが、今回は省いた。

only タグはその設定を有効にするアプリ名を記載する。このなかでは , を使うことで複数のアプリを指定できる。MS-Office に所属する主立ったアプリをここで指定している訳だ。

autogen タグによってどういったキーをリマップしていくかを記載するが、EmacsKeybinding の、特にカーソル移動の部分だけ場合、アプリの中にそれだけの定義を抜き出した XMLが存在する。

ここでは、include タグでその XMLを読み込むことで個別の定義を回避している。

なお、ここで先ほどの XML_INC の定数を参照している。(別にフルパスを書いてもいいのだが...。)
相対パスにした場合はどうもそのXMLファイルの位置からの相対になるようだ(未確認)。

この定義を private.xml に作成、保存した後にリロードすることで、設定が現れる。


後はチェックを入れるだけだ。軽く試した限りは、これでちゃんと動作しているようだ。



個人的に気になったのは、item にて挙動の定義と画面に表示されるデータが混在されていることにある。

ActiveDirectory のGPOの管理テンプレートでもあった失敗だが、挙動と表示を混ぜた定義を作ってしまうと I18Nのとき、名称や説明を現地の言葉にする場合にハマってしまう。

GPOの管理テンプレートの場合、それ以外の問題(例えば構文が独自だったのをXMLに更新したかったなど)もあり、動作を定義した ADMX ファイルと、言語ごとの表示内容を抜き出した ADML ファイルに分ける羽目になった。

管理テンプレートの例を出さずとも、OS X の Cocoa アプリのローカライズも、.lproj というフォルダを作成し、nib/xib といった表示されるオブジェクトの定義や strings といったメッセージを各言語ごと別に作る事でなされている。


Karabiner の場合も、item には identifier があるので、言語ごとのメッセージファイルを作成、identifier でローカライズされたメッセージと item を紐付ければいい、用に見えるが、ここで先の「item は入れ子にできる」が引っかかってくる。

そう、グループを作る親の item はname タグしかもっておらず、個別の identifier を持たない。つまり、各設定項目ごとは identifier で紐付けして別のファイルからメッセージを持ってこれるが、「General」などのグループ名に対するローカライズされたメッセージを紐付ける手段がない。


まあ、private.xml の説明が英語でしかなかったり、そもそもアプリの GUI も英語UIしかないので、そうした表示面でのローカライズについてはこれを行わない、というのがおそらく作者のポリシーなのだろう。Karabiner のアプリの立ち位置を考えると、別にそれは悪いことでもない。

2015/08/03

【余談】Karabiner でのキーリピート速度

これまで、ちょっとしたテキストやメモの共有には、OS X/iOS標準の「メモ」(Notes)を使っていた。

「メモ」(Notes)はバックエンドがIMAPなどメールサーバになっており、Gmail なりの適当なメールサーバさえ確保できれば簡単にドキュメントが同期できることと、Apple 系のデバイス間だけではなく、限定的にだが ExchangeServer を経由して Windows とも連携が可能なのが便利だったためだ。

そもそも、何故 IMAPをメモに...っていうのも理由があり、ExchangeServer がメールや予定等々を統一的なアクセス方法で扱えるようにしており、その中に「メモ」があったのが理由と思われる。( 古い Macユーザなら、Exchange サポートの入った前後の Mail.app に「メモ」がひっついてたのを覚えているだろうか? 要するにそういうことだ )

ところが、ExchangeServer 側がメモのサポートをやめようとしている。一応機能としては残っているが obsolete 扱いで、現在の Exchange 2013 + Outlook 2013 では、表示フォントの変更ができないなど以前にあった機能が欠落を始めている。


そんなこともあり、ちょっとしたテキストやメモの共有に OneNote を使い始めた。OneNote はフリーで使え、iOS でもアプリがある。仕事でも OneNote を使い始めたこともあって、移行先としては悪くないと思った次第だ。

多少の癖はあるが Mac 版の OneNote もそこそこできがいい。(IMAPやExchangeではなく) OneDrive を通じて同期し、人との共有も可能。賛否は分かれるがページ以外にもタブという概念があり、一次元ではなく二次元にメモを整理できる。また、オンラインアクセスできるのも悪くない。(iPhone でアクセスするときわめて使いにくく、PC/タブレット用と割り切る必要はあるが。)


さて、便利に使い始めた OneNote だが、Emacsキーバインドが使えないのだけが厄介であった。指がそっちに慣れているため、つい Ctrl-P を押してしまう、Ctrl-F, Ctrl-B でカーソルを動かそうとしてしまう、のでどうしてもストレスがたまる訳だ。

同じ事が Excel や PowerPoint でも起こっており、そろそろ年貢の納め時か、とあきらめ Karabiner を導入した。以前は KeyRemap4MacBook と呼ばれていたアプリで、 KEXT (カーネル拡張)を突っ込んでキーボードからの入力をいじってしまうというもの。トラブったときがやっかいなのでこの手合いのデバイスドライバはなるたけ避けていたのだが、背に腹はかえられぬ。実際、導入したら便利であった。

ただ、Karabiner を導入するとキーリピート速度の速度がなにやら遅い。見ると Karabina がリピートまでの認識時間とリピート速度を上書きしている、とある。

直したいのだが Karabiner ではミリ秒単位で値を設定するもので、さて Mac側の設定でどれが何ミリ秒になっているかわからないと設定しようがない。

仕方がないので、少し調べた。
Mac 側の設定は「defaults read -g | grep Repeat」あたりで検出できる。InitialKeyRepeat の値が「リピート認識までの時間」、KeyRepeat の値が「キーのリピート」での値だ。

しかし、この値はミリ秒ではない。出てきた値に 15をかけるとミリ秒になる。

図示すると、こんな感じだ。



値としては、以下の通りだ。

キーのリピート 遅い           早い
1800
1350
900
450
180
90
30

リピート入力認識までの時間 長い         短い
1800 
1470
1020
525
375
225

この値をかき込めば、Mac のときと同じになる。

ただ、微妙に妙な動作がでてしまう。例えば OmniGraffle でテキストフィールドで範囲選択中に Ctrl-A を押したときの挙動が、Karabiner の有無で異なる。

Notifier を使って Office アプリだけを有効にしたいのだが...、これは、XMLでの設定を書くことでできそうなのでまた試すとする。

--
8/4 タイトルのスペル間違えてたので修正。