Monthly Archives: 8月 2013

リビジョン管理rcsのすすめ(xxx.conf.20130829とかはもう止めよう)

Pocket

 

一人だけで管理しているサーバの設定ファイルを更新するとき、皆さんはどのように管理しているだろうか。
私は以下のようにしていた。
例えば、httpd.confを2013/8/25に変更しようとするとき。

# vi httpd.conf
# cp -p httpd.conf httpd.conf.20130825

 

経験のある方はご存じだろうが、長い間これを続けると、ディレクトリが散らかって酷い事になる。

ではバージョン管理を導入すべきか?
でも、一人で管理しているサーバなのに、わざわざsubversionを入れる?それはちょっと。

というのが長らくの悩みであったのだが、実はrcsという簡便なリビジョン管理ツールがあることを知った。今さらではあるが。
しかし、これがまた実に快適であった。
快適すぎて、今ではどこのディレクトリでもRCSディレクトリ(後述)を掘ってしまうくらいになってしまった。

そんなRCSについて以下に記す。

RCSとは。

RCSとはRevision Control System
きわめて軽量単純なGNU製のリビジョン管理システムである。
一人で使う分には十分(いちおう、ロック機能はあるよ!)。
だいたいのUNIX系OSには最初から入っている。
FreeBSDはベースシステムに入っているので、インストール不要。これはポイント。
もちろんLinuxにも(Redhatの5にあることは確認)

 

コマンドの使い方を示す。FreeBSD環境下のもの。
Linux向けmanはこちら。
http://linuxjm.sourceforge.jp/html/GNU_rcs/man1/co.1.html

 

RCSのコマンド

使うコマンドはおおよそ以下のようなもの。
詳しくはman。

co - check out RCS revisions
ci - check in RCS revisions
rlog - print log messages and other information about RCS files
rcsdiff - compare RCS revisions

 

RCSへの登録

ためしに、/etc/rc.confを、RCSで管理してみる。
最初にやることはRCSに登録すること。
ci(check in)コマンドを使う。
ciにrc.confを渡してやるだけ。

初回は「ファイルの説明を入れろ」と聞いてくるので、”System Setting file”などと入れてみる。
ドット「.」を入れれば完了。

$ cd /etc
$ sudo ci rc.conf
Password:
rc.conf,v  <--  rc.conf
enter description, terminated with single '.' or end of file:
NOTE: This is NOT the log message!
>> System Setting File
>> .
initial revision: 1.1
done

 

最初のバージョンは1.1になる。

初回チェックインの注意

驚くことに、初めてチェックインするとファイルが消える。
代わりと言ってはなんだが、ファイル名末尾に「,v」と付いたファイルが現れる。

$ ls -l rc.conf
ls: rc.conf: No such file or directory
$ ls -l rc.conf*
-r--r--r--  1 root  wheel  353 Aug 25 12:50 rc.conf,v

 

RCSはそれぞれのファイルを、この「,v」ファイルで管理しているのである。
しかしrc.confが無くなられては困る。
そこでco(check out)コマンドにより、「,v」からrc.confを取り出す。

$ sudo co rc.conf
rc.conf,v  -->  rc.conf
revision 1.1
done
$ ls -l rc.conf*
-r--r--r--  1 root  wheel  156 Aug 25 12:55 rc.conf
-r--r--r--  1 root  wheel  353 Aug 25 12:50 rc.conf,v

 

並べてみると「,v」には管理情報が含まれているせいでサイズが少し増えている。

しかしちょっと待て。

「,v」が散らかる→RCSディレクトリで解決

新しいファイルをRCSに登録する都度、「,v」が増えていくのではたまらない。
しかし、そこはさすがに考えられていて、同じディレクトリにRCSというディレクトリがあれば、その下に「,v」を作ってくれる。
さきほど作ったrc.conf,vを消してから試してみる。

$ sudo rm rc.conf,v
$ sudo mkdir RCS
$ sudo ci ./rc.conf
./RCS/rc.conf,v  <--  ./rc.conf
(略)
initial revision: 1.1
done
$ ls ./RCS
rc.conf,v

 

と、ご覧の通り/etc/RCSの下に「,v」が作られる。
こうしておけば「,v」ファイルが散らかって困ることはない。
忘れずにチェックアウト。
RCS/rc.conf,vから取り出されていることが分かる。

