Monthly Archives: 1月 2014

FreeBSDへのMATEインストール

Pocket

 

FreeBSDにMATEをpkgngでインストールしたので経緯を示す。
「メイト」って読んでたけどマテ茶のマテなのね。
私がFreeBSDをインストールしているマシンはやや古めで、GNOME3だと荷が重い。
そこでGNOME2後継のMATEにした。
デザインなど、やっぱり物足りない点はあるけれど満足している。
デスクトップ用途としてはそんなに使わないしね。
(追記)
この記事は一ヶ月ほどまえに書いたものです。
FreeBSD 10.o-RELEASEが公式アナウンスされた1/21(JST)の時点では、公式pkgリポジトリにmateが、加えてxorgすらもありません。
pkgリポジトリは一週間に一回の頻度で更新されますが、その都度全体的な整合性が保証されるわけではありません。
したがって、あるpackageがリポジトリに現れたり消えたりすることは、ままあることです。
mateやxorgなどの大量に依存を抱えるソフトウェアをすべてpkgで扱うのは、現時点では難しいようです。
(追記ここまで)
(2014/1/30さらに追記)
現時点でpkgにmateはあるけれども、今度はavahi-daemonがコアダンプするとかもうね…。
(追記ここまで)

MATEとは

Wikipediaから引用

MATE (マテ、スペイン語発音: [ˈmate])はGNOME 2のコードからフォークされたデスクトップ環境である。

従来のデスクトップメタファーをGNOME Shellによる新しいインターフェースで置き換えたGNOME 3はLinuxコミュニティの一部から批判を受けた。多くのユーザーは新しいGNOMEを受け入れることを拒否し、GNOME 2の開発を継続する者を求めた。MATEプロジェクトはあるArch Linuxユーザー[3]によってこのタスクを行うために立ち上げられた。

MATE(wikipedia)
http://ja.wikipedia.org/wiki/MATE_%28%E3%83%87%E3%82%B9%E3%82%AF%E3%83%88%E3%83%83%E3%83%97%E7%92%B0%E5%A2%83%29

公式サイトはこちら。
MATE(公式)
http://mate-desktop.org/

 

FreeBSDへのインストールについて

pkgngに用意されているので、コマンド一発でインストールできる。

ただ、注意点が一つ。
mateにはログインマネジャーが付属しない。
おすすめはslim。xdmでも可。
gdmはおすすめしない。

理由。
gdmはGNOMEアプリケーションだから。(せっかくGNOMEからフォークしてるのに)
以下にmateをFreeBSDにportしてくれた人のコメントを引用。

Q: Why you won’t check on GDM?
A: Because it’s a GNOME applications and I do not want to install any
extra dependency. :-) But if MATE folks fork the GDM and yes I will
work on it.

引用元
http://lists.freebsd.org/pipermail/freebsd-gnome/2012-July/027576.html

インストール

Xorgはインストールされている前提。
$ sudo pkg install mate とするだけ。
ログを取り忘れたので出力例は割愛。

slimもインストールする。
slimは本体の他にテーマもインストールする。
-fで調べてみると以下の様な結果。

$ pkg search -f slim-1.3.5_3
slim-1.3.5_3
Name : slim
Version : 1.3.5_3
Origin : x11/slim
Architecture : freebsd:9:x86:32
Prefix : /usr/local
Categories : x11
Licenses : GPLv2
Maintainer : henry.hu.sh@gmail.com
WWW : http://slim.berlios.de/
Comment : Graphical login manager for X11, derived from Login.app
Options :
PAM : on
(略)Description :
SLiM is a desktop-independent graphical login manager for X11, derived from Login.app by Per Liden.
It aims to be light and simple, although completely configurable through
themes and an option file; is suitable for machines on which remote login functionalities are not needed.
WWW: http://slim.berlios.de/

インストール。

$ sudo pkg install slim
Updating repository catalogue
The following 1 packages will be installed:

Installing slim: 1.3.5_3

The installation will require 467 kB more space

257 kB to be downloaded

Proceed with installing packages [y/N]: y
slim-1.3.5_3.txz 100% 258KB 257.9KB/s 97.9KB/s 00:01
Checking integrity... done
[1/1] Installing slim-1.3.5_3... done
*************************************************************************

Thanks to Nikos Ntarmos, it is now possible to start slim from /etc/ttys.
Please see /usr/local/etc/rc.d/slim for instructions on how to do that.

テーマもインストール

