Script to modify the data files of Munin

この記事は先日の記事の英語版です。リクエストが有ったので翻訳してみました。

When you update the node name in the munin.conf, you must modify the data files names. If you installed the package, the default directory structure is the following.

Data directory /var/lib/munin
HTML files /var/www/html/munin

The data files of monitoring nodes exist in the following locations.

  • /var/lib/munin/state--.storable
  • /var/lib/munin//-.rrd
  • /var/www/html/munin///

Also It's a good idea that you delete the graph data following directory:

  • /var/lib/munin/munin-cgi-graph///

If the host name or group name has been updated, you must modify their data files in accordance with naming rules.

The bulk update with the script

The bulk update script is following:

This script allows you to:

  • When you change the node name in the munin.conf, update its data files.
  • When you delete the node name from the munin.conf, delete its data files.

How to use is the following:

  1. Adding execute permission
  2. Setting datadir, htmldir and cgitmpdir
  3. Update the ''munin.conf''
  4. Run this script

It is run interactively.

Environment is assumed the following.

  • CentOS6(RHEL6) 64bit / Ubuntu
  • Munin2.0
Examples
[hoge.example.com]
    address hoge.example.com
    use_node_name yes

to

[hoge.example.jp]
    address hoge.example.jp
    use_node_name yes

$ sudo /opt/sbin/munin-modify-data.sh
Please select the action
1) rename
2) delete
3) exit
Enter menu number> 1
Please enter OLD GROUP name > example.com
Please enter OLD NODE name > hoge.example.com
Please enter NEW GROUP name [example.com] > example.jp
Please enter NEW NODE name [hoge.example.com] > hoge.example.jp

OLD Group: example.com
OLD Node : hoge.example.com
New Group: example.jp
New Node : hoge.example.jp

OK? [y/n]: y
Waiting for the munin-update and munin-html processes to finish.

move state files:
        /var/lib/munin/state-example.com-hoge.example.com.storable >>> /var/lib/munin/state-example.jp-hoge.example.jp.storable
rename data files:
        rename example.com/hoge.example.com example.jp/hoge.example.jp /var/lib/munin/example.com/hoge.example.com-*
move html files:
        /var/www/html/munin/example.com/hoge.example.com/ >>> /var/www/html/munin/example.jp/hoge.example.jp/
delete graph directory:
        /var/lib/munin/cgi-tmp/munin-cgi-graph/example.com/hoge.example.com/

delete the empty directory '/var/lib/munin/example.com'
delete the empty directory '/var/www/html/munin/example.com'
delete the empty directory '/var/lib/munin/cgi-tmp/munin-cgi-graph/example.com'
  • Changing the node name('Group:hoge Host:hoge-ap' to 'Group:hoge Host:foo-ap')
[hoge;hoge-ap]
    address hoge-ap.internal
    use_node_name yes

to

[hoge;foo-ap]
    address foo-ap.internal
    use_node_name yes

$ sudo munin-modify-data.sh
Please select the action
1) rename
2) delete
3) exit
Enter menu number> 1
Please enter OLD GROUP name > hoge
Please enter OLD NODE name > hoge-ap
Please enter NEW GROUP name [hoge] >
Please enter NEW NODE name [hoge-ap] > foo-ap

OLD Group: hoge
OLD Node : hoge-ap
New Group: hoge
New Node : foo-ap

OK? [y/n]: y
Waiting for the munin-update and munin-html processes to finish.
.......
move state files:
        /var/lib/munin/state-hoge-hoge-ap.storable >>> /var/lib/munin/state-hoge-foo-ap.storable
rename data files:
        rename hoge/hoge-ap hoge/foo-ap /var/lib/munin/hoge/hoge-ap-*
move html files:
        /var/www/html/munin/hoge/hoge-ap/ >>> /var/www/html/munin/hoge/foo-ap/
delete graph directory:
        /var/lib/munin/cgi-tmp/munin-cgi-graph/hoge/hoge-ap/

delete the empty directory '/var/lib/munin/cgi-tmp/munin-cgi-graph/hoge'
  • Deleting data files.
$ sudo munin-modify-data.sh
Please select the action
1) rename
2) delete
3) exit
Enter menu number> 2
Please enter DELETE GROUP name > hoge
Please enter DELETE NODE name > foo-ap

DELETE Group: hoge
DELETE Node : foo-ap