$ sudo co rc.conf
RCS/rc.conf,v  -->  rc.conf
revision 1.1
done

 

ファイルの更新(チェックアウト)

今度はファイルを更新してみる。
修正したファイルをチェックイン(ci)するだけなのだが、それに先立つチェックアウト(co)の時に考慮すべきことがある。
それはファイルのロック。

単にcoしただけのrc.confのパーミッションを見てみると、読み取り専用(444)になってしまっている(本来は644)。

$ ls -l rc.conf
-r--r--r--  1 root  wheel  156 Aug 25 12:55 rc.conf

 

なにも無計画にしているわけではない。
「RCSで管理しているファイルを迂闊に書き換えないように」というRCS師匠のありがたい配慮である。
これを避けるには、ファイルのロックをしてからチェックアウトをすればよい。
coの際に-lオプション(lock)を与えるだけ。

$ sudo co -l rc.conf
Password:
RCS/rc.conf,v  -->  rc.conf
revision 1.1 (locked)
done
$ ls -l ./rc.conf
-rw-r--r--  1 root  wheel  156 Aug 25 12:56 ./rc.conf

 

(locked)という表示が増えている。
また、パーミッションも644になっている。
これでファイル変更の準備ができた。

 

ファイルの更新(チェックイン)

修正が済んだらチェックイン。
チェックアウトの時と同じように、ロックの考慮が必要。
端的に言えばロックを解除する。
ciの際に-uオプション(unlock)を与える。

$ sudo ci -u ./rc.conf
./RCS/rc.conf,v  <--  ./rc.conf
new revision: 1.2; previous revision: 1.1
enter log message, terminated with single '.' or end of file:
>> disable sendmail on boot
>> .
done
$

 

log message、つまり修正内容の記入が求められるので書き入れたのちドット「.」で終了。
そしてロック解除したために、再びファイルのバーミッションが444に戻っている。

$ ls -l ./rc.conf
-r--r--r--  1 root  wheel  283 Aug 25 19:29 ./rc.conf

 

履歴の確認

RCSで管理しているファイルに対しrlogを発行すると履歴が表示される。

$ rlog ./rc.conf

RCS file: ./RCS/rc.conf,v
Working file: ./rc.conf
head: 1.2
branch:
locks: strict
access list:
symbolic names:
keyword substitution: kv
total revisions: 2;     selected revisions: 2
description:
System configuration file
----------------------------
revision 1.2
date: 2013/08/25 10:29:49;  author: root;  state: Exp;  lines: +6 -0
disable sendmail on boot
----------------------------
revision 1.1
date: 2013/08/25 04:07:09;  author: root;  state: Exp;
Initial revision
----------------------------

=============================================================================

 

 

revisoin 1.2では9行追加されていることを示している。
デフォルトではタイムスタンプがUTC。
これは分かりにくいので、ローカルタイムで表示する。
そのためには-zLTを与える。

$ rlog -zLT ./rc.conf

RCS file: ./RCS/rc.conf,v
Working file: ./rc.conf
head: 1.2
branch:
locks: strict
access list:
symbolic names:
keyword substitution: kv
total revisions: 2;     selected revisions: 2
description:
System setting file
----------------------------
revision 1.2
date: 2013-08-25 19:29:49+09;  author: root;  state: Exp;  lines: +6 -0
disable sendmail on boot
----------------------------
revision 1.1
date: 2013-08-25 13:07:09+09;  author: root;  state: Exp;
Initial revision
----------------------------
=============================================================================

 

 

差分の確認

二つのバージョン間の差分を確認するには、rcsdiffを使う。

$ rcsdiff -r1.1 -r1.2 ./rc.conf
===================================================================
RCS file: ./RCS/rc.conf,v
retrieving revision 1.1
retrieving revision 1.2
diff -r1.1 -r1.2
6a7,12
>
> # kill sendmail
> sendmail_enable="NO"
> sendmail_submit_enable="NO"
> sendmail_outbound_enable="NO"
> sendmail_msp_queue_enable="NO"

 

 

特定のバージョンを取り出す。

coに-rオプションでバージョンナンバを指定する。
1.1を取り出したいなら-r1.1。

$ sudo co -r1.1 rc.conf
RCS/rc.conf,v  -->  rc.conf
revision 1.1
done

 

