2013年1月5日土曜日

git との格闘w その2 いろいろ変更

さて、サーバーにも接続できるようになったところでチュートリアルに戻ります。さっき clone したところに移動して、
$ vi README        <-- 適当に編集
$ git commit -a
[master 2698c25] Add one line
 1 files changed, 1 insertions(+), 0 deletions(-)
git commit をするとエディタが上がるので適当に commit のコメントを追加。これも git push origin master で push してみるとうまくいく。なるほど。

次はstaging。
$ vi README 
$ vi tmp/README 
$ git status
# On branch master
# Changed but not updated:
#   (use "git add ..." to update what will be committed)
#   (use "git checkout -- ..." to discard changes in working directory)
#
# modified:   README
# modified:   tmp/README
#
no changes added to commit (use "git add" and/or "git commit -a")
何か変更を作ってみた。一つ staging。
$ git add README 
$ git status
# On branch master
# Changes to be committed:
#   (use "git reset HEAD ..." to unstage)
#
# modified:   README
#
# Changed but not updated:
#   (use "git add ..." to update what will be committed)
#   (use "git checkout -- ..." to discard changes in working directory)
#
# modified:   tmp/README
#
コミットしてみる。
$ git commit
[master ae419f9] Add another line
 1 files changed, 1 insertions(+), 0 deletions(-)
$ git status
# On branch master
# Your branch is ahead of 'origin/master' by 1 commit.
#
# Changed but not updated:
#   (use "git add ..." to update what will be committed)
#   (use "git checkout -- ..." to discard changes in working directory)
#
# modified:   tmp/README
#
no changes added to commit (use "git add" and/or "git commit -a")
ほほう。1つはちゃんと commit されて、もう一つの変更はそのままと。さっき何も考えずに commit -a としていたが、その -a は全部ファイルを commit しちゃうためのものだったとか。(それを知らずに -a して全部コミットされたアカウントはこちらですw その場合は git reset --hard HEAD~ とやると全部投げ捨てられる模様。)なるほどなるほど。この状態でまた push すると当然 commit されたものだけ飛んでいきます。

次はいよいよブランチ。
$ git branch
* master
作成。
$ git branch experiment
$ git branch
  experiment
* master
作成されました。
$ git checkout experiment
M tmp/README
Switched to branch 'experiment'
$ git branch
* experiment
  master
$ git status
# On branch experiment
# Changed but not updated:
#   (use "git add ..." to update what will be committed)
#   (use "git checkout -- ..." to discard changes in working directory)
#
# modified:   tmp/README
#
no changes added to commit (use "git add" and/or "git commit -a")
なるほど・・・。さっき commit してなかった変更とかはそのままなんですね。当たり前か。
$ vi TODO
$ git add TODO 
$ git commit -am "Commit on branch"
[experiment 700f0dc] Commit on branch
 2 files changed, 3 insertions(+), 1 deletions(-)
 create mode 100644 TODO
$ git status
# On branch experiment
nothing to commit (working directory clean)
あれ、commit どこいった?
$ git diff master
diff --git a/TODO b/TODO
new file mode 100644
index 0000000..295f16a
--- /dev/null
+++ b/TODO
@@ -0,0 +1,2 @@
+Todo file
+
diff --git a/tmp/README b/tmp/README
index edb0724..3105724 100644
--- a/tmp/README
+++ b/tmp/README
@@ -1,2 +1,2 @@
 This is sample file 2.
-
+This is another line in another file.
とりあえず master との比較ではずれがあることはわかる。(コマンドがこれでいいのかは不明。)
$ ls
README  tmp  TODO
$ git checkout master
Switched to branch 'master'
Your branch is ahead of 'origin/master' by 1 commit.
$ ls 
README  tmp

さあ conflict させてみますよ。
$ vi tmp/README 
$ git commit -am 'Conflict!'
[master 9fb2424] Conflict!
 1 files changed, 1 insertions(+), 1 deletions(-)