OK? [y/n]: y
Waiting for the munin-update and munin-html processes to finish.
...
delete state files:
        /var/lib/munin/state-hoge-foo-ap.storable
delete data files:
        /var/lib/munin/hoge/foo-ap-*
delete html files:
        /var/www/html/munin/hoge/foo-ap/
delete graph directory:
        /var/lib/munin/cgi-tmp/munin-cgi-graph/hoge/foo-ap/

delete the empty directory '/var/lib/munin/hoge'
delete the empty directory '/var/www/html/munin/hoge'
delete the empty directory '/var/lib/munin/cgi-tmp/munin-cgi-graph/hoge'

The flow is following:

  • If the munin-update or munin-html processes are running, waiting for its to finish.(It may be better to disable the cron.)
  • If you no longer have node in the original group by moving the node, it will also delete the directory of the group.
  • If you no longer have node in the original group by deleting the node, it also delete the directory group.

Please be careful with the steps, so do not look until consistency of strict data. If you can tolerate loss of temporary data during data migration:

  1. Disable cron
  2. modify setting in the munin.conf
  3. Run this script
  4. Enable cron

Additionally

I was thinking also that it's run by passing information in the argument of the command, but the interactive execution is easy to use for me. It may be good to be usable by batch processing.

Muninの監視ノード名を変更した時にデータを引き継ぐ更新スクリプトを作ってみた

Muninで監視ノードのグループ名やノード名を変更した場合、データファイルがノード名に紐付いているので設定ファイルを変更しただけでは蓄積したデータを引き継ぐ事ができません。ノード名の変更にあわせてデータファイルを適切に更新する必要があります。Muninをepelなどからパッケージでインストールした場合、デフォルトのディレクトリ構成は

データディレクト /var/lib/munin
HTMLファイル /var/www/html/munin

になっています。この場合監視ノードのデータファイルは以下の場所に存在します。

  • /var/lib/munin/<グループ名>/<ホスト名>-<監視項目>.rrd
  • /var/lib/munin/state-<グループ名>-<ホスト名>.storable
  • /var/www/html/munin/<グループ名>/<ホスト名>/

また以下のデータはグラフ閲覧時に作成されるので(graph_strategy が cgi の場合)、ノード名変更時に削除しておいた方がよいです。

  • /var/lib/munin/munin-cgi-graph/<グループ名>/<ホスト名>/

グループ名やホスト名が更新された場合、これらをルールに則って更新しなければなりません。

スクリプトで一括更新

ノード名の変更ってそんなにするものではないとも思いますが、無いわけでもなく今までは rename(1) コマンドとかで手作業でやっていました。ただ今回複数のノードを整理する必要が出てきてめんどくさかったので、今後の事も考えて更新するスクリプトを書いてみました。以下で公開しています。

できることは以下です。

  • ノード名変更時に引き継ぐデータの移行処理
  • 監視ノード削除時に対象のデータを削除

実行の手順としては

  1. ファイルに実行権付与
  2. スクリプト内の datadirhtmldircgitmpdir を環境に合わせて設定
  3. munin.conf でノードの設定更新
  4. 実行権限つけて引数なしで実行

です。インタラクティブに実行できるようにしてあるのであとは実行すればわかると思います。

環境は

  • CentOS6(RHEL6) 64bit / Ubuntu
  • Munin2.0系

を想定しています。rename(1) コマンドをスクリプト内で使っていますが、Ubuntu だとコマンドの実装が違うとかいう話を聞いたのでそちらの動作確認はしていません。Ubuntu の簡易チェックを入れて対応しました。

使用例
  • ノード名を変更(example.com を example.jp に変更)
[hoge.example.com]
    address hoge.example.com
    use_node_name yes

[hoge.example.jp]
    address hoge.example.jp
    use_node_name yes

に変更した場合、以下を実行します。

$ sudo /opt/sbin/munin-modify-data.sh
Please select the action
1) rename
2) delete
3) exit
Enter menu number> 1
Please enter OLD GROUP name > example.com
Please enter OLD NODE name > hoge.example.com
Please enter NEW GROUP name [example.com] > example.jp
Please enter NEW NODE name [hoge.example.com] > hoge.example.jp

OLD Group: example.com
OLD Node : hoge.example.com
New Group: example.jp
New Node : hoge.example.jp

OK? [y/n]: y
Waiting for the munin-update and munin-html processes to finish.