しかしこれでは手元にあるファイルが上書きされる。
都合が悪い場合には-pオプションを使う。
-pオプションは結果を標準出力に表示させるもの。

$ sudo co -p -r1.1 rc.conf > /tmp/rc.conf
RCS/rc.conf,v  -->  standard output
revision 1.1

 

ident文字列の埋め込み

ファイルを特定しやすくするための仕組みがident文字列。
ある文字列を埋め込んでおくと、RCSが自動的に置換・更新をしてくれる。
実際に見てもらった方が早い。

 

rc.confに埋め込んでみる。
ident文字列には何種類かあるが、ここでは「$Id$」を使う。

しかし、$Id$といきなり書いてはいけない。コメントとして埋め込もう。
すなわち、#のあとに続ける。
(同様に、たとえばxmlなら”<!–“と”–>”の間、というようにフォーマットに合わせたコメント文に埋め込むとよい)

rc.confの例

#$Id$
hostname="hogehoge"
keymap="jp.106.kbd"
ifconfig_em0="DHCP"
sshd_enable="YES"

 

これをチェックインすると、自動的に以下のように変換してくれる。

$ head -1 /etc/rc.conf
#$Id: rc.conf,v 1.2 2013/08/24 10:52:27 root Exp $

 

これは便利である。
実はこの文字列、よく見かけたのだが、やっとその秘密が分かった。

しかしタイムスタンプはUTCである。
チェックインのときに-zLTと指定すればローカルタイムで置換してくれる。

$ sudo ci -u -zLT ./rc.conf
./RCS/rc.conf,v  <--  ./rc.conf
new revision: 1.4; previous revision: 1.3
enter log message, terminated with single '.' or end of file:
>> update timestamp from UTC to LT
>> .
done
$ head -1 ./rc.conf
#$Id: rc.conf,v 1.4 2013-08-24 20:18:36+09 root Exp $

 

ident文字列のちょっとしたノウハウ

ident文字列の場所はどこでもよい。
しかし、1行目か2行目がよいでしょう。

ident文字列はファイルのIDとして埋め込んでいる。
IDの場所がバージョンごとに違うと、のちのち差分を確認するときに見にくくなってしまうから。

 

No tags for this post.

FreeBSD(FreeNAS)にPlex Media Serverをインストール

Pocket

Plexというメディア共有ソフトウェア群がある。
Plex Media ServerとPlex Media Clientの二つから成っている。

Plex Media Serverというサーバを立てておけば、Plex Media Centerのインストールされた端末から動画や音楽を視聴することができる。

もっと具体的に言うと、自宅でPlex Media Serverを立てておけば、宅内はもちろん、外出先のモバイル端末からでもメディアへアクセスできる。

動画や音楽をため込んでいるNASにPlex Media Centerをインストールできればとても便利というわけ。
クライアントは、Windows, Linux, iOS, Android向けに用意されており、PS3, XBOX360はデフォルトで対応。
しかしiOSやAndroid向けのアプリは\450と、なかなかのお値段であって、そこまでして外出先で見たいか?と一考する余地はあると思う。
私も買ってません。

(追記)2015/8 にjailにインストールしたときの顛末はここ

Plex Media ServerがFreeBSD/FreeNASに対応

Plex Media Serverは長らくWindows/OS X/Linuxにしか対応していなかったのだが、近ごろFreeBSDにも対応した。
FreeBSDに対応ということはつまりFreeNASにも対応したということである。
すなわち冒頭で書いたような、「NASに動画や音楽をため込んで、しかもNASに動画共有させる」事が出来る。

以下、FreeBSDでのインストール、設定方法を示す。

インストール

FreeBSD対応がなされたばかりであるため、なるべくportsから、それも最新のportsからインストールすることを勧める。

いずれにしても、Plex Media Serverはクローズドなので、大したコンパイル時間は発生しない。

$ cd /usr/ports/multimedia/plexmediaserver
$ sudo make install clean

 

すぐ終わるはず。

起動

/usr/local/etc/rc.dに起動スクリプトがインストールされる。
サーバ起動時にPlex Media Serverも起動するには、/etc/rc.confに以下の一行を追加する。

 plexmediaserver_enable="YES"

 

ただ今回は実験のため以下のようにして起動。