これで master と experiment がそれぞれ先へ進みました。マージしてみます。
$ git merge experiment
Auto-merging tmp/README
CONFLICT (content): Merge conflict in tmp/README
Automatic merge failed; fix conflicts and then commit the result.
おうふ・・・。ちょっと変更が近すぎましたかね。TODO のほうは成功したんですが tmp/README がだめでした。ファイルの中身はどうなってるかな?
$ cat tmp/README 
<<<<<<< HEAD
This is sample file 2 and more!.

=======
This is sample file 2.
This is another line in another file.
>>>>>>> experiment
解決するには編集して普通に add して commit だそうで。
$ vi tmp/README 
$ git add tmp/README 
$ git commit -am 'Resolve conflict'
$ git status
# On branch master
# Your branch is ahead of 'origin/master' by 4 commits.
#
nothing to commit (working directory clean)
それぞれの変更が入った状態の完成です。最後にワークに使った branch を消す。
$ git branch -d experiment
Deleted branch experiment (was 700f0dc).

git との格闘w その1 git サーバー on CentOS 6

気楽に Twitter4J の JavaDoc のリンク切れをドヤ顔で指摘したら、pull request してくださいとの返答をいただき、これまた気軽にりょうかいしたところ、やったことない人には壮絶に敷居が高そうなことがわかりましたw 自宅で1人で書いてるコードの変更管理なら CVS やら SVN やらで十分だし、仕事では某社のツールべったりだったし、目にはしたけど使ったことないんですよね、git。なのでもちろん github も見るだけでして。ここで諦めてもいいんですが、せっかくなので挑戦してみますか。まずは git から。

インストール

ふむふむ。git はコマンドラインでいろいろやるっぽいですね。もちろん IDE からもできるはずですがコマンドの理解から入るほうが理解しやすいですし。最終的にはせっかく買ったこの子から使いますよ。で、コマンドライン環境は・・・そんな時のために Linux サーバーがあるんですよ! ええ!早速インストールです。
# yum install git
(snip)
Setting up Install Process
Package git-1.7.1-2.el6_0.1.x86_64 already installed and latest version
Nothing to do
既に入ってましたw

使ってみる

まあ何はともあれ使ってみよう。まずはこのへんを読んでみる。ポイントは分散開発環境では当然問題になる部分ですが”cheap branching and easy merging”という部分にありそうですね。

まずは全体の環境設定から。
$ git config --global user.name "Sdk0815"
$ git config --global user.email "***@***.***"
何かリポジトリを作ってみます。
$ mkdir -p git/sample
$ cd git/sample
$ git init
Initialized empty Git repository in ~/git/sample/.git/
適当にファイルを置いて
$ git add .
$ git log
fatal: bad default revision 'HEAD'
$ git commit -m "initial commit"
[master (root-commit) 253133b] initial commit
 2 files changed, 4 insertions(+), 0 deletions(-)
 create mode 100644 README
 create mode 100644 tmp/README
$ git log
commit 253133b619739070a06835181c4ed6c40aa7e08c
Author: Sdk0815 <***@***.***>
Date:   Fri Jan 4 13:55:45 2013 +0900

    initial commit
ふむ。何かコミットできたようです。

・・・というか、ここから先はサーバーとやりとりするようになってる。せっかくだから自宅サーバーも git のサーバーとして使えるようにしてみるか?

サーバー構築

今度は
# yum install git-daemon
(snip)
Running Transaction
  Installing : 2:xinetd-2.3.14-35.el6_3.x86_64         1/2 
  Installing : git-daemon-1.7.1-2.el6_0.1.x86_64       2/2 
  Verifying  : git-daemon-1.7.1-2.el6_0.1.x86_64       1/2 
  Verifying  : 2:xinetd-2.3.14-35.el6_3.x86_64         2/2 

Installed:
  git-daemon.x86_64 0:1.7.1-2.el6_0.1
Dependency Installed:
  xinetd.x86_64 2:2.3.14-35.el6_3

Complete!
入ってませんでしたのでめでたくインストールw /etc/xinetd.d/git を開き、disable = yes を no に変更し、xinitd を restart。