move state files:
        /var/lib/munin/state-example.com-hoge.example.com.storable >>> /var/lib/munin/state-example.jp-hoge.example.jp.storable
rename data files:
        rename example.com/hoge.example.com example.jp/hoge.example.jp /var/lib/munin/example.com/hoge.example.com-*
move html files:
        /var/www/html/munin/example.com/hoge.example.com/ >>> /var/www/html/munin/example.jp/hoge.example.jp/
delete graph directory:
        /var/lib/munin/cgi-tmp/munin-cgi-graph/example.com/hoge.example.com/

delete the empty directory '/var/lib/munin/example.com'
delete the empty directory '/var/www/html/munin/example.com'
delete the empty directory '/var/lib/munin/cgi-tmp/munin-cgi-graph/example.com'
  • ノード名を変更(hoge グループの hoge-ap を hoge グループの foo-ap に変更)
[hoge;hoge-ap]
    address hoge-ap.internal
    use_node_name yes

[hoge;foo-ap]
    address foo-ap.internal
    use_node_name yes

に変更した場合、以下を実行します。

$ sudo munin-modify-data.sh
Please select the action
1) rename
2) delete
3) exit
Enter menu number> 1
Please enter OLD GROUP name > hoge
Please enter OLD NODE name > hoge-ap
Please enter NEW GROUP name [hoge] >
Please enter NEW NODE name [hoge-ap] > foo-ap

OLD Group: hoge
OLD Node : hoge-ap
New Group: hoge
New Node : foo-ap

OK? [y/n]: y
Waiting for the munin-update and munin-html processes to finish.
.......
move state files:
        /var/lib/munin/state-hoge-hoge-ap.storable >>> /var/lib/munin/state-hoge-foo-ap.storable
rename data files:
        rename hoge/hoge-ap hoge/foo-ap /var/lib/munin/hoge/hoge-ap-*
move html files:
        /var/www/html/munin/hoge/hoge-ap/ >>> /var/www/html/munin/hoge/foo-ap/
delete graph directory:
        /var/lib/munin/cgi-tmp/munin-cgi-graph/hoge/hoge-ap/

delete the empty directory '/var/lib/munin/cgi-tmp/munin-cgi-graph/hoge'
  • ノードデータを削除
$ sudo munin-modify-data.sh
Please select the action
1) rename
2) delete
3) exit
Enter menu number> 2
Please enter DELETE GROUP name > hoge
Please enter DELETE NODE name > foo-ap

DELETE Group: hoge
DELETE Node : foo-ap

OK? [y/n]: y
Waiting for the munin-update and munin-html processes to finish.
...
delete state files:
        /var/lib/munin/state-hoge-foo-ap.storable
delete data files:
        /var/lib/munin/hoge/foo-ap-*
delete html files:
        /var/www/html/munin/hoge/foo-ap/
delete graph directory:
        /var/lib/munin/cgi-tmp/munin-cgi-graph/hoge/foo-ap/

delete the empty directory '/var/lib/munin/hoge'
delete the empty directory '/var/www/html/munin/hoge'
delete the empty directory '/var/lib/munin/cgi-tmp/munin-cgi-graph/hoge'

設定で graph_strategy の設定は cgi が前提です。(cronはほぼ使わないですよね?)

処理的には以下の感じです。

  • cronで munin-update と munin-html が動いている場合はプロセスが終了するまで処理が待機します。めんどくさい場合は cron の実行処理を一時的に止めておいたほうがいいかもしれません。
  • ノードの移動で元のグループにノードがいなくなった場合、グループのディレクトリも削除します。
  • 同じくノードの削除の場合もグループにノードがいなくなった場合、グループのディレクトリも削除します。

データのアップデートのプロセスが動いていないタイミングを見て実行するようにしていますが、厳密なデータの整合性までは見ていないので手順には気をつけてください。例えば munin.conf のノード名を変更する前にデータの移動を先にした場合、古いノードのデータが残骸として残るかもしれません。
データ移行中の一時的なデータの欠損が許容できるなら、

  1. cron でのデータ収集を一時的に停止
  2. munin.confの設定を変更
  3. スクリプトの実行
  4. cron でのデータ収集再開

とするのが無難でしょうか。

まとめ

コマンドの引数で情報渡して実行するのも考えたんですが、インタラクティブな方が個人的に使いやすかったのでこの形にしました。*1
何か気づいた点やおかしな点があれば教えてください。