$ sudo service plexmediaserver onestart
$
$ service plexmediaserver onestatus
plexmediaserver is running with pid: 789
$

 

設定

plex media serverを動かしているサーバにブラウザで繋ぐ。
サーバが192.168.1.1なら以下のように。

http://192.168.1.1:32400/manage/index.html

こんな画面になるはず。
plex0010
まあ、agreeですな。

plex0020

plex0030

開始。

plex0040

Friendly Nameを入れろと言われる。
Friendly Nameとは、クライアントからPlex Media Serverを見つけやすいように付ける名前。たとえばPlex Serverとか。
ブランクのままにすれば、サーバのホスト名がそのまま使われる。

あとはまあ、言われたとおりに。

plex0050

plex0060

 

myPlexアカウントを入れろ、と言われる。
外出先のモバイル端末からPlex Media Serverにアクセスするなら、Plexのサイトに行って作ったアカウントをここに入れる。
自宅内だけで共有するなら、skipしてもOK.

plex0070

 

アクセス

Plex Media Serverにアクセスする方法はいくつかある。

  1. Plex Media CenterをインストールしたWindows, OS X, Linuxからアクセス
  2. PlexをインストールしたiOS, Androidからアクセス
  3. PS3, XBOX360からアクセス
  4. ブラウザからアクセス

ここでは4の方法だけ示す。

ブラウザでのアクセスには「:32400/web/index.html」へ繋ぐ。
サーバが192.168.1.1なら以下のように。

http://192.168.1.1:32400/manage/index.html

たとえばps3だと、XMCのフォト、ミュージック、ビデオにサーバが表示されるようになるので、そこから。
 

ssmtpでUnable to locate smtp.gmail.comが表示される。

Pocket

ここで書いたように、自宅サーバーのroot宛メールをすべてgmailに転送しているのだが、ある日気が付くと、以下のようなメッセージがログに表示されている。

 

sSMTP[1044]: Unable to locate smtp.gmail.com

 

気が付かなかったくらいだから、メールの転送に問題はない。
ないのだけど気持ち悪いので対策しよう。
原因はmailグループにrootのないこと。
だから単純に/etc/groupでmailにrootを加えればOK。

mail:*:6:clamav,root

 

参考
Forwarding Root’s Mail to a Gmail Account using SSMTP

No tags for this post.

[VM] VMWareのイメージをVirtualBoxで読み込むには(OVF経由での読み込み)

Pocket

 

VMware Playerにはsnapshot機能がない。
仮想マシンを使う目的の一つは、本番マシンではできない、いろいろな実験をすることだ。
snapshot機能がないと実験が途端に面倒になる。

こればかりはどうしようもない。仕方がないので、手元の仮想マシンはすべてVirtualBoxに移行する。
そのときのメモ。

全体の流れ

  1. VMWare Player付属のツールでOVFに変換する。
  2. それをVirtualBoxでインポート。

OVFとはOpen Virtualization Formatのこと。詳しくはWikipedia

VMWare Player付属のovftool.exeについて

VMWareのイメージをOVFフォーマットに変換するツール。
コマンドプロンプトで使う。
書式は以下の通り。

ovftool <変換元イメージ> <変換先イメージ>

実際にやってみる。

OVFへの変換。

ovftool.exeはVMWare Playerのインストールフォルダにある。
作業はコマンドプロンプトで行う。
いちいちcdしていくのが面倒なので、以下のようにしてコマンドプロンプトを開く。

convert001
convert002

そして変換元ディスクイメージの指定も面倒なので、いったんエクスプローラに戻り、パスを取得する。

convert003

コマンドプロンプトに戻って貼り付け。その後、変換先イメージの場所を指定。

convert004
convert005

VirtualBoxでのインポート

大して難しいことはない。
が、注意点が一つだけ。

OVFファイルのあるフォルダに、拡張子.mfを持つファイルがある。
VirtualBoxでのインポート前に削除しておくこと。
.mfとはManifestファイルであり、これがあるとインポートに失敗する

convert0071

後は素直に。英語ならpretty straightforwardとかいうでしょうか。

convert006
ファイル→仮想アプライアンスのインポート。

convert007
変換してできたovfを選ぶと、設定が表示される。
メモリ256MBってなんだよ…。あとで設定を変えよう。

convert008