ん、これだけ?よくわからんのでとりあえずリポジトリを作って進んでみよう。ユーザーも特に作られてないし・・・。
# cd /var/lib/git/
# mkdir sample
# cd sample
# git init --bare --shared
さっきのプロンプトに戻って
$ git remote add origin git://localhost/sample
$ git push origin master
fatal: The remote end hung up unexpectedly
ですよね・・・。そううまくいくわけはなく。/var/log/messages を見ると
git-daemon[25672]: 'receive-pack': service not enabled for '/var/lib/git/sample'
なるほど。さっきの /etc/xinetd.d/git の server_args に --enable=receive-pack を追加して xinetd を再起動してみる。
$ git push origin master
Counting objects: 5, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (5/5), 333 bytes, done.
Total 5 (delta 0), reused 0 (delta 0)
error: unpack failed: unpack-objects abnormal exit
To git://localhost/sample
 ! [remote rejected] master -> master (n/a (unpacker error))
error: failed to push some refs to 'git://localhost/sample'
めげるな!またログを見ろ!
git-daemon[25747]: error: insufficient permission for adding an object to repository database ./objects
ふむ。さっきの /var/lib/git/sample には objects ってディレクトリがあってそこは root の持ち物になってる。xinetd は root だが・・・ってそうか!また /etc/xinitd.d/git に戻り、ユーザーをチェックすると、nobody になってる。なるほど、では git ユーザーを作って再挑戦。ついでに repository のディレクトリも ~git/repo に変更。xinitd を再起動していざ。
$ git push origin master
Counting objects: 5, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (5/5), 333 bytes, done.
Total 5 (delta 0), reused 0 (delta 0)
To git://localhost/sample
 * [new branch]      master -> master
おおお?うまくいったかな?確認。
$ cd ..
$ ls
sample
$ rm -rf sample
$ ls
$ git clone git://localhost/sample
Initialized empty Git repository in ~/git/sample/.git/
remote: Counting objects: 5, done.
remote: Compressing objects: 100% (2/2), done.
remote: Total 5 (delta 0), reused 0 (delta 0)
Receiving objects: 100% (5/5), done.
$ ls
sample
$ cat sample/README 
This is test file.

おおお、できましたね!

2013年1月4日金曜日

Linux で日本語

実際のところそんなには利用頻度は高くないですが、Linux 環境でも日本語を入力したくなることはあります。たとえばここに書くときとかw これまでは Linux で作業したやつをコピペして Windows 上で書いてたのですが、いい加減面倒くさくなってきました。 なので大した手間ではなかったので手順を書いておきます。

インプットメソッド

インストールしたときに日本語を選んでおけばよかったのですがそんなつもりもなかったので英語でインストールしてました。でもその状態でも IM とかはちゃんと入ってるようですね。

  1. gnome 上から System -> Preferences -> Imput Method を選ぶ
  2. iBus を選び、Imput Method Preferences をクリック
  3. Imput Method タブで Japanese -> Anchy を選び、Add
  4. ログアウトしてログインしなおす
これで日本語入力ができるようになるはずですし、直接コンソールから入ってる場合は Ctrl+Space や半角全角キーで日本語モードになるはず。

しかし私の環境では Linux マシンにはディスプレイ等はつながっておらず、常に VNC で作業してる状態なのですが、VNC 経由では Ctrl+Space は効くものの半角全角は効かない。しかも Ctrl+Space って IDE/エディタでは重要なキーバインドなのでやはり半角全角で変換したいです。なので先ほどの Input Method Preference に戻ります。
  1. Keyboard Shortcuts の Enable or disable : のところの ... をクリック
  2. Keycode の ... のところをクリック
  3. ダイアログが出てるところで半角全角キーを押す
  4. 出てきた「Hankaku」と「Zenkaku」を "Release" のチェックを外して Add
VNC の設定等で回避できるのかもしれないのですがキーコードが Hankaku か Zenkaku になるようですね。