$ pkg search -f slim-themes-1.0.1
slim-themes-1.0.1
Name : slim-themes
Version : 1.0.1
Origin : x11-themes/slim-themes
Architecture : freebsd:9:x86:32
Prefix : /usr/local
Categories : x11-themes
Maintainer : rea@FreeBSD.org
WWW : http://slim.berlios.de/themes01.php
Comment : Theme pack for SLiM login app
Options :
ALL_THEMES : on
ARCHLINUX_SIMPLE: on
CAPERNOITED : on
DEBIAN_MOREBLUE: on
FINGERPRINT : on
FLAT : on
FLOWER2 : on
FREEBSD : on
GENTOO_SIMPLE : on
GNEWSENSE : on
LAKE : on
LUNAR_LINUX : on
MINDLOCK : on
PARALLEL_DIMS : on
RAINBOW : on
REAR_WINDOW : on
SCOTLAND_ROAD : on
SUBWAY : on
WAVE : on
ZENWALK : on
Flat size : 5.33MiB
Pkg size : 4 MB
Description :
Theme pack for the SLiM X login application.

WWW: http://slim.berlios.de/themes01.php

 

$ sudo pkg install slim-themes-1.0.1

Updating repository catalogue
The following 1 packages will be installed:

Installing slim-themes: 1.0.1

The installation will require 5 MB more space

4 MB to be downloaded

Proceed with installing packages [y/N]: y
slim-themes-1.0.1.txz 100% 5021KB 279.0KB/s 311.5KB/s 00:18
Checking integrity... done
[1/1] Installing slim-themes-1.0.1... done

 

設定

以下メールの手順に沿うだけ。とっても簡単。
http://lists.freebsd.org/pipermail/freebsd-gnome/2012-July/027575.html

具体的には/etc/rc.confの修正と、ホームディレクトリ.xinitrcの修正。
/etc/rc.conf

dbus_enable="YES"
hald_enable="YES"
avahi_daemon_enable="YES"
avahi_dnsconfd_enable="YES"
slim_enable="YES"

dbusからavahiまでの順番は重要。入れ替えないこと。
gdm_enableがあれば削るかコメントアウトすること。

~/.xnitrc

exec mate-session

再起動すればおしまい。

 

 

[メモ] FreeBSD 10.0 で libc_nonshared.aが見つからないときには

Pocket

10.0-RCxから10.0-RELEASEへの移行期に下記のようなエラーに遭遇した場合。

/usr/bin/ld: cannot find /usr/lib/libc_nonshared.a
cc: error: linker command failed with exit code 1 (use -v to see
invocation)

以下のようにしてlibc_nonshared.aをインストールすれば回避できる。

# cd /usr/src/lib/libc_nonshared
# make && make install && make clean

srcが無いなら、以下からダウンロードする。(i386の例)
ftp://ftp.iij.ad.jp/pub/FreeBSD/releases/i386/10.0-RELEASE/src.txz

src.txzを展開して(依存があるから全部展開するのがよいあるね);

$ tar xvzf ./src.txz
x usr/src/
x usr/src/share/monetdef/sr_YU.ISO8859-2.src
x usr/src/share/monetdef/es_ES.UTF-8.src
(略)

ディレクトリに降りてmake install clean;

$ cd usr/src/lib/libc_nonshared/
$ sudo make install clean
Warning: Object directory not changed from original /usr/home/vanilla/files/10.0/usr/src/lib/libc_nonshared
cc  -O2 -pipe  -fpic -DPIC -fvisibility=hidden(略)

きちんとありますな。

$ ls -la /usr/lib/libc_nonshared.a
-r--r--r--  1 root  wheel  16658  1月 28 23:22 /usr/lib/libc_nonshared.a

終わったらsrcは消してOK。

zfs snapshotの差分send/recvについて

Pocket

 

zfs snapshotの差分send/recvについて

zfsのバックアップは、snapshotを撮っておいて、自ホストの別zpool、あるいは他ホストの別zpoolに移すことで行われる。
バックアップは定期的に行われるものであるが、ではそのsnapshotを移す際、毎回毎回まるまる送っていたんでは帯域も時間もディスク寿命も無駄である。
zfsはそこも考慮していて、差分だけを送ればいいようにincrementalオプションがきちんと用意されている。

書式は以下の通りsendに-iオプションを与えるだけ。
(recv側にはsnapshotAがすでに転送済みの前提)

zfs send -i <snapshotA> <snapshotB> | zfs recv <target pool>

 

よろしい。では次回からは…?

ふむ。
では二回目以降はどうするのだろう?
上記の書式例でsnapshotCが出来たらどうするのだろう?
まさかsnapshotA, B, Cを全部並べるのか?と思ったけどそれは間違いで、snapshotB, Cだけでよい。

recv側にはsnapshotAがすでにあるとき。
zfs send -i snapshotA snapshotBでAとBの差分のみが送られる。
つぎにzfs send -i snapshotB snapshotCでBとCの差分のみが送られる、というわけ。

では早速試してみる。が。

「転送先が更新されているため差分を転送できません」

こんなエラーがでる。

cannot receive incremental stream: destination warehouse/dir has been modified
since most recent snapshot

まあ文字通りなんですが。
バックアップ用の転送先が更新されるのはなぜか分からないが(atimeだろうか?)。