convert009
できあがり。
このあと設定を変えればVirtualBoxで使えます。
なお、OVFファイルは捨ててしまっても問題なし。

No tags for this post.

[Hadoop] 擬似分散モードから完全分散モードへ(データノードの追加)

Pocket

Hadoopへのノードの追加

hadoopの長所は、処理量に応じて簡単にスケールできる点にある。
処理がおっつかなくなってきたら、データノードを追加するだけ。
擬似分散モードから完全分散モードへの移行は、データノードの追加と同じ。
もう少し詳しく言うと、最初の1台をnamenode/jobtrackerのままにして、datanode/tasktrackerを追加する。
※FreeBSDで、hadoop-1.0.0です。

背景

namenode, datanodeはHDFSのノード種別を表し、namenodeはファイルのメタデータを扱い、datanodeは実データを扱う。
namenodeはhadoopクラスタに原則1台。datanodeは1台以上必要。

jobtracker, tasktrackerはMapReduceでのノード種別を表し、jobtrackerは作業の分担を、tasktrackerは作業の実施を行う。
jobtrackerはhadoopクラスタに原則1台。tasktrackerは1台以上必要。

hadoopクラスタに参加しているノードは、4つの役割のいずれかを担う。複数の役割をこなすのも可。
ただしdatanodeとtasktrackerは必ずセット。
イメージを示す。

hadoopmode

 

設定ファイル

再掲になるが。

どのノードがnamenodeかを指定するのは、core-site.xml 。
どのノードがjobtrackerかを指定するのは、mapred-site.xml 。
どのノードがdatanode/tasktrackerかを指定するのは、slaves 。

擬似分散モードでは、以上3つのファイルに1ノードしか書かれていなかった。

ノードを追加するなら、slavesにdatanode/tasktrackerを追記すればよい。
擬似分散モードの状態からjobtrackerを分離するには、mapred-site.xmlを書き換えればよい。
擬似分散モードの状態からnamenodeを分離するには、core-site.xmlを書き換えればよいけど、HDFS上にすでにファイルを置いている状態でそんなことするとファイルが吹き飛ぶので止めよう。

そしてこれら設定ファイルは、クラスタ内のノードで同じものを使う。

作業の流れ。

datanode/tasktrackerを追加してみる。

擬似分散モードを仮想マシンで動かしている場合には、それをまるまるコピーしてしまえばよい。
私の場合は、ESXi上でHadoop環境を作ったので、それをコピーし、別マシンのESXiに移し替えた。
もちろんホスト名は別のものにする。

ESXiなどを挟まない場合にはもう一度セットアップ。
ほんとに面倒くさいので、chefやらpuppetなどを使うことになるでしょう。

なお、ESXiは使わない方がパフォーマンスは良い。これは当たり前。

追加ノードの注意点

便宜上、擬似分散モードを動かしたノードをoriginal、追加するノードをaddとする。
addを追加するときの注意点は以下の通り。

/etc/hostsの設定。

original, addの/etc/hostsには、original, addの名前解決ができるようにしておくこと。

時刻同期

original, addで時刻を合わせておくこと。

slavesへの追記

original, addそれぞれでslavesにaddと追記しておく。

SSHログインの確認

originalからaddへsshログインできることを確認しておく。
datanode/jobtrackerの制御はsshでされるため。

replication数の変更

HDFS上でデータのコピーをどれだけ作成するかの設定。
擬似分散ではreplicationを1にしていた。
せっかくなのでこれを2に変更する。
デフォルトは3。
datanodeをさらに増やしたなら、ここの上限をとりあえず3として増やそう。

ノード追加の反映

ノードの追加が初めてならstop-all.shで止めて、start-all.shでまるまる再起動するのがいいでしょう。

当然ながら、hadoop上で何かしらの作業が動いていたらやり直しになってしまう。
通常は、namenodeでhadoop dfsadmin -refreshNodesを実行。
さらにhadoop dfsadmin -reportで確認する。

[hadoop@vfbsd ~]$ hadoop dfsadmin -refreshNodes
[hadoop@vfbsd ~]$ hadoop dfsadmin -report
Configured Capacity: 96683511808 (90.04 GB)
Present Capacity: 57517137920 (53.57 GB)
DFS Remaining: 28587847680 (26.62 GB)
DFS Used: 28929290240 (26.94 GB)
DFS Used%: 50.3%
Under replicated blocks: 5
Blocks with corrupt replicas: 0
Missing blocks: 0