これで日本語の入力ができるようになりました。

フォント

入力はできるようになりました。しかし表示は相変わらず昔のコンピュータみたいです。もう少しマシなフォントを入れますか・・・。おお、今時はIPAフォントが base からとれるんですね。
# yum install ipa-*-fonts
(snip)
Installed:
  ipa-gothic-fonts.noarch 0:003.02-4.2.el6           ipa-mincho-fonts.noarch 0:003.02-3.1.el6          ipa-pgothic-fonts.noarch 0:003.02-4.1.el6         
  ipa-pmincho-fonts.noarch 0:003.02-3.1.el6         

Complete!
$ fc-list  | grep IPA
IPAGothic,IPAゴシック:style=Regular
IPAPGothic,IPA Pゴシック:style=Regular
IPAMincho,IPA明朝:style=Regular
IPAPMincho,IPA P明朝:style=Regular
楽々ですね。ってもそんなに綺麗にはなってない気がしますが・・・。文字が少しぼけた感じなのはフォントを変える前からですが。

2013年1月3日木曜日

#f1yosou : HRD への移行

というわけで、HRD への移行を行ってみます。基本はガイドに従えばいいはず・・・。

TaskStatusRemarks
Duplicating Your ApplicationDone
Deploying Your New HRD ApplicationDone
Using the Migration ToolDone結構待ちます。

あれ、結構簡単でした?w

しかし実際は index の定義をちゃんと書いてるわけではない(Eclipse 上で実行していると自然と生成される定義を使っていた)ので、最初に新しいアプリケーションのほうに deploy したら索引が全くない状態になってしまいました。なので開発環境で適当に実行して生成された定義を使ってもう一度 deploy。今度はうまくいきました。

果たして migration した元のアプリケーションは消してよいのか。消さないと10個までというアプリケーション数の制限を圧迫するんだけど・・・。

同様にチェックしたDMログ(仮)は実はバグがあってだいぶ前から動いてなかったっぽい。けど何も言われてないってことはそろそろ消してもいいかな?政治家的にいえば「一定の役割は果たした」のでw

#f1yosou : 現状の説明

みなさんご存知の通り #f1yosou の中の人をやっているわけですが、今年もやるためには以前ツイートしたように、
といった作業が必要になります。作業を分類すると

必須の作業
  • HRD 移行
  • Twitter API V1.1 対応
ほぼ必須の作業
  •  公式アカウントによる参加者のフォロー&TL読み込み(Twitter API V1.1でリスト関連の API が変更になったため、どのみち何らかの作業が必要なため)
できればやりたい作業
  • DMによるお題投票
  • ログインシステム廃止
といった感じです。

このうち Twitter API V1.1 対応については Twitter4J V3.0.3 への更新が完了したので基本問題ないはずです。なので残る作業は HRD 移行とフォロー&TL読み込みです。

ちなみにHRDなんじゃそれと言う方も多いと思うので一応説明しておくと、#f1yosou のサイトは Google App Engine for Java といういわゆる PaaS サービス(の無料部分を!)利用しています。しかし #f1yosou サイトを立ち上げた当時にはデータストアとして Master/Slave というものが使われていたのですが、それが deprecated となり、HRD (High Replication Datastore)に1年以内に移行する必要が出てきました。一応別のアプリケーションとして新たに同じコードを deploy したらちゃんと HRD 上でも動いたので移行作業さえ終われば問題はないはずですが・・・。面倒そうな雰囲気だけがありますw

さて今年の開催も含めてどうするか。悩みどころです。

2013年1月2日水曜日

RAID と LVM と 4K セクタ

フォロワーさん(いつもありがとうございます!)から教えていただいた情報。
LVM on RAID するときの注意点
そういえば(爆)使ってるディスクたちは Western Digital のいわゆる Advanced Format、つまり4096バイトセクタを採用しているディスクたちでした。もともと512バイトが一般的だったので、それを前提としたフォーマットを特に考えないで使ってしまうとパフォーマンスが劣化すると言うやつですね。まあぶっちゃけるとサイズにばかり目が行ってて忘れてました。 orz