こういう場合には、recv側で-Fオプションを与えればよい。
-Fオプションによりrecv側は最新snapshotに強制rollbackして、それからsnapshotを受け取る。

下記の例だと、recv側は@20131226にいったんrollbackしてから受け取る。

$ sudo sh -c "zfs send -i vault/chamber@20131226 vault/chamber@2014010
2 | zfs recv -F warehouse/chamber"

 

atimeのoff

recv側がなぜ更新されてるのか、atimeが怪しいのでoffにしておく。
recv側のzpoolに対してzfs set atime=offするだけ。
(zpoolから切り出されたzfsすべてに適用される)

$ zfs get atime warehouse
NAME       PROPERTY  VALUE  SOURCE
warehouse  atime     on     default
$ sudo zfs set atime=off warehouse
$ zfs get atime warehouse
NAME       PROPERTY  VALUE  SOURCE
warehouse  atime     off    local
$ zfs get atime warehouse/chamber
NAME               PROPERTY  VALUE  SOURCE
warehouse/chamber  atime     off    inherited from warehouse

 

Windows7でsambaのファイルがうまく開けない件について(oplocks死すべし)

Pocket

昨年あたりからWindows XPのサポート終了にともない、Windows 7へクライアントOSを移す企業が多い。
私の仕事PCも過日、ついに7に変更された。
さすがに色んなところが改善されていて使いやすくなっているのだが、なぜかSambaに置いてあるファイルが壊れたり、誰も開いていないはずなのに読み取り専用でしか開けない事象が頻発した。
特に共有設定したOfficeドキュメントで顕著。

しばらく悩んでいたのだが、Sambaのログにoplocks failedという記録を見つけて(おそらく)対処方法が分かった。
以下に示す。
Sambaのバージョンは3.6.22である。

結論

smb.confのglobalセクションに以下を書け。

oplocks = No
blocking locks = No

 

ネタ元

ネットを渉猟したところ、やはりOplocksの評判はあまりよくない。

以下のホワイトペーパーが分かりやすかった。
Oplocksとread cachingが原因と断定している。

Opportunistic Locking and Read Caching on Microsoft Windows Networks
http://www.dataaccess.com/whitepapers/opportunlockingreadcaching.html

先に進む前にプロトコルとしてのSMBでいくつか確認を。

 

SMB(プロトコル)のバージョンについて

Windowsファイル共有で使われるプロトコルSMBは、Vistaでバージョン2, 7でバージョン2.1になった。
Oplocksとread cachingもバージョン2以降で追加、あるいは強化されている。
詳細は以下。

SMB の新機能
http://technet.microsoft.com/ja-jp/library/ff625695.aspx
SMB1⇒2⇒2.1への変化と新機能
http://blog.goo.ne.jp/mito_and_tanu/e/10c47629fbb7e7d3d73cbd54a1a9f28d


Oplocksとは

ネットワークの効率化を狙う、Windows固有の機能。
複数のプロセスが同じファイルをロックでき、なおかつクライアントがデータをキャッシュできる。

Chapter 17. File and Record Locking
http://www.samba.org/samba/docs/man/Samba-HOWTO-Collection/locking.html
http://www.samba.gr.jp/project/translation/Samba3-HOWTO/locking.html

Read Cachingとは

Oplocksの一機能。クライアント側でのデータキャッシュ。
クライアントがローカルでデータをキャッシュする目的は、ネットワーク越しの書き込み回数を減らすこと、ひいてはネットワークの効率化のため。
ファイルの同じ部分(the same region)に対する書き込みをまとめて、一回で済ませる。

Oplocksの危険性

Oplocksが狙い通りに動けば、目的通りネットワークの効率化が図られる。
問題なのはネットワークに何か問題が起こり、キャッシュが適切にフラッシュされない場合。ともするとファイルの破壊を引き起こす。
とくにデータベースが危険。
以下のリンクに詳細が。
本記事の末尾に私訳を付す。

Locks and Oplocks
http://www.samba.org/samba/docs/using_samba/ch08.html

対策:Oplocksを無効にしろ

ここまで分かれば、対策は簡単。
Oplocksを無効にすればよい。
無効にする方法には、サーバ側での方法、クライアント側での方法がある。
クライアントと言っても、たいていはWindowsであろうが、Windowsで対処しようとするとレジストリの変更が必要になる。
さすがにそれは面倒だ。
そこでサーバ側、Sambaの設定でOplocksを無効にする。

smb.confでOplocksを無効にする

oplocks = noとすればよい。
デフォルト無効にしたければ[global]セクションに、共有ごとに無効にしたければ共有のところに書けばよい。
smb.confのmanは一見、共有ごとにしか指定できないように見えるかもしれないが[global]にも使える。
また、oplocksはbooleanなのでnoでもfalseでも、はたまた0でも理解してもらえる。

なお、ファイルごとに有効無効を指定したければveto oplock filesで指定できる。

smb.confのmanより抜粋