-------------------------------------------------
Datanodes available: 2 (2 total, 0 dead)

Name: 192.168.200.1:50010
Decommission Status : Normal
Configured Capacity: 65501978624 (61 GB)
DFS Used: 28920520704 (26.93 GB)
Non DFS Used: 35444080640 (33.01 GB)
DFS Remaining: 1137377280(1.06 GB)
DFS Used%: 44.15%
DFS Remaining%: 1.74%
Last contact: Mon Aug 12 22:19:15 JST 2013

Name: 192.168.200.100:50010
Decommission Status : Normal
Configured Capacity: 31181533184 (29.04 GB)
DFS Used: 8769536 (8.36 MB)
Non DFS Used: 3722293248 (3.47 GB)
DFS Remaining: 27450470400(25.57 GB)
DFS Used%: 0.03%
DFS Remaining%: 88.03%
Last contact: Mon Aug 12 22:19:17 JST 2013

 

上記の例で言えば、192.168.200.100が追加したdatanode。
使用量がまだ8MBしかないことが分かるだろうか。
replication数を2にしたので、ゆくゆくは192.168.200.1と同じ程度の使用量になるはず。
しばらく放置が必要。
(いま気がついたけど、”Under replicated blocks”、つまり所定のreplicationに満たないblockの数が5…)

擬似分散→擬似分散+1の効果

効果は劇的。
もともと2時間半かかっていたものが1時間半に短縮できた。
下記はtimeの結果。上が擬似分散、下が擬似分散+1。

real    147m34.258s
user    0m6.835s
sys     0m2.233s

real    82m59.557s
user    0m5.624s
sys     0m1.604s

ああもっとdatanode増やしたい。

関連エントリ

[FreeBSD] Hadoopのportsからのインストール
[FreeBSD] portsのHadoopで分散(x-distributed)モードを動かす準備
[Hadoop]Hadoop 擬似分散(Psuedo-distributed)モードの設定
[Hadoop]擬似分散モードで実験

No tags for this post.

[hadoop] hadoop streamingでファイルを分割させないためには。

Pocket

※hadoop-1.0.0です。

hadoop streamingで困ること。

作業データ(たとえばログ)を与えると、Hadoopはまず分割をする。
分割されたものはinput splits, あるいは単にsplitsと呼ばれる。
splitsのサイズはデフォルトで64MBytesだ。
Hadoop(JobTracker)は作業ノード(TaskTracker)にsplitsを割り当てる。
作業ノードはsplitsに対してmapタスクを行う。

なお、作業ノードの割り当てにあたっては、splitsの物理的な場所との近さも考慮される。
要するにsplitsの実データが置かれている作業ノードが選ばれる。

これは素晴らしい仕組みなのだが、困ることもある。
例えば以下のような場合。

 

  • ファイルの冒頭にあるヘッダが処理に必要な場合。
    →分割されると、ヘッダのないsplitsが出来てしまう。
  • ログ上の2点間の時間差分を知りたい場合。
    →2点の間で分割されると計算できない。

回避策

下記の通り。

How do I process files, one per map?

つまり、hadoopへの入力に、いきなり「ファイルの内容」を送り込むのではなく、「ファイルのリスト」を渡す。
ファイルのリストだから、いくら分割してもファイル自体は分割されない。
なるほど。

 

回避策とはいっても。

しかし、この場合mapper側に工夫が必要になる。

通常であれば、標準入力からファイルの中身がドバドバやってくる。
PythonだろうとRubyだろうとstdinをforループで読むだけ。
楽ちん。

ところがこの回避策だと、ファイルリストが入力されるわけだから、ファイルを開くことから始めなければならない。
そしてファイルを開くには、mapperスクリプト内で「hadoop dfs -cat <ファイル>」しないといけない
(ファイルがHDFSにあるとして)。

それも面倒だし、加えて、無駄な通信が発生する可能性がある点も懸念。

先述の通り、Hadoopは作業の振り分けにあたって、実データに近い作業ノードを選ぶ。
しかしファイル「リスト」を渡すということは、ファイル「リスト」と作業ノードの近さは考慮してくれるものの、リストに書かれたファイルと作業ノードの近さは考慮外になるということ。