で、ようやく全ステップが完了したのでのんびり(おい)対応していこうかなぁと。また無駄なデータの移動とかしちゃうけどね~。楽しいからいいもんね~。などと自分をごまかしつつ。

ディスク全体をRAID1にしてる場合

まずは上記のリンクにあるように、ディスク全体を RAID 1 にしてる人。そんなことしてるわけが・・・ありました。うーむ。まずは RAID の superblock のバージョンですが、
# mdadm --detail /dev/md4
/dev/md4:
        Version : 1.2
おうふ・・・。お勧めの1.0なんかにはもちろんしていない。上のリンクでは、1.0だとmetadata の位置が領域の最後方となるため、データ領域がディスクの先頭=4096バイトセクタの先頭ということですよね。えー、でも1.0より新しい気がするのに問題あるとか納得いかない感じなのですが・・・。1.2とはどういうものかというとこれによれば、superblock の場所が
4K from the beginning of the device
とあります。1.0だとたしかに at the end of device とあるのでデータ領域は先頭のようです。しかしどう読んでも superblock の長さもわからないのでデータ領域がいくつから始まってるのか不明。いろいろ調べたら mdadm で調べられると。コマンド発行対象のデバイスはディスク自体であることに注意です。
# mdadm -E /dev/sdc
/dev/sdc:
        Version : 1.2
(snip)
    Data Offset : 2048 sectors
   Super Offset : 8 sectors
たしかに superblock は 8 sectors = 512x8 bytes = 4096 ですね。でも Data Offset はちゃんと 2048 sectors = 512x2048 bytes で 4K セクタに合っているではないですか!GJ!(であってますかね?w)

なので RAID のほうはこのままで OK と。次はPV(物理ボリューム)のほうです。 これもデータ領域がどこから始まってるかが問題。
# pvdisplay --verbose /dev/md4
    Using physical volume(s) on command line
  --- Physical volume ---
  PV Name               /dev/md4
  VG Name               vg_data
  PV Size               2.27 TiB / not usable 1.64 MiB
  Allocatable           yes (but full)
  PE Size               4.00 MiB
(snip)
うーむ。これもまたデータ領域がどこから始まってるのかわからない。man pvcreate 等を見ていたら、pvs でどこから始まってるのかがわかるそうな。
# pvs -o +pe_start
  PV         VG      Fmt  Attr PSize   PFree   1st PE 
  /dev/md4   vg_data lvm2 a--    2.27t      0    1.00m
おお!?これって最初のPEが1Mから始まってるってことですよね?ということはこれも4KにアラインしてるということでOK!(でいいんですかね?w)そして PE の単位は上で調べたとおり4Mなので当然4Kにアラインします。というわけで、結論。
 ディスク全体を RAID 1 にしたものについてはこのまま運用!w
 あってるかどうか実験しようもないのであくまでも推察ですが・・・。結局のところ勝手によきにはからってくれるようないい時代になったってことですかね。

パーティションを切ってRAID1してる人たち(>2TB)

次はパーティションを切ってる場合の調査です。これはさんざいわれてましたね。fdiskを使うときに。
# fdisk /dev/sde

WARNING: GPT (GUID Partition Table) detected on '/dev/sde'! The util fdisk doesn't support GPT. Use GNU Parted.


WARNING: The size of this disk is 3.0 TB (3000592982016 bytes).
DOS partition table format can not be used on drives for volumes
larger than (2199023255040 bytes) for 512-byte sectors. Use parted(1) and GUID 
partition table format (GPT).


The device presents a logical sector size that is smaller than
the physical sector size. Aligning to a physical sector (or optimal
I/O) size boundary is recommended, or performance may be impacted.

WARNING: DOS-compatible mode is deprecated. It's strongly recommended to
         switch off the mode (command 'c') and change display units to
         sectors (command 'u').

Command (m for help): q