oplocks (S)

This boolean option tells smbd whether to issue oplocks
(opportunistic locks) to file open requests on this share.
(略)

Default: oplocks = yes

smb.confのmanよりPARAMETERS抜粋

PARAMETERS
(略)
The letter G in parentheses indicates that a
parameter is specific to the [global] section. The letter S indicates
that a parameter can be specified in a service specific section. All S
parameters can also be specified in the [global] section - in which
case they will define the default behavior for all services.

 

blocking locks

Sambaはロックの方法を指定できる。
blocking locksというものである。
これは、ファイルをロックするときに、特定部分だけをロック(range lock)するか、ファイル全体をロックするか、というものである。
デフォルトで有効。
WindowsのRead Cachingに対応してそうな機能である。
加えてmanを見ると、「range lockに失敗すると、タイムアウトするまで何回かrange lockを再試行する」などと書いてある。
これも無効にしよう。

blocking locks (S)

This parameter controls the behavior of smbd(8) when given a
request by a client to obtain a byte range lock on a region of an
open file, and the request has a time limit associated with it.

If this parameter is set and the lock range requested cannot be
immediately satisfied, samba will internally queue the lock
request, and periodically attempt to obtain the lock until the
timeout period expires.

If this parameter is set to no, then samba will behave as previous
versions of Samba would and will fail the lock request immediately
if the lock range cannot be obtained.

Default: blocking locks = yes

 

設定例

以上を踏まえて、以下のように設定
しょぼい英文は勘弁しておくれ。

[global]
(略)
#
# Disable oplock
# It's supposed to improve network performance but causes problems
#
# See:
# Opportunistic Locking and Read Caching on Microsoft Windows Networks
# http://www.dataaccess.com/whitepapers/opportunlockingreadcaching.html
#
oplocks = no
blocking locks = no

 

再起動しておしまい。

$ sudo service samba restart
Performing sanity check on Samba configuration: OK
Stopping winbindd.
Waiting for PIDS: 667.
Stopping smbd.
Waiting for PIDS: 664, 664.
Stopping nmbd.
Waiting for PIDS: 661.
Removing stale Samba tdb files: .. done
Starting nmbd.
Starting smbd.
Starting winbindd.

 

(参考)Locks and Oplocks 私訳

http://www.samba.org/samba/docs/using_samba/ch08.html
Locks and Oplocks

oplocksの使用によって得られるパフォーマンス増は、大変に望ましいことがほとんどだ。
しかしながら、クライアントやネットワークのハードウェアの信頼性が怪しいような状況では、クライアントにデータをキャッシュさせることは大きなリスクになり得る。
クライアントが書き込みのためにファイルを開き、oplockを行う場合を考えてみよう。
そして他のクライアントが同じファイルを開こうとしたとき、”oplock break”要求が最初のクライアントに送られる。
もしこの要求が何らかの理由により失敗し、二番目のクライアントがファイルの書き込みをしたとする。
二つのプロセスが同時に書き込みをするわけだから、ファイルは簡単に壊れてしまうだろう。
残念なことに上記のケースは現実に起こりうる。
SMBネットワークにおける複数のWindowsクライアント環境では、このようなおかしな動きは頻繁にみられる。
たくさんのクライアントが同時に書き込みを行うデータベースファイルは特に影響を受けてしまう。

oplocksの失敗するもっと具体的な例を挙げると、それはデータベースファイルが大変に大きい場合である。
クライアントがこのようなファイルを開き、oplockを許可されると、非常に大きな遅延が発生する。
その一部を修正するためだけであっても、クライアントがファイル全部をキャッシュするからである。
このファイルを別のクライアントが開こうとしたとき、状況はさらに悪くなる。
二番目のクライアントがファイルを開くためには、最初のクライアントがキャッシュをすべてサーバに書き戻す必要があるからだ。
このために、また別の遅延が発生する(しかも双方のクライアントで)。
結果として、タイムアウトにより二番目のクライアントがファイルオープンに失敗し、たぶんデータが壊れた旨のWarning messageも併せて表示されるだろう。

In most cases, the extra performance resulting from the use of oplocks is highly desirable. However, allowing the client to cache data can be a big risk if either the client or network hardware are unreliable. Suppose a client opens a file for writing, creating an oplock on it. When another client also tries to open the file, an oplock break request is sent to the first client. If this request goes unfulfilled for any reason and the second client starts writing to the file, the file can be easily corrupted as a result of the two processes writing to it concurrently. Unfortunately, this scenario is very real. Uncoordinated behavior such as this has been observed many times among Windows clients in SMB networks (with files served by Windows NT/2000 or Samba). Typically, the affected files are database files, which multiple clients open concurrently for writing.