*1:AWS などのクラウド環境でサーバの自動登録と削除とかでデータの削除とかもするならバッチ処理的な動作もあった方がいいかもとは思いますが。

ELBのEC2インスタンスの登録/解除のrcスクリプトを作ってみた

EC2でELBに登録していてインスタンスを停止して再度起動した場合、ELBは対象のインスタンスを 「Out of Service」にしたまま自動では復帰しません。チェック自体が行われないので、いくら待っても自動での復帰はされません。
これを解消するには停止時にELBから登録を削除して起動時に再度登録すればよいわけで、自動化するスクリプトはググればいくつか見つかると思います。

rcスクリプトで管理

停止時と起動時に特定の処理を実行させると言えばrcスクリプトを思いつくわけですが、探してもそっちのサンプルはさくっとは見つからなかったのでPythonのお勉強がてらserviceコマンドで実行できる形で作成してみました。
RHEL6(CentOS6)用にRPMにして以下で公開してます。

64bit用しか用意してないですが、32bit版が必要な場合はソースもsrc.rpmも用意してあるので自前でビルドすれば良いと思います。サービス名やパッケージ名を変えたい場合もspecファイルいじれば問題無いと思います。

使い方もREADMEに書いてある通りで、PythonのBotoモジュールが必要です。
インストールすれば自動でサービスに登録されるので、あとは /etc/sysconfig/aws-elb-reg に適切にIAMで権限設定したアカウント情報を記述すればOKです。登録ELBを判定するタグ名もこのファイルで設定できます(デフォルトは elb)。

簡単な使い方

まずはパッケージをインストールです。

# rpm -ivh aws-elb-reg-<version>.rpm

あとは以下の手順で。

  1. 入っていなければBotoモジュールをインストール。pipでもyumでepleからインストールでも。
  2. ELBの操作が可能なIAMユーザー情報を /etc/sysconfig/aws-elb-reg に記述。
  3. 対象のインスタンスにタグ(デフォルトはelb)を追加して、値としてELB名を設定します。ELBは ','(カンマ)区切りで複数指定可能です(例:elb-hoge,test-ap,foo)。
  4. serviceコマンドを実行します。
  • ELBへ追加
# service aws-elb-reg <start|add>
  • ELBから削除
# service aws-elb-reg <stop|delete>
  • ELBへの登録状況確認(タグの値ではなく実際に登録されているELBを検出)
# service aws-elb-reg status

サービスに登録されているのでサーバの起動と停止時に自動でstartとstopが実行されます。

おわり

RPMにしたのでdebian系だとそのまま使えないですが、スクリプトを修正すれば同じようにできると思います。自分の環境では必要ないのでそっちまで作ってないですが将来必要になれば作るかもしれません。

ファイルひとつで設置できるサンプルも転がっているのでわざわざめんどくさいかもしれないですが、Auto Scaling で使うのに簡単かなと思って作ってみました(実際にはまだ Auto Scaling では使ってないので何か問題あるかも)。
自社の環境で使って今のところ問題なく動いてます。何か気づいた点などあれば教えてください。

Amazon EC2のAmazon Linuxでmoshをyumでインストール

Macでtmux使ってるとmosh使った時に出力が崩れる時があるから普段はあんまり使わないんですが、一応管理してる全サーバに入れてるので入れておこうと思ってお試し。サーバ側でtmux使って作業するときぐらいしかmoshで接続しないんですが。
ググってもあんまり情報がなかったのでメモとして残しておこうと久々の更新。

そのままではインストールできない

普通にAWSAmazon Linux(AMI release 2013.03)でmoshを入れようと思って

# yum insall --enablerepo=epel mosh

とかやると

600 packages excluded due to repository priority protections
Setting up Install Process
Resolving Dependencies
--> Running transaction check
---> Package mosh.x86_64 0:1.2.4-1.el6 will be installed
--> Processing Dependency: libprotobuf.so.6()(64bit) for package: mosh-1.2.4-1.el6.x86_64
--> Finished Dependency Resolution
Error: Package: mosh-1.2.4-1.el6.x86_64 (epel)
           Requires: libprotobuf.so.6()(64bit)
 You could try using --skip-broken to work around the problem
 You could try running: rpm -Va --nofiles --nodigest

とか言われてそのままじゃインストールできない。
amzn-mainのリポジトリにあるprotobufパッケージが新しいのが原因でlibprotobuf.so.8がインストールされている。