つまり、作業ノードと実際のデータのある場所が一致するとは限らない。
一致しなければ、作業ノードはデータを別ノードからダウンロードしなければならない。

ノード間通信はコスト高なのでなるべく避けよう、というHadoopの思想にはそぐわない。

mapperの例

しかし選択肢はないので進める。
以下はpythonでファイルリストを受けた場合の処理例。
作業データはHDFS上にあるので、subprocessで「hadoop dfs -cat <ファイル>」する。

#!/usr/bin/env python
# -*- coding: utf-8 -*-

import sys os subprocess

for line in sys.stdin:

        line.strip("\n")
        filename = line

        cat = subprocess.Popen(["hadoop","dfs","-cat",filename],stdout=subprocess.PIPE)

        for logline in cat.stdout:
		#処理
		print line

 

大したことではないけれど、下記のように必ずテストしてからhdoopに投入すること。

$ cat filelist.txt | mapper.py | sort | reducer.py

hadoopは自前mapper, reducerが失敗しても、エラー内容を教えてはくれないので(たぶん)。

注意点

HDFS上にファイルを置いている場合、絶対パスで指定すること。
相対パスではダメだった。
また、HDFSでは「/user/hadoop/input」のように、「user」であって「usr」でないことに注意。

作業データがローカルディスクにあるなら、hadoop dfs -getとか。
しかしそうするとすべての作業ノードがローカルディスクにアクセスしてくることになる。
それは避けたいので、HDFS上に置いた方がよいでしょう。

No tags for this post.

Windows Update関連メモ(自分のタイミングでWSUSからパッチダウンロード)

Pocket

Windows Updateはすごく重い。
なにか作業している裏で走られるとストレスだ。
加えて「パッチを入れろ入れろ」と鬱陶しいことこの上ない。
会社のPCだったりすると問答無用でインストールまでされて、思わぬ瞬間に再起動されることだってある。

問題は何かといえば、こちらの意図しないタイミングでHDDをガリガリやられたり再起動されることだ。
ということで、自分でWindows Updateを走らせる。
会社のPCだと、パッチはWSUS経由で、通常のWindows Updateからではインストールできない事がある。
そこでwuaucltコマンドを使う。

Windowsの更新があるか確認するには、以下のコマンドを実行する。

wuauclt /detectnow

 

WSUSサーバ経由でWindows Updateしてるなら、以下のようにすると、サーバ側Cookieを破棄させる。詳細は後述のリンク。
※オプションの順番はこの通りでないとダメ。

wuauclt /resetauthorization /detectnow

 

さらにさらに、クライアントのWindows Updateサービスを再起動すればより確実に。

net stop wuauserv
net start wuauserv
wuauclt /resetauthorization /detectnow

ログは以下の場所に。

%systemroot%\WindowsUpdate.log

 

参考
コマンド ライン オプションを使用して自動更新の動作を調整する

No tags for this post.

[Hadoop] $HADOOP_HOME is deprecatedの対処

Pocket

“$HADOOP_HOME is deprecated”が鬱陶しい。

※本記事ではhadoop 1.00を使ってます。

hadoopを実行すると”$HADOOP_HOME is deprecated”と表示されることがある。
HADOOP_HOMEはもう使われなくなり、代わりにHADOOP_PREFIXにするよう推奨されている。

これを抑制するには、以下二つのうち、いずれかをすればよい。

”$HADOOP_HOME is deprecated”を抑制するには。

  1. HADOOP_HOMEをHADOOP_PREFIXに置き換える。あるいは。
  2. HADOOP_HOME_WARN_SUPPRESS=YESと宣言する。

hadoopのバージョンアップをするつもりがないなら、②が楽でしょうかね。
具体的には、hadoopを使うユーザの.profileあたりで宣言しておけばOK。

エラーメッセージの原因

なお、HADOOP関連のスクリプトを当該メッセージでgrepすると、hadoop-config.shに以下の記載がある。

hadoop-config.sh

if [ "$HADOOP_HOME_WARN_SUPPRESS" == "" ] && [ "$HADOOP_HOME" != "" ]; then
  echo "Warning: \$HADOOP_HOME is deprecated." 1>&2
  echo 1>&2
fi

