ひげろぐ

勉強会などのメモを今までは紙のノートに取っていたのだけれど、ノートPCで取った方が速いし編集も楽なので気軽に持ち運べるノートが欲しくなった。
MacBook Proは持ち歩くにはやっぱしでかいし重いのですよ。

ということでレッツノートのR7を中古でゲットしてきた。
近所のヤマダ電機で5万円ちょい。
OSがVistaだったが、もともとLinuxを入れて使うつもりだったので問題はない。

Linuxは昨今評判の良いUbuntuを入れてみることにした。9.10の日本語Remix版。
DVDドライブが付いてないが、USBのドライブをつないでさくっとインストール終了。
サウンドも無線LANもあっさり動いた。
普段Redhat系を使ってる人なのでDebian系はイマイチ使い勝手が分からないところもあるけど、今のところ不便は感じない。

現在まだカスタマイズ中だが、サスペンドからの復帰時にたまに固まってしまうという問題がある以外は概ね快適。
外出時に持ち歩いてみたりもしているが、本一冊分程度のサイズはやっぱりよい。カバンの中に常備しておいても気にならない携帯性だ。

思った以上にいろいろできるのでiPhone開発する気がなければMacいらないような気すらしてきました。

現在のカスタマイズ内容

タッチパッド

このあたりを参考にしてホイールスクロールを有効にした。
しかし本家の動作とは違ってスクロール開始と見なされる範囲がちょっと広い気がする。
そのためカーソルを動かしたいときにスクロールが始まってしまうことがあるのでちょっとだけ残念な感じがする。

キーマップ

まずはお決まりのCtrlキーの位置の調整。

パネルの「システム」 > 「設定」 > 「キーボード」で、キーボードの設定を開く。
それから「レイアウト」タブの「レイアウトのオプション」で「Ctrlキーを位置」からCapsLockをCtrlにしてしまう。
で、CapsLockはなくても困らないので元々のCtrlもCtrlのままにしておく。

それから無変換キーと変換キーで日本語入力の切り替えを行いたい。

xmodmap -pre > ~/.Xmodmap

~/.Xmodmapを編集して半角/全角キーに割り付けられていた機能を無変換キーと変換キーにも割り当てる。
これで無変換キーと変換キーを半角/全角キーと同じ働きになった。

そしていったんログアウトすると変更が有効に。

キーボードショートカット

パネルの「システム」 > 「設定」 > 「キーボード・ショートカット」からいろいろと設定できる。

Menuキー => ターミナルを起動

今のところとりあえずこれだけ。
ランチャーからgnome-terminalという名前を指定するのがダルイので。

ランチャー

「アプリケーション実行のダイアログ・ボックス」が標準であるけどランチャーとしては頼りない。
MacのQuickSilverライクなランチャーでGNOME-Doなるものがあるというのでインストール。

sudo apt-get install gnome-do

これでWinキー + Spaceで立ち上がるように。
いいですね。

Vim

sudo apt-get install vim-gnome

vim-gnomeを入れて、Macで使ってる.vimrcなどを設置。
まだいろいろ試行錯誤中。

ATOK

標準の日本語変換もそれなりの使い勝手だったが、やはり物足りなさを感じたのでLinux版を購入。
なんだかんだ言ってもまだATOKに及ぶIMEはないですな。

Ubuntu9.10で動かすにはいろいろとパッチも必要になるので本体のソースの他にサポートページから適当に落として入れる。
ぐぐるといろいろ情報が出てくる。
インストールはシェルスクリプトとかファイルコピーとかイマイチ洗練されてないが、十分簡単ではある。

Ruby

1.9を入れた。
そろそろシフトするかと。

あとでTDD環境も整えなくては。

Firefox

ついにvimperalorに手を染めた。
これでめでたく変態の仲間入りです。

Dropbox

Linux版のクライアントもしっかり用意されているとは素晴らしい。
Dropbox公式からゲットできます。

昨日XenのDomainUのひとつがいつの間にかRead-onlyになっていた。
とりあえずログを見ても原因がわからない。何らかのI/O負荷に伴うものだろうか。