A more concrete example of oplock failure occurs when database files are very large. If a client is allowed to oplock this kind of file, there can be a huge delay while the client copies the entire file from the server to cache it, even though it might need to update only one record. The situation goes from bad to worse when another client tries to open the oplocked file. The first client might need to write the entire file back to the server before the second client’s file open request can succeed. This results in another huge delay (for both clients), which in practice often results in a failed open due to a timeout on the second client, perhaps along with a message warning of possible database corruption!

Hadoopフレンドリーなデータとは

Pocket

 

ログは1行1イベントに

何を言っとるんだお前はという感じであるが、つまりこういう事である。

通常、ログは1行が1イベントである。
たとえばapacheのログやらなにやら、みんなそうである。
少なくともUNIX系のシステムであれば、これは常識である。
しかし、この世の中、UNIX系の常識が通用しないログだって山ほどあるのである。

1イベントが複数行にわたるログがなぜいけないか。

たとえば以下の様な擬似ログを考えてみよう。

まったく関係のない話だが、以下のデータは手元にあるLIFEのノートから適当にでっち上げた。
冒頭にタイムスタンプがあり、イベントの内容が記される、典型的なログである。

2013/12/16 17:55:05.6582 N28 [499016804864] Noble note section B6 5m/m

しかしこれが、以下のように複数行にわたって記録(あるいは表示)される、こういうログを相手にすることだってあるのだ。

2013/12/16 17:55:05.6582 N28
4990 1680
4864
Noble note section
B6 5m/m

 

これは主に可読性を意識したせいであろうが、こういったログをHadoopで扱うのは難しい。

Hadoopのデータの扱い方

というのも、Hadoopは分散処理のためにログを分割するからだ(デフォルトでは64MBごと)。

しかもその分割は、単純にサイズのみで判断され、文脈は考慮されない。
上のログで言えば、Nobleの手前で切られてしまってログとして意味がなくなってしまうことだってある。

これを避けるには、Hadoopにファイルそのものではなくて、ファイルリストを与える手があるけれども、それではHadoopの長所を活かせない。
ファイルリストは綺麗に分割されるけど、ファイルの大きさはまちまちだから。

ログの整形

というわけで、こういったログを扱う前に、下準備として1行1イベントにまとめてしまおう。

まとめ自体もHadoopで処理してしまえば楽である。
Hadoopの象本Appendix Cに良い例があるのでこれを使う。
ここでfiles.txtは処理するログファイルをリストしたものとする。
また、concat.shは1行1イベントにまとめるスクリプトとする。

$ hadoop jar $HADOOP_INSTALL/contrib/streaming/hadoop-*-streaming.jar \
-D mapred.reduce.tasks=0 \
-D mapred.map.tasks.speculative.execution=false \
-D mapred.task.timeout=12000000 \
-input files.txt \
-inputformat org.apache.hadoop.mapred.lib.NLineInputFormat \
-output output \
-mapper concat.sh \
-file concat.sh

 

reduceは必要ないのでmapred.reduce.tasks=0。
重複して書き込んでほしくないのでmapred.map.tasks.speculative.execution=false。
タイムアウトは長めに。
mapが一回に処理するファイルはひとつにしたいので、-inputformat org.apache.hadoop.mapred.lib.NLineInputFormat 。

以上

NginxでのFastCGI PHP設定

Pocket

 

タイトル通り、FreeBSDでnginx、FastCGIでPHPを動かす場合。
lighttpd + phpの場合はこちら

必要なもの。

  • nginx
  • spawn-fcgi
  • php(fastCGI)

 

概要

nginxは静的コンテンツ向けのwebサーバ。
そのままでは動的コンテンツは扱えない。
どうしても必要なら、よそで動的コンテンツを生成してもらわなければならない。

その仕組みの一つにFastCGIがある。
FastCGIは動的コンテンツの受け渡しのためのインタフェースである。
spawn-fcgiはFastCGIプロセスの管理を行う。

ここで、PHPにはFastCGIサーバモードというのがある。
指定されたポートで待ち受けてリクエストに応えるというもの。
spawn-fcgiとPHPのFastCGIサーバモードを組み合わせれば、PHPのFastCGIインタフェースができあがる。

nginxはPHPコンテンツのリクエストを受けたら、FastCGIを通してphp-cgiにコンテンツを生成してもらう、というわけ。

参考。まあwikipediaなんですけどね。

nginx
http://ja.wikipedia.org/wiki/Nginx
CGI
http://ja.wikipedia.org/wiki/Common_Gateway_Interface
FastCGI
http://ja.wikipedia.org/wiki/FastCGI

インストール

FreeBSDなら、pkgで前章の三つをインストールする。
特に難しいこともないので割愛。
phpはpkgそのままでfastCGI対応になっているので意識する必要なし。

PHPの確認

FastCGI対応かどうかを念のため確認。
/usr/local/bin/php-cgiというのがインストールされていればよい。
念のため-vで確認。

$ php-cgi -v
PHP 5.4.23 (cgi-fcgi) (built: Dec 19 2013 21:06:30)
Copyright (c) 1997-2013 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2013 Zend Technologies

 