つまりHADOOP_HOMEに何か設定されていれば、メッセージを表示する。
しかし、HADOOP_HOME_WARN_SUPPRESSに何か設定されていれば、そのメッセージを抑制する、というわけ。
上記ではHADOOP_HOME_WARN_SUPPRESS=”YES”にしているが、実際のところ中身はなんだってよい。

No tags for this post.

仮想マシンイメージの変換について

Pocket

 

VMWare PlayerのイメージをESXi用に変換するには

VMWareが提供しているコンバータを使う。
以下、まとめ。

なお、動機としては、「手元のVMware Playerで手軽にいろいろ検証をして、出来上がったものをESXiに移す」ことが出来るようにしたい、というもの。
しかし最後に書くように、変換してもVMware Player上と同じようにESXi上でも動くとは限らない。
可能なら最初からESXi上で検証したほうがよいようだ。

VMware vCenter Converterとは。

 

「VMware vCenter Converter は、物理マシンから仮想マシンへの変換のほか、仮想マシン フォーマット間の変換を自動化および簡素化します。 VMware vCenter Converter では、直感的なウィザード形式のインターフェイスを使用して、物理マシンを仮想マシンに変換できます。」

vmware.comを見ると、「物理マシンから仮想マシンへ変換」なんてすごい事が書いてある(2013/8/1現在)。

さらにvmware.comから引く。

VMware vCenter Converter は、さまざまなハードウェア上で実行でき、最も広く使用されている Microsoft Windows と Linux オペレーティング システムの各バージョンに対応します。 この堅牢なエンタープライズ クラスの移行ツールにより、次のことが可能になります。

システム停止やダウンタイムなしで、ローカルおよびリモートの物理マシンを迅速かつ確実に仮想マシンに変換できます。
統合管理コンソールと直感的な変換ウィザードにより、複数の変換を同時に実行します。

Microsoft Hyper-V、Microsoft Virtual PC、Microsoft Virtual Server など、サードパーティの仮想マシン フォーマットのほか、Symantec Backup Exec System Recovery や Norton Ghost など、物理マシンのバックアップ イメージを VMware の仮想マシンに変換します。

入手

http://www.vmware.com/jp/products/converter

 

手順

ここでは5.0.0ビルド 470252を使用している。

メニューから変換を選ぶ

  1. 「ソースのタイプを選択」→「VMware Workstation またはその他の VMware 仮想マシン」を選ぶ
  2. 仮想マシンファイルで変換したいvmxファイルを選ぶ。
  3. 「ターゲットのタイプを選択」→「VMware Infrastructure 仮想マシン」
  4. VMware Infrastructure サーバの詳細で、ESXiマシンの詳細を入れる。

ESXi上での名前を決めて、あとは適当に。
100MのEternetで2GBytes程度の仮想イメージを転送したところ、10分強かかった。

また、ESXi上で起動するときもいくつか聞かれるが、それも適当に。

 

愚痴

本記事が、とてもやる気のない感じになっているのは、VMware Playerで問題のなかった仮想マシンが、ESXiに移したら途端に調子が悪くなったから。
具体的には、FreeBSD 9.1-RELEASE(amd64)をESXiに移したら、ira16から割り込みの嵐が発生してまともにパフォーマンスがでなかった。
新規で同じOSを入れたら事象発生せず(vmstat -iを見たら割り込みを発生させたデバイスがない)。
ぐぐっても解決策なし。
がっかり。

No tags for this post.

[FreeBSD] sendmailをさらに黙らせるには

Pocket

 

FreeBSD起動時のsendmailを止める方法はこの通り
これで確かに止まる。
しかしFreeBSDにはcronでmailサーバの状況を調べるスクリプトが動いていて、明示的に指定しない限り毎日毎日mailqの情報とかを送り付けてくる。

たとえばこんな感じ

Mail in local queue:
mailq: Mail queue is empty

Mail in submit queue:
mailq: Mail queue is empty

Security check:
    (output mailed separately)

Checking for rejected mail hosts:

 

邪魔なのでこれを止める。
方法は簡単。/etc/periodic.confに以下を追加するだけ。

daily_clean_hoststat_enable="NO"
daily_status_mail_rejects_enable="NO"
daily_status_include_submit_mailq="NO"
daily_submit_queuerun="NO"

 

 

 

No tags for this post.