muninのグラフを見ると障害の直前までに徐々に負荷が高まっている様子が確認できたので、なんとなく状況は把握。
この負荷が高まった原因については分かっているけど、すぐに対応できるものではないのでこちらはタスクに放り込んでスルーしておく。

止まっても緊急性のないサーバなのでのんびりと復旧を開始した。

ひとまず再起動

しょっぱなから適当に最強の回復魔法を試してみたのだが撃沈。
どうもブートの途中でひっかかってしまって起動しなくなった。

起動時にfsckが走ることを期待したのだが、そこまでも行かないっぽい。
しかしながらXenのconsoleから確認するとディスクをマウントするところで止まっているっぽいので、やはりまずはfsckをかけたいところだ。

Domain0からディスクイメージの中身をfsck

そこでDomain0からイメージファイルの中身を触って修復することにした。

まずディスクイメージをloopデバイスに割り当てる
これにはlosetupを使う。

# losetup /dev/loop0 /var/lib/xen/images/hoge.img

まだこの状態ではfsckかけてもext2じゃないよとか言われて動かないので更にパーティションごとにアクセスできるようにする。

# kpartx -a /dev/loop0

これで/dev/mapper/以下にloop0p1からloop0p8までパーティションに応じたデバイスができるので、これらをfsckすることができるようになった。

# e2fsck -c -f /dev/mapper/loop0p1

p4が欠番でp3はswapなのでスルーしてp1,p2,p5,p6,p7,p8を順にfsck。
p7とp8でいくつか不良ブロックが見つかったのでyを何回か押して修復完了。

最後に後始末しておしまい。

# kpartx -d /dev/loop0
# losetup -d /dev/loop0

これで再度起動すると無事起動して動き出した。
素晴らしい。

参考

• Xenのイメージファイルをマウントする < < そこはかと
• HDDイメージファイルをマウントして使う方法 – adsaria mood
• 19.11.ゲストディスクイメージ上のデータアクセス

最近Gitが幅をきかせているので重い腰を上げて入れてみた。
特に何も考えず以下のコマンドを打ってみる。

$ sudo yum install git

なんだか入った。

でも標準リポジトリには入ってないようだ。
標準のリポジトリじゃなくて外部リポジトリとして登録してあるDagのところから入った。
外部リポジトリ登録がない環境でもパッケージはあるのでRPMを落としてきて入れられるね。

参考：YUMで便利な外部リポジトリを使う – ひげろぐ

あとは以下のページとかみながらちょっと触ってみますかね。

Git入門 – トップページ

とりあえずチュートリアルの最初だけ試してみた。

$ git config --global user.name "akahige"
$ git config --global user.email akahigeg@gmail.com

ちゃんと登録されているのかな？

$ git config --global --list
user.name=akahige
user.email=akahigeg@gmail.com

されてた。ぐっど。

2010/7/30追記

EPELの方がなんとなく安心度高い。

$ sudo wget http://download.fedora.redhat.com/pub/epel/5/i386/epel-release-5-3.noarch.rpm
$ sudo rpm -ivh epel-release-5-3.noarch.rpm

で、yumでEPELのリポジトリが有効になる。

YUMの外部リポジトリにRedHat系のディストリで使えるRPMをたくさん配布しているDAGのサイトを登録してみる。
ここは新し目のパッケージがいろいろとあったりするので何かと便利。

DAG: RPM packages for Red Hat, RHEL, CentOS and Fedora

/etc/yum.repos.d/CentOS-Base.repoの末尾に以下の内容を追記する。

[dag]
name=Dag RPM Repository for Redhat EL5
baseurl=http://apt.sw.be/redhat/el$releasever/en/$basearch/dag
gpgcheck=1
enabled=1
gpgkey=http://dag.wieers.com/packages/RPM-GPG-KEY.dag.txt

TracとかもYUMで入れられます。

参考

MuraTaka 速記メモ / 2007-06-24

最近サービスのインフラをリニューアル中。
古いサーバをリプレースするんで新しいサーバにいろいろと移行中だったりします。