spawn-fcgiの設定

spawn_fcgiには特定の設定ファイルがないのでrc.confに直接書き込む。
起動スクリプト/usr/local/rc.d/spawn-fcgiの中身を見るとどういったオプションがあるかが分かる。

nginx、spawn-fcgiの起動設定と一緒にやってしまおう。
下記を/etc/rc.confにひとまず貼りつける。

コメントアウトしてあるのはデフォルト設定。
変えたい箇所があれば#を外して設定する。

注意!
spawn-fcgiのspawnとfcgiの間はハイフン(ダッシュ)”-“であるが、/etc/rc.confでの記載にはアンダースコア”_”にすること。
言い方を変えると、spawn-fcgi_enableなどと書かないこと。

#
# nginx, with PHP FastCGI
#
nginx_enable="YES"
spawn_fcgi_enable="YES"
##spawn_fcgi_app="/usr/local/bin/php-cgi"
##spawn_fcgi_pidfile="/var/run/spawn-fcgi.pid"
##spawn_fcgi_username="www"
##spawn_fcgi_groupname="www"
##spawn_fcgi_bindaddr="127.0.0.1"
##spawn_fcgi_bindport="9000"
##spawn_fcgi_bindsocket_mode="0777"
##spawn_fcgi_children="5"
##spawn_fcgi_max_requests="1000"
##spawn_fcgi_path_env="/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin"

最終的に以下のようにした。
個人用のサーバなのでささやかに。
(冗長なので一部のコメント部分は除く)

#
# nginx, with PHP FastCGI
#
nginx_enable="YES"
spawn_fcgi_enable="YES"
spawn_fcgi_bindport="8000"
spawn_fcgi_children="3"
spawn_fcgi_max_requests="100"

 

spawn-fcgiの起動確認

serviceコマンドで起動。

$ sudo service spawn-fcgi start
Starting spawn_fcgi.
spawn-fcgi: child spawned successfully: PID: 7486

sockstatで待ち受けポートを確認

$ sockstat -l4
USER     COMMAND    PID   FD PROTO  LOCAL ADDRESS         FOREIGN ADDRESS
www      php-cgi    7489  0  tcp4   127.0.0.1:8000        *:*
www      php-cgi    7488  0  tcp4   127.0.0.1:8000        *:*
www      php-cgi    7487  0  tcp4   127.0.0.1:8000        *:*
www      php-cgi    7486  0  tcp4   127.0.0.1:8000        *:*
(略)

 

phpの動作確認

nginxにはサンプルの設定ファイルがついてくる。
それをベースに、たとえば以下のような設定ファイルを作る。
location ~ \.php$のブロックが重要。
fastcgi_pass 127.0.0.1:8000;のポートを先のswawn-fcgiと合わせること。

worker_processes  1;
events {
    worker_connections  1024;
}
http {
    include       mime.types;
    default_type  application/octet-stream;
    sendfile        on;
    keepalive_timeout  65;
    server {
        listen 80;
        root /usr/local/www/php-test;
        index   index.html;
        fastcgi_index   index.php;
        location ~ \.php$ {
                include fastcgi_params;
                fastcgi_param   SCRIPT_FILENAME  $document_root$fastcgi_script_name;
                fastcgi_pass    127.0.0.1:8000;
        }
    }
}

/usr/local/www/php-testにindex.htmlをつくる。また、test.phpを作る。
index.html

It works!

test.php

<?php
phpinfo();
?>

nginxをスタートしておき;

$ sudo service nginx restart
Performing sanity check on nginx configuration:
nginx: the configuration file /usr/local/etc/nginx/nginx.conf syntax is ok
nginx: configuration file /usr/local/etc/nginx/nginx.conf test is successful
Stopping nginx.
Performing sanity check on nginx configuration:
nginx: the configuration file /usr/local/etc/nginx/nginx.conf syntax is ok
nginx: configuration file /usr/local/etc/nginx/nginx.conf test is successful
Starting nginx.

ブラウザで繋ぐ。
スクリーンショット撮るのが面倒なのでw3mで。
下記の通り/usr/local/www/nginx/index.htmlの内容が表示される。

$ w3m 127.0.0.1
It works!

index.htmlの内容が表示された。
これで通常のwebサーバとしては問題なく動作していることが確認できた。

ではphpの動作確認
PHP infoの結果が表示される。
内部的には、nginxが127.0.0.1:8000で待っているphp-cgiにtest.phpを実行させて、その結果を返している。

$ w3m 127.0.0.1/test.php

PHP Logo

PHP Version 5.4.23

              FreeBSD copper 10.0-RC2 FreeBSD 10.0-RC2 #0 r259404: Sun Dec
System        15 08:18:20 UTC 2013 root@snap.freebsd.org:/usr/obj/usr/src/
              sys/GENERIC amd64