・・・って新しく買ったディスク、3TBなので fdisk を使おうとすると警告が出ます。というか警告多すぎw そのまま使うと正しく認識されなかったりさんざんな目にあうとか。実際 2.5TB のディスクを Windows につけたら謎のパーティション構成になってました。そちらは dos 形式の MBR を gpt に変更したら直りましたけど。

で、今回はいよいよ上の警告でお勧めされている parted を使いました。なんか使ったことないので怖いぞw parted で mkpart を実行すると、もう画面はどっかいっちゃったので見せられませんが、「このままだとパフォーマンス悪いよー」的な警告が。その対策としては「ユニットをMiBにすればいいよ」と。なので u MiB をしてからパーティションを作成すると何も言われずに作成されます。果たしてこのパーティションは 4K バイトに沿っているのでしょうか?
(parted) u s                                                              
(parted) print                                                            
Model: ATA WDC WD30EZRX-00D (scsi)
Disk /dev/sde: 5860533168s
Sector size (logical/physical): 512B/4096B
Partition Table: gpt

Number  Start        End          Size         File system  Name  Flags
 1      2048s        3907028991s  3907026944s                     raid
 2      3907028992s  5860532223s  1953503232s
ユニットをs(セクタ)にして print してみたところ、ちゃんと開始が 2048s になってました。ということでこれもOKだし、RAID の superblock も
# mdadm -E /dev/sde1
/dev/sde1:
(snip)
    Data Offset : 2048 sectors
   Super Offset : 8 sectors
なのでこれも問題なし!(ですよね?ww)というわけで、結論。
 3TB で RAID 1 にしたものについてもこのまま運用!ww

 パーティションを切ってRAID1にしてる人たち(ブート)

さて最後に残った一番怪しそうなところです。今回 CentOS を新たにインストールしたとき、インストーラの時点で RAID のパーティションを作成してインストールしました。ここが一番うまくいってなさそうな気配です。ここを上と同様にチェックしてみます。
(parted) u s                                                              
(parted) print                                                            
Model: ATA WDC WD20EARS-00M (scsi)
Disk /dev/sda: 3907029168s
Sector size (logical/physical): 512B/512B
Partition Table: msdos

Number  Start       End          Size         Type     File system  Flags
 1      2048s       1050623s     1048576s     primary  ext4         boot, raid
 2      1050624s    17827839s    16777216s    primary               raid
 3      17827840s   554698751s   536870912s   primary               raid
 4      554698752s  3907024064s  3352325313s  primary               raid
まずいきなり見えた1から2048セクタなのでいい感じ?ほかもすべて 2048 (64) の倍数から開始しているのでこれもよさそうな感じではないですか!(本当にいいんですよね?www) RAID の superblock も同じように 2048 sector から開始しているようです。なんだすばらしいじゃないですか。ちなみに partition 3 は / 用に切ったパーティションなんですが、この人はなぜか metadata 1.1 になってます。インストーラから作る /boot でないやつは 1.1 になるんですかね。

というわけで、結論。
 インストール時に作ったものについてもこのまま運用!www
 というわけで、今現在ささっているすべてのディスクについてこのまま運用するという結論が出ました。めでたしめでたし。

(間違ってるところあったらぜひ指摘していただけるとうれしいです。)

Step 9-11 : 完了

さていよいよ最終ステップです。
  1. もともと VG に入っている 1.5TB の HDD を抜き、新たに 3.0TB と交換
  2. 開発機から 1.0TB のディスクを抜いて刺し、3.0TB の RAID 1 を VG に追加
  3. 開発機に 2.5TB、1.5TB を刺し、1.5TB RAID1 + 1.0TB にする
これも技術的には特に問題なし。mdadm, pvcreate, vgextend 等を使って追加します。開発機のほうも移動したディスクに cygwin の rsync で全コピーしてドライブレターを付け替えるだけで問題なく移行できました。

これにてストレージに関しては

Server      : RAID1 6.5TB
Dev Machine : RAID1 1.5TB + non-RAID 1.0TB

となりました。めでたしめでたし(?)