# rpm -qa protobuf
protobuf-2.5.0-1.8.amzn1.x86_64

CentOS6の場合はepel経由でmoshをインストールすると、2.3.0が入るので問題ないんですが。
確認するとこんな感じ。

# yum list --enablerepo=epel --disablerepo=amzn-main protobuf
Loaded plugins: priorities, security, update-motd, upgrade-helper
amzn-updates                                                                                    | 2.3 kB     00:00
182 packages excluded due to repository priority protections
Installed Packages
protobuf.x86_64                                       2.5.0-1.8.amzn1                                        @amzn-main
Available Packages
protobuf.i686                                         2.3.0-7.el6                                            epel

どうするか

yumでもバージョン指定のインストールはできるけど、先に新しいバージョン(2.5.0)が入っているので無理なわけです。yumにはrpmのforceコマンド的なものがないからとりあえずパッケージを落としてrpmコマンドでインストールすることに。

# yumdownloader --enablerepo=epel --disablerepo=amzn-main protobuf-2.3.0-7.el6.x86_64

パッケージの中身を確認する。
2.3.0は以下。

# rpm -qpl protobuf-2.3.0-7.el6.x86_64.rpm
/usr/lib64/libprotobuf.so.6
/usr/lib64/libprotobuf.so.6.0.0
/usr/share/doc/protobuf-2.3.0
/usr/share/doc/protobuf-2.3.0/CHANGES.txt
/usr/share/doc/protobuf-2.3.0/CONTRIBUTORS.txt
/usr/share/doc/protobuf-2.3.0/COPYING.txt
/usr/share/doc/protobuf-2.3.0/README.txt

デフォルトでインストールされている2.5.0は以下。

# rpm -ql protobuf
/usr/lib64/libprotobuf.so.8
/usr/lib64/libprotobuf.so.8.0.0
/usr/share/doc/protobuf-2.5.0
/usr/share/doc/protobuf-2.5.0/CHANGES.txt
/usr/share/doc/protobuf-2.5.0/CONTRIBUTORS.txt
/usr/share/doc/protobuf-2.5.0/COPYING.txt
/usr/share/doc/protobuf-2.5.0/README.txt

かぶるファイルがないから強制的にインストールしてみます。

# rpm -ivh --force protobuf-2.3.0-7.el6.x86_64.rpm

これであとはmoshをインストールすればすんなり入ります。

# yum install --enablerepo=epel mosh

以上。

MacBook Air(USキーボード)でキーマップをカスタマイズしてみた

MacBook Air 2012を購入してしばらくモバイル専用で使っていたけど、真面目にメインで使おうと思ったらやっぱりキーボードがめんどくさい。
今までメインではWindowsHHK Professional 2 を使っていたのでもともとかなり癖がある。
矢印キーはfnキーを押しながらで、F1~12もfnキーを押しながら使うのがスタイルで慣れていたので、Macでもできるだけ同じ感覚で使いたかった。
メインで使う気になれなかったのはキーボードが使いづらかったからだけど、一度は挫折したキーボードのremapで良い感じになってきたのでメモ。
ちなみに当然MacもUSキーボードでcapslockはctrlキーと入れ替えており、それを前提としたカスタマイズ。

使うのは多くの人が使っていると思うKeyRemap4MacBook
KeyRemap4MacBook - OS X用のソフトウェア

やりたいこと

自分の設定ではdeleteとバックスラッシュを入れ替えたり、Escとバッククォートを入れ替えたりもしているんだけど、そこはHHKになるべく近づけるため。
これらの設定も当然できるんだけど、そのあたりは人それぞれなのでスルー。

今回一番やりたかったことは

  • 「Control + {C,V,X}」を「command + {C,V,X}」に割り振る

ということ。
デフォルトの項目でもこれは「For PC Users」にあるんだけど、除外の項目にVim(MacVim-KaoriYa)とFirefoxがない。つまり、設定するとContorl+Vでペーストはできるようになるんだけど、gVimで矩形選択ができなくなるということになる(FirefoxはVimperatorでvimキーバインドにしてるからこちらも除外できないと困る)。
普段はターミナルで作業するからgVimwikiの編集とかぐらいにしか使わないんだけど、vimと設定はなるべくあわせておきたい。キーバインドの設定とか変えればいいんだろうけど、そっちはいじりたくない。
Mac使うんだからMacキーバインドでやれよという話もあるけど、WinもLinuxも使うのでキーの配置と操作内容はなるべく一致させておきたい。
Winから来た人はやっぱControlとcommandが別でそれぞれ役割もってるのが戸惑う箇所なんではないかと思う。ターミナル使ってると特に。。。