Build Date    Dec 19 2013 21:05:25
(略)

以上

hadoopのsafemodeとfsck

Pocket

 

Hadoopのnamenode兼datanodeが電源瞬断のせいで壊れてしもうた。
勉強用のHadoopなのでダメージはないのだが、せっかくなのでfsckなどを試した結果を記す。
hadoop-1.0.0。
OS側でもfsckはしておいた。

サマリ

  • HDFSにもfsckがある。
  • hadoop fsckでチェック、修正できる。
  • hadoop fsckと叩けば使い方の簡単な説明が表示される。
  • namenodeがsafemodeのためにHDFSが読み取り専用になっていることがある。
  • 読み取り専用ではfsckで修正できないので、safemodeから出る必要がある。

 

HDFSでのfsck

hadoop fsck <path>と指定すればよい。
CORRUPT!とのことで、壊れておりますなあ。

$ hadoop fsck /
FSCK started by hadoop from /172.29.17.159 for path / at Wed Dec 25 18:51:37 JST 2013
(略)
/var/hadoop/mapred/system/jobtracker.info: MISSING 1 blocks of total size 4 B.Status: CORRUPT
Total size: 45638364128 B
Total dirs: 5321
Total files: 13059
Total blocks (validated): 9819 (avg. block size 4647964 B)
********************************
CORRUPT FILES: 2470
MISSING BLOCKS: 2498
MISSING SIZE: 15590981155 B
CORRUPT BLOCKS: 2498
********************************
Minimally replicated blocks: 7321 (74.559525 %)
Over-replicated blocks: 0 (0.0 %)
Under-replicated blocks: 7321 (74.559525 %)
Mis-replicated blocks: 0 (0.0 %)
Default replication factor: 2
Average block replication: 0.7455953
Corrupt blocks: 2498
Missing replicas: 7321 (100.0 %)
Number of data-nodes: 1
Number of racks: 1
FSCK ended at Wed Dec 25 18:51:38 JST 2013 in 1185 milliseconds

The filesystem under path '/' is CORRUPT

 

壊れている場合の対処:消去か移動

壊れている場合には対処が二つ。
壊れているブロックを消すか、lost+foundに移すか。
消す場合には-delete, 移す場合には-moveを指定する。
以下は消した場合の例….なのだが、namenodeがsafemodeにいるので変更が出来ないとのこと。

$ hadoop fsck / -delete
FSCK started by hadoop from /172.29.17.159 for path / at Wed Dec 25 18:58:29 JST 2013
.
/tmp/hadoop-hadoop/mapred/staging/hadoop/.staging/job_201308300823_0001/job.jar: CORRUPT block blk_3947350403157044322

/tmp/hadoop-hadoop/mapred/staging/hadoop/.staging/job_201308300823_0001/job.jar: MISSING 1 blocks of total size 66249 B.FSCK ended at Wed Dec 25 08:58:29 JST 2013 in 5 milliseconds
Cannot delete /tmp/hadoop-hadoop/mapred/staging/hadoop/.staging/job_201308300823_0001/job.jar. Name node is in safe mode.
The ratio of reported blocks 0.7456 has not reached the threshold 0.9990. Safe mode will be turned off automatically.

Fsck on path '/' FAILED

 

safemodeとは

そもそもnameodeは通常の動作として、起動時には状態がsafemodeである。
safenodeのまま待機をしているうちに、datanodeが起動し、保管しているブロックの報告をnamenodeに行う。
namenodeは、充分なブロックの確認ができれば自動的にsafemodeを出る。
「充分なブロック」がどれくらいか、は設定できる。

safemodeのときは読み取り専用になり、複製や消去もできないが、手動でsafemodeに入ったり出たりすることができる。

以下、公式からの引用

Safe mode is entered automatically at Namenode startup, and leaves safe mode automatically when the configured minimum percentage of blocks satisfies the minimum replication condition. Safe mode can also be entered manually, but then it can only be turned off manually as well.
Safe mode maintenance command. Safe mode is a Namenode state in which it
1. does not accept changes to the name space (read-only)
2. does not replicate or delete blocks.

今回、問題の発生したnamenodeはdatanodeも兼ねている。
電源瞬断でブロックが壊れているからブロックの報告はできないし、そもそもnamenodeが保管しているメタデータも壊れている。
ボロボロである。
したがって、いつまで待ってもsafemodeから出るはずがない。
そこで手動でsafemodeを解除する。

safemodeの操作

safemodeの操作はhadoop dfsadmin -safemodeに続けて行う。
getで状態を得る。
enterでsafemodeに入る。
leaveでsafemodeから出る。
面白いのは、wait。
safemodeから出たらコマンド実行する、というもの。

# 状態を得る。
$ hadoop dfsadmin -safemode get

# 終わってからコマンド実行
$ hadoop dfsadmin -safemode wait

# safemodeに入る。
$ hadoop dfsadmin -safemode enter