今日は開発に使っているSubversionのリポジトリをさくっと移行しました。
古いほうでバックアップして新しいほうでリストアするだけです。

バックアップ＠旧サーバ

まず古いサーバにあるSubversionのリポジトリをバックアップ。

svnadmin dump /path/to/repos > backupfile

自分以外いじる人はいないのでhotcopyとかは特に考えず。

リストア＠新サーバ

次に新しいサーバでリポジトリを作って、バックアップ内容をリストア。

svnadmin --fs-type fsfs create /path/to/newrepos
svnadmin load /path/to/newrepos < dumpfile

サーバを立ち上げて動作テスト。
ローカルからチェックアウトしてみたり、他のマシンからリポジトリの内容をブラウズしてみたり。

問題ないことを確認して完了。
簡単なもんですな。

2008/02/03追記

コミットしようとしたら認証を要求されてパスワードの設定忘れてたのに気がつきました。
ちなみにsvnserveで動かしてます。/path/to/repos/conf/svnserve.confを編集。

[general]
anon-access = none
auth-access = write

password-db = passwd
realm = brass repository

「anon-access = none」で認証されてないアクセスは一切認めず。
ちなみに「none」ではなく「read」を指定すると読み込みだけ可能になります。

「password-db」でパスワードファイル名を指定。
「realm」は認証の名前空間なので複数リポジトリを持っている場合はかぶらないようにしたほうがいいのだろうか？まあ複数リポジトリ持ってないので適当に設定。

次に/path/to/repos/conf/passwdを編集。

[users]
hogeuser = hogehoge

これで無事コミットもできるようになりました。

参考

• Subversion について
• svnserve, 専用サーバ

システムはなるべくシンプルな方がいい。
それはアプリケーション開発でも言えることだけれど、その土台となるサーバ構成にも言えることだ。

前職では主にオープンソースを利用したLinuxクラスタを作ったり運用していた。
そういう経験の上で、冗長化や負荷分散のためのクラスタリングは本当に必要でなければできるだけやらない方がいいというのが最近の考え。
システムをサーバ一台で間に合わせることができるならば、それに越したことはない。

クラスタを組むとそれだけコストが高くなる。
クラスタの設計やサーバ調達などにかかる初期コストもそうだが、特に構築後の運用コストや変更コストがバカにならない。
ほんとうにそのシステムにクラスタが必要かどうか、そのコストの見極めをしっかりしたほうがよい。

クラスタを組むとサーバ一台で運用するのに比べて

• ネットワーク構成の複雑化
• クラスタリングを見越したアプリケーションの実装
• 複数サーバのソフトウェアのバージョンアップ
• 複数サーバへのアプリケーションのデプロイ
• 運用の設計と組み立て
• 構成変更時にいろいろと気を遣う

などなど面倒ごとが増える。
それだけ運用負荷があがる。
消費MPが増える。

サーバ一台の構成に比べてシステムに変更を加えるのに気を遣わねばならず、その作業の効率化や運用の組み立てにコストがかかるようになる。
まあ運用の組み立てがうまくいけばそのノウハウは財産になるかもだけど。

もちろん要件的に必要であれば、コストをかけてクラスタを組む価値がある。（コストがかけられなければ要件が無茶ってことだ）
しかしその要件が「あればいいな」くらいのレベルであるならばまずはクラスタを組まずに一台で様子を見た方がいいんじゃないだろうか。
または何らかの代替手段を検討できないだろうか。

サーバ一台でも電源冗長化やボンディング、RAIDなど、障害の発生率を抑える手段はいろいろある。
またリソースのモニタリングをしっかり行ってチューニングしていけば、一台でもパフォーマンスは上がる。
もしかするとサーバ構成以外にも問題解決のポイントはあるかもしれない。

システムはシンプルであることでより堅牢になり、変更に対するフットワークも軽くなる。
サーバ構成にもなるべくシンプルさを心がけたいものだ。

近況とかつぶやきとか

薄めたポカリがマイブーム。水3:ポカリ1。