実際の作業

でいろいろ見ていると、private.xmlで項目追加すれば除外アプリケーションを自分で設定できるということに気づいた。ググってみると同じようにカスタマイズしてる人もいたのでそれらを参考にprivate.xmlを設定した。
設定は 「/Library/org.pqrs/KeyRemap4MacBook/app/KeyRemap4MacBook.app/Contents/Resources/include/checkbox/for_pc_users.xml」を参考にカスタマイズしてついでに他に設定したいことも追加した。
ちなみにカスタマイズは直接変更を加えるのではなくprivate.xmlで行うのが作法のらしい。

<?xml version="1.0"?>
<root>
  <appdef>
    <appname>MACVIM</appname>
    <equal>org.vim.MacVim</equal>
  </appdef>

  <item>
    <name>Use PC Style Copy/Paste #5</name>
    <appendix>(Control+C to Command_L+C)</appendix>
    <appendix>(Control+V to Command_L+V)</appendix>
    <appendix>(Control+X to Command_L+X)</appendix>
    <appendix>(Except in Terminal, VM, RDC, Emacs, X11, Eclipse, MacVim)</appendix>
    <identifier>remap.copy_paste_winstyle_no_term_and_macvim</identifier>
    <not>EMACS, TERMINAL, VIRTUALMACHINE, REMOTEDESKTOPCONNECTION, X11, ECLIPSE, MACVIM</not>
    <autogen>--KeyToKey-- KeyCode::C, VK_CONTROL, KeyCode::C, ModifierFlag::COMMAND_L</autogen>
    <autogen>--KeyToKey-- KeyCode::V, VK_CONTROL, KeyCode::V, ModifierFlag::COMMAND_L</autogen>
    <autogen>--KeyToKey-- KeyCode::X, VK_CONTROL, KeyCode::X, ModifierFlag::COMMAND_L</autogen>
  </item>
  <item>
    <name>Use PC Style Select All #2</name>
    <appendix>(Control+A to Command_L+A)</appendix>
    <appendix>(Except in Terminal, VM, RDC, Emacs, X11, Eclipse, MacVim)</appendix>
    <identifier>remap.select_all_winstyle_no_term_and_macvim</identifier>
    <not>EMACS, TERMINAL, VIRTUALMACHINE, REMOTEDESKTOPCONNECTION, X11, ECLIPSE, MACVIM</not>
    <autogen>--KeyToKey-- KeyCode::A, VK_CONTROL, KeyCode::A, ModifierFlag::COMMAND_L</autogen>
  </item>
  <item>
    <name>Use PC Style New #2</name>
    <appendix>(Control+N to Command_L+N)</appendix>
    <appendix>(Except in Terminal, VM, RDC, Emacs, X11, Eclipse, MacVim, FireFox)</appendix>
    <identifier>remap.new_winstyle_no_term_and_macvim</identifier>
    <not>EMACS, TERMINAL, VIRTUALMACHINE, REMOTEDESKTOPCONNECTION, X11, ECLIPSE, MACVIM, FIREFOX</not>
    <autogen>--KeyToKey-- KeyCode::N, VK_CONTROL, KeyCode::N, ModifierFlag::COMMAND_L</autogen>
  </item>
  <item>
    <name>Use PC Style Find #2</name>
    <appendix>(Control+F to Command_L+F)</appendix>
    <appendix>(Control+G to Command_L+G)</appendix>
    <appendix>(F3 to Command_L+G)</appendix>
    <appendix>(Control+F3 to Shift+Command_L+G)</appendix>
    <appendix>(Except in Terminal, VM, RDC, Emacs, X11, Eclipse, MacVim, FireFox)</appendix>
    <identifier>remap.find_winstyle_no_term_and_macvim</identifier>
    <not>EMACS, TERMINAL, VIRTUALMACHINE, REMOTEDESKTOPCONNECTION, X11, ECLIPSE, MACVIM, FIREFOX</not>
    <autogen>--KeyToKey-- KeyCode::F, VK_CONTROL, KeyCode::F, ModifierFlag::COMMAND_L</autogen>
    <autogen>--KeyToKey-- KeyCode::G, VK_CONTROL, KeyCode::G, ModifierFlag::COMMAND_L</autogen>
    <autogen>--KeyToKey-- KeyCode::F3, VK_CONTROL, KeyCode::G, ModifierFlag::COMMAND_L | ModifierFlag::SHIFT_L</autogen>
    <autogen>--KeyToKey-- KeyCode::F3, KeyCode::G, ModifierFlag::COMMAND_L</autogen>
  </item>