# safemodeから出る。
$ hadoop dfsadmin -safemode leave

以下、実際の例。
safe modeがONになっているので、OFFに。

$ hadoop dfsadmin -safemode get
Safe mode is ON

$ hadoop dfsadmin -safemode leave
Safe mode is OFF

改めてfsck / -delete
blockが2000個くらい消えた。ま、まあ勉強用だし(震え声)

$ hadoop fsck / -delete
FSCK started by hadoop from /172.29.17.159 for path / at Wed Dec 25 19:05:54 JST 2013
(略)
.......Status: HEALTHY
Total size: 29928657533 B
Total dirs: 5321
Total files: 10589
Total blocks (validated): 7319 (avg. block size 4089173 B)
Minimally replicated blocks: 7319 (100.0 %)
Over-replicated blocks: 0 (0.0 %)
Under-replicated blocks: 7319 (100.0 %)
Mis-replicated blocks: 0 (0.0 %)
Default replication factor: 2
Average block replication: 1.0
Corrupt blocks: 0
Missing replicas: 7319 (100.0 %)
Number of data-nodes: 1
Number of racks: 1
FSCK ended at Wed Dec 25 19:05:55 JST 2013 in 1696 milliseconds

The filesystem under path '/' is HEALTHY

HEALTYになったので、これでhadoopが使える状態に戻った。
以上。

[メモ] grepでコメント行、空行以外の行を表示させるには

Pocket

 

いつも忘れるのでメモ。
あるファイルから、コメント行と空行を除いて表示させるには。

コメント行なら”^ *#”がマッチ。
空行なら^ *$”がマッチ。

egrepに -v “^ *#|^ *$” を与えればよい。
冒頭タブとかは漏れてしまうけど、ひとまずはこれでいいかな。

以下、実行例。

$ egrep -v "^ *#|^ *$" ./nginx.conf
user  www;
worker_processes  1;
events {
    worker_connections  1024;
}
http {
    include       mime.types;
    default_type  application/octet-stream;
    sendfile        on;
    keepalive_timeout  65;
    server {
        listen       80;
        server_name  localhost;
        location / {
            root   /usr/local/www/nginx;
            index  index.html index.htm;
        }
        error_page   500 502 503 504  /50x.html;
        location = /50x.html {
            root   /usr/local/www/nginx-dist;
        }
    }
}

 

iCalにGoogleのカレンダーを表示するには

Pocket

 

メモ。
iCalにGoogleカレンダーの内容を表示させる方法について

事前準備

googleの二段階認証を有効にしている場合には、googleのアカウントでiCal向けのパスワードを作っておく。
icaladdgoogle2stepauth20140110

 

登録

流れ。

  1. iCalからカレンダー、アカウントの追加を選ぶ
  2. Googleを選ぶ
  3. アカウント情報を入れる。

 

二段階認証を有効にしている場合には、Step3で、Googleアカウントで作ったical向けのパスワードを入力。

Step 1
icaladd
Step 2
icaladdgoogle20140110

Step 3
icaladdgoogleauth20140110

以上

EasyBotterをFreeBSDで動かす

Pocket

 

EasyBotterとはTwitter Botツールで、pha氏の手になるもの。
phpで作られている。

設定は以下に沿うとして、このツールをFreeBSDで動かすために必要な事を記す。
http://pha22.net/twitterbot/
http://www26.atwiki.jp/easybotter_wiki/pages/1.html

FreeBSD 10.0-RC1, pkgngで実施。

EasyBotterの展開

ダウンロードしたEasyBotterを展開する。
どこでもよい。

$ ls
EasyBotter.php          bot.php                 license.txt
PEAR                    data.txt                log.dat
RCS                     path.txt                 reply_pattern.php
__MACOSX                index.html              setting.php

設定は冒頭のリンクに沿ってどうぞ。

phpのインストール

最低限必要なものは以下の三つ。2013/12/16現在。
php5-5.4.21                    PHP Scripting Language
php5-hash-5.4.21               The hash shared extension for php
php5-json-5.4.21               The json shared extension for php

botの喋る内容はUTF-8で書くので、vimも入れておくとよいかも。

テスト

bot.phpを実行する。
以下のようになれば成功。

$ php ./bot.php
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" lang="ja" xml:lang="ja">
<head>
<meta http-equiv="content-language" content="ja" />
<meta http-equiv="content-type" content="text/html; charset=UTF-8" />
<title>EasyBotter</title></head><body><pre>Twitterへの投稿に成功しました。
<br />@<a href='http://twitter.com/samplebot' target='_blank'>samplebot</a>に投稿したメッセージ:....

 

cronに設定

以下のようなどうってことないシェルスクリプトを作って;

#!/bin/sh

cd /home/nobody/files/EasyBotter/
/usr/local/bin/php ./bot.php

crontabに設定。

$ crontab -l
10 * * * * /home/nobody/bin/bot.sh

以上