</root>

簡単に解説するとでアプリケーションを定義して各セクションの要素で指定するだけ。あとはネーミングが既存のものと被らないようにナンバリングしてある。
設定してる内容は以下。

  • 「Control + {C,V,X}」を「command + {C,V,X}」に割り振る
    • ただしMACVIMは除く
  • 「Control + A」を「command + A」に割り振る
    • ただしMacVimは除く
  • 「Control + N」を「command + N」に割り振る
    • ただしMacVim/Firefoxは除く
  • 「Control + F」を「command + F」に割り振る
    • ただしMacVim/Firefoxは除く

Firefoxが入っている理由はvimperatorアドオンを入れてvimコマンドで操作しているから。
これで他のアプリケーションでもControl+Nで新規ウインドウとかが可能になった。
大分使いやすくなったけど他の人はどうやってるんだろうかと気になる。同じこと考える人はいると思うんだけど、もっとうまいやり方があるのかな。

他にも必要な設定があれば自分で簡単に設定できるのは本当にすばらしい。KeyRemap4MacBookは神ツールと言える。


MySQLのプロンプトの色をシェル側で設定する

MySQLのプロンプトカラーをテストサーバとそれ以外などという形で設定したい場合のメモ。
見つけたやり方は以下。

ただ今回やりたかったのはシェルの環境変数を使ってカラーリングすること。そこで色々ググると以下のページを発見。

上記のページでも書かれている通り、環境変数MYSQL_PS1で設定すればOKなわけだがこのやり方だとエスケープの入力が毎度めんどくさい。新しく設定するときもさくっとコピペできるようにしておきたかった

シェルで特殊文字入力

特殊文字を変数に格納してそれを使って環境変数の設定を行う。
以下を/etc/profileなり~/.bash_profile(bashの場合)なりに追記する。

# mysqlプロンプトのカラー
mycolor=$'\e[1;32m'
clear=$'\e[0m'
export MYSQL_PS1="$mycolor\u@\d \v>$clear"

するとこんな感じになる。

カラーコードは以下。

Black       0;30     Dark Gray     1;30
Blue        0;34     Light Blue    1;34
Green       0;32     Light Green   1;32
Cyan        0;36     Light Cyan    1;36
Red         0;31     Light Red     1;31
Purple      0;35     Light Purple  1;35
Brown       0;33     Yellow        1;33
Light Gray  0;37     White         1;37

MySQLPS1で使える特殊文字は以下を参照。

ちなみに動作はbash/zshで確認済み。他のシェルでもいける記述なのかは調べてない。
というか$'...'特殊文字の設定ができることを知らなかったよ・・・。


[2012-03-21追記]
どうも長いクエリを実行しようとすると折り返しがうまくいかなくて表示が上書きされてしまう。プロンプトの最後を「\n」で改行にすれば問題ないんだけど回避する方法はないものか。
my.cnfで設定しても同様。ググって出てくるようにエスケープ文字入力しても同じ。みんなどうやってるんだろう。

NexentaStor Community Editionの初期設定的な何か

以前のエントリで概要とインストールについて書いたわけですが、実際に使うとなると色々設定する必要があるわけです。
概要についてはこちら

自分も全部の機能を把握してるわけではないので、とりあえず手をつけた部分をメモがわりに。あとここではCommunity Edition(以下CE)を対象にしています。内部のシェルで操作(expert mode)する部分が多分にあります。標準のコマンドラインからの操作以外のシェル操作はEnterprise Edition(以下EE)の場合サポート対象外になるのでやらないほうがいいです。CEは機能削られてるので自分で面倒見れるなら自分で色々いじくればいいんじゃね?のスタイルで使える人に向いてるかも知れません。もともとサポートないので。

尚、ここで解説するバージョンは3.0.4です。過去の例からマイナーバージョンの違いでも変わる部分があるので参考にする方はその点ご注意ください。

続きを読む