任意のディレクトリ以下のファイル全部でメッセージダイジェスト(ハッシュ) を取得

メモエントリ
 
 

find でフルパスを貰って、xargs に投げるというだけだがメモ。
 

# find /etc -type f -exec ls -1d {} \; | xargs openssl dgst -sha1
 
"/etc" 以下で 属性がファイルのものをフルパス表示させて片っ端から openssl に投げてハッシュを出力する。
(これは sha1 でやってるけど、デフォルトの md5 のほうがはるかに早いです)
 

"/etc" 出力例
SHA1(/etc/logrotate.conf)= 7b323754d7a2235d2af27d033d0d9f4bc04d702d
SHA1(/etc/pcmcia/config.opts)= 0a5c34714920af23596fbf8b7e88ae8b1a32e9d3
SHA1(/etc/scsi_id.config)= fa2ed8a92d90c965842f2e5ca763fc02a89672f3
-- snip --
SHA1(/etc/modprobe.d/modprobe.conf.dist)= 950ba44077e82aaf2a17d11f2900e94cab208f8b
SHA1(/etc/modprobe.d/blacklist-firewire)= de82c03c535e9deb16aed94153883280891da2d7
SHA1(/etc/mail.rc)= 9197e3c08646d0be585103d88d041182460ca0e5
 

ディレクトリをコピーや移動して、心配な時に diff に食わせる。

ZFS のデバイスを「物理⇔仮想」で移植（できるかもしれない）

前回、ZFSのデバイス管理について書いたが、ふとわいた疑問があったのでテストしてみた。
各デバイスは中身だけあればいいんだから、ddでいくらでもコピーできるんじゃないのか。
 
 

テスト用ZFSストレージプールの作成

物理HDDをパーティションで区切ったもの "c1d1p2 c1d1p3 c1d1p4" の3つでプールを作った。
RAWデバイスでやりたかったがちょっと手元になし。
 

ステータスを見るとこうだ。
$zpool status
プール: zfs01
状態: ONLINE
スクラブ: 何も要求されませんでした
構成:
 
NAME STATE READ WRITE CKSUM
zfs01 ONLINE 0 0 0
c1d1p2 ONLINE 0 0 0
c1d1p3 ONLINE 0 0 0
c1d1p4 ONLINE 0 0 0
 
エラー: 既知のデータエラーはありません
 


では、おもむろにエクスポートしよう。

$zpool export zfs01

 
準備OK。
 
 

ddコマンドでデバイスを少しファイルに書き出し

さて、先ほどのプールに使ったデバイスたち、当然ZFSのメタ情報が頭のほうに入っているに違いない。
ということで dd コマンドを使って先頭のほうだけファイルに書き出してみよう。
"/zdev3/" というフォルダに、3つのパーティションからそれぞれ "p2 p3 p4" というファイルで書き出した。これらは合計1MBにも満たない。

$dd if=/dev/dsk/c1d1p2 of=/zdev3/p2 count=512
書き込まれたレコード数 512+0
読み出されたレコード数 512+0
$dd if=/dev/dsk/c1d1p3 of=/zdev3/p3 count=512
書き込まれたレコード数 512+0
読み出されたレコード数 512+0
$dd if=/dev/dsk/c1d1p4 of=/zdev3/p4 count=512
書き込まれたレコード数 512+0
読み出されたレコード数 512+0

 
 

いんちきファイルをインポート認識するか？

さあ、さっき作ったファイルを置いたディレクトリを指定して、インポート検出してみる。

$zpool import -d /zdev3
プール: zfs01
ID: 9060992260761082608
状態: ONLINE
アクション: プールの名前または数値識別子を使用してプールをインポートできます。
構成:
 
zfs01 ONLINE
/zdev3/p2 ONLINE
/zdev3/p3 ONLINE
/zdev3/p4 ONLINE

認識するし。。。オイオイ、この節操なしめ。
 
 

まとめ

ZFSのストレージプール用デバイスは、うまいことやれば物理仮想問わずに乗せ換えが自由自在かもしれない。
懐が深い気もするが、穿った見方をすれば結構いいかげんに作ることで堅牢っぽく見せているともいえるか。
 

今度は容量をちゃんと確保して、RAWからファイルに書きだしてZFSを再構築したいな。
 

ZFSはストレージプール(zpool)のデバイス情報をツリー状にGUIDで管理する

ZFSをちまちまと触っていると疑問に思うことがあります。
ストレージプールの移行が妙に柔軟にできるようだが、デバイスの管理はどうやってるんだろう。
 
タイトルでネタばれはせっかちなので仕方ないとして、ZFSの話。
※ここの情報は ZFSの ver.4 ver.10 で確認、特にドキュメントないので変更の可能性は大？ 間違ってたり変更があったら是非教えてください。
 
 

実際、ZFSの移行 "zpool export" したデバイスを適当なサーバにつないで "zpool import"すれば、物理デバイス(のパス)がなんであろうがZFSはストレージプールの情報を拾ってきて移行完遂してくれる。
ソースが公開されているので ZFSソースツアー を解読すればきっちりわかるんだろうが生憎と C言語 が読めん。

 
 

物理パス・論理パスと移行前に比べてデタラメでもきっちり自分のZFSを構成するデバイス(ファイル)群を認識する、どう考えても独自になにか付与しているんだろう。

で、どうなってるのか気になっていたところに見つけた情報が

[zfs] どこにも mount されていないのに zfs snapshot が取れない件 < < 気になるもの

 

zdb？そんなコマンド、ZFSの管理ドキュメントにのってないじゃないか、ZFSのデバッグ用らしいが。
 
 

zdb、ZFSデバッグ用のコマンドを使ってメタ情報をがっつり収集

とりあえずファイルをzpoolのデバイスとしてミラーで構築したZFSを作った。わかりやすいようにストレージプルのデバイスは mkfile で作ったファイルにした。
こんな感じだ

Zpool名：mf01
ミラー

• /zdev/mfile01


• /zdev/mfile02

 


 

で、 zdb を叩いてみる。
$zdb
mf01
version=10
name='mf01'
state=0
txg=4
pool_guid=8209644695030027085
hostid=500812174
hostname='hogehoge.example.com'
vdev_tree
type='root'
id=0
guid=8209644695030027085
children[0]
type='mirror'
id=0
guid=13660030613472834359
metaslab_array=14
metaslab_shift=21
ashift=9
asize=257425408
is_log=0
children[0]
type='file'
id=0
guid=9114859995283150354
path='/zdev/mfile01'
children[1]
type='file'
id=1
guid=8018218252628534999
path='/zdev/mfile02'

おやおやこいつは．．．
もう「謎は全て解けた」も同然だな。
 
 

guid だね、各デバイスにこのZFSメタ情報を書いておくんだろう。
インポート、ZFSを再構築する際は solaris(OS) が認識したブロックデバイスに対し、片っぱしからZFSのデバイスかどうか調べてguidからツリーに当てはまるようにしているんだろう。
 

guidの付与されるタイミングは ストレージプールに参加するタイミングだろう、それ以外考えられないしそうでないと意味がない。
 
 

検証としてデバイスのパスを変えてみる

ディレクトリを一個作って、zpoolを構成するデバイス(ファイル)のパスを変えてみる、プールは事前に "export" 済み。
 

$cp /zdev/mfile0* /zdev2
$mv /zdev2/mfile01 /zdev2/hogehoge01

これで "zdev2" というディレクトリに名前違いのデバイスコピーができた、"import" でみてみる。

$zpool import -d /zdev2
プール: mf01
ID: 8209644695030027085
状態: ONLINE
アクション: プールの名前または数値識別子を使用してプールをインポートできます。
構成:
 
mf01 ONLINE
mirror ONLINE
/zdev2/hogehoge01 ONLINE
/zdev2/mfile02 ONLINE
 

デバイス名が移行前と全然違うのにONLINEなのが分かる。
インポート後にまた "zdb" で見てみよう

mf01
version=10
name='mf01'
state=0
txg=496
pool_guid=8209644695030027085
hostid=500812174
hostname='hogehoge.example.com'
vdev_tree
type='root'
id=0
guid=8209644695030027085
children[0]
type='mirror'
id=0
guid=13660030613472834359
metaslab_array=14
metaslab_shift=21
ashift=9
asize=257425408
is_log=0
children[0]
type='file'
id=0
guid=9114859995283150354
path='/zdev2/hogehoge01'
children[1]
type='file'
id=1
guid=8018218252628534999
path='/zdev2/mfile02'

ファイル名を変えたデバイスについて、path 要素は更新・GUIDは変わらずと判るだろう。
 
 

ちょっとまとめ

ZFSは事前にエクスポートさえしておけば、ストレージプールを構成するデバイスを全部認識さえさせれば蘇る。としていいんじゃないかな。
 
生前と物理パス・論理パスすらも問わないのでとにかく認識させろ、ということだ。
 
多分エクスポートも不要だが、そこは安全性を考慮してのことで。
これでいろいろとすっきりした。
 
 
 

おまけ：guidだけ、というわけではない

基本的には guid を基準としてデバイスプールが再構築されるんだが、それだけじゃないよという例を。
 

raidz2 のプールを作って、それをエクスポートしてみる。

rz01 ONLINE
raidz2 ONLINE
/zdev/file01 ONLINE
/zdev/file02 ONLINE
/zdev/file03 ONLINE
/zdev/file04 ONLINE
/zdev/file05 ONLINE
/zdev/file06 ONLINE


で、これの "/zdev/file04" だけを "/zdev2/rzhoge04" とコピーして、 "/zdev2/" を対象にインポート調査をしてみよう。
 
あくまで "/zdev2/" のみなので、インポートコマンドは "rzhoge04" しか見ないはずだが．．．


$zpool import -d /zdev2
プール: rz01
ID: 15179283843329238703
状態: ONLINE
アクション: プールの名前または数値識別子を使用してプールをインポートできます。
構成:
 
rz01 ONLINE
raidz2 ONLINE
/zdev/file01 ONLINE
/zdev/file02 ONLINE
/zdev/file03 ONLINE
/zdev2/rzhoge04 ONLINE
/zdev/file05 ONLINE
/zdev/file06 ONLINE


他の構成要素 "file01-06" もすべてONLINE として認識される。
 

これは "import" がデバイスの認識をするにあたって、

1. 見えるデバイスがZFSのデバイスか判断して、ZFSデバイスならGUIDをみる


2. PATHで指定されいるデバイス(ファイル)が存在するか見て、あればGUIDを確認

という事をしているんだろう、周到だ。
 
ちなみに "file04" は存在しているが "rzhoge04" が優先されていることから、やっぱりGUIDを先に認識したものを優先するんだろう。
pathも意味がないわけではないということがわかった。
ついでにZFSのメタデータは全デバイスに保存されてるだろうということが確認できた。
 
 
 

おわりに

どうも zdb も デバイスの guid についても sunのドキュメントにそれらしき記述がない、国内のサイトにも全然情報がない。
アンドキュメンテッドな仕様というやつだったんだろうか、ソース見ればわかるから特に記述してないのか、よくわからないな。
 

その辺から本稿の初期タイトルは「ドキュメントでは教えてくれない、ZFSの秘密」だったんだが、事情もよく知らんし「なんだかびみょう」なのでネタばれ優先のタイトルにした。
 

全デバイスにメタデータ保存・GUID付与してそれを優先に管理というのは色々と理にかなっているなあと感心、「シンプル イズ ザ ベスト」だね。

エイサー Aspire one のACアダプタを”ちょっとだけ”改良する

前回の記事とかぶるというか結果報告。
 

エイサーの Aspire one が自宅にあるんですが、ACアダプタのケーブル差し込み口がミッキーマウス型で、ケーブル太いんですよね、
 

で、変換アダプタを買いましたと。
どのくらいスッキリするか比べてみましょう。
[caption id="attachment_1243" align="alignnone" width="480" caption="写真：使用前、見た目"][/caption]
 

[caption id="attachment_1244" align="alignnone" width="480" caption="写真：使用後、見た目"][/caption]
 

スッキリ．．．？ したよね。
まあパッと見わからないかもしれないが、太いケーブルの取り回しの悪さは使ってるひとならよくわかるでしょう、すごく良くなった。
 
 
 

ついでにモバイル的に重要な要素、目方についてもレポートしておこう。

[caption id="attachment_1245" align="alignnone" width="360" caption="写真：使用前、重さ"][/caption]
 

[caption id="attachment_1246" align="alignnone" width="360" caption="写真：使用後、重さ"][/caption]
 

見たまえ、60g かるくなったぞ
 

長年の野望が叶った満足感＋とり回し向上の実感がある割に見栄えと数字に表れてないが、お勧めだ。

安めのノートPC・ネットブックのACアダプタ、太っといケーブルが嫌

とても嫌。
 

主に海外製のノートPCやネットブックに標準添付されているACアダプタについてくるあの太いケーブル。
 
 

常日頃から何とかならないかと思っていたら、ダイヤテックがとてもよいものを販売しているじゃないの。
 

3ピン→2ピン変換プラグ YL-3114 (通販ページリンク)
 
これがあれば細いケーブルに変更できる。
 
 

アジャスタブルACケーブル＆3ピン→2ピン変換プラグセット PLSACC2 ＆ YL-3114 (通販ページリンク)
 
ついでに携帯に便利なケーブルもつけても良さそう。
 
 

ここ数日、買おうと思いつつ自宅に戻ると忘れている、絶対買うのでTODOとしてエントリー。


ネタ元はこちら、さすがというか目ざとい。。
電源回りにウルサい拙者 < < スタパ齋藤の「週刊スタパトロニクスmobile」
 
 

まあ電源周りという事もあって保証は出来ないので、心配なら使わないほうがいいかも、念のため。
巻き取りは特に危なっかしいよね、電源ドラムなんかは巻いたまま使うと燃えることあるし。
 

3ピンから2ピンに変換 → 普通の2ピンケーブル、という組み合わせがやっぱりベストかな。

フリーソフトでHDDの内容を消去する

古いPCのデータを消そうと思いました。
 

そこでデータ消去に丁度よいものはないかと探したら、 Darik's Boot And Nuke(DBAN) というツールの紹介をいくつか発見。
 

CD-ROMから起動できて、データを消去する方式が選べる。
前からHDDを初期化するときは 最低でも 米国国家安全保障局方式(NSA) か 米国国防省方式(DoD) 方式でやろうと思っていたので、対応しているこのツールをチョイス。
 
 

で、使ってみた。

[caption id="attachment_1237" align="alignnone" width="300" caption="写真：HDDデータ消去中"][/caption]
 

驚きの並行作業 をやってくれているようで満足。

Linux の シャドウパスワードを移行する

Linux のユーザ管理、"/etc/passwd","/etc/shadow" ついでに "/etc/group""/etc/gshadow" とあります。
これを他のサーバに移行したい場合、そのまま持っていけばOKというお話。
 
 


shadow にはハッシュが書いているだけなので、ハッシュの求め方が同じシステムでも動作するのは当然ということで、折角なのでLinux同士で試してみた。
(※FreeBSDに移動するのもOKらしいね、ファイル名は違うけど)

FreeBSDに関して情報追記：
フィールドの並びも違うよ。あと、BSD はパスワードデータベースファイルを作るのでファイルをコピーした場合、pwd_mkdb(8)なりvipw(8)なりでデータベースも更新する必要があります
by umq さん
なるほどー

 
 

編集用コマンドが用意されてるので一応それ使いましょう

"/etc/passwd","/etc/shadow" を直接 vi で編集すると何かしら事故った時に困るので、専用の編集コマンドがあります。
 

vipw, vigr というのがそれ、使い方は vi と同じなんですけど、同時読み込みとか保存とか気を使ってくれるらしい。デリケートゾーンのお手入れ用？という感覚だろうか。
 

ちょっとその 'man vipw' を。

VIPW(8) BSD System Manager’s Manual VIPW(8)
 
NAME
vipw, vigr - edit the password or group files
 
SYNOPSIS
vipw [-V] [--version]
vigr [-V] [--version]
 
DESCRIPTION
Vipw edits the password file after setting the appropriate locks, and does any necessary processing
after the password file is unlocked. If the password file is already locked for editing by another
user, vipw will ask you to try again later. The default editor for vipw is vi(1).
Vigr edits the group file in the same manner as vipw.
 
ENVIRONMENT
If the following environment variable exists it will be utilized by vipw:
 
EDITOR The editor specified by the string EDITOR will be invoked instead of the default editor
vi(1).
--snip--

適切ロックでヨロシクやってくれる ということだろうか、よかね。
 
"-s" でシャドウ編集となってるのもあるけど、Linux (CentOS5.2で試した) のはオプション不要、 passwd を編集した後に shadow も編集するか聞かれる。
 
 

wassr突っ込み追記
sudoers を編集する visudo(8) もあるんですよ
こちらも umq さん

貼り付けてみよう

まあちょっとやってみよう。

# vipw

とすると、 "/etc/passwd" が開くので、よそから持ってきたユーザ、
sawano, sawano64 の情報をファイル末尾にくっつける、ラストは改行しちゃ(多分)ダメ。

--snip-
sawano:x:635:635::/home/sawano/:/bin/bash
sawano64:x:636:636::/home/sawano64/:/bin/bash
 

さて、"passwd" を編集し終わって保存すると、

You are using shadow passwords on this system.
Would you like to edit /etc/shadow now [y/n]?

と聞かれる、特に編集してない場合は聞かれないので、お試しのときは注意。
 

y を押すと "/etc/shadow" の編集に入るので移行元の shadow を貼り付ける。

sawano:$1${パスワードのハッシュ}.:13872:0:99999:7:::
sawano64:$1${パスワードのハッシュ}.:13872:0:99999:7:::

 

ホームディレクトリは作ってあげないといけないので、mkdir で作って skel を持ってきてあげよう。
と書いて思ったが useradd で作って shadow だけ編集でも十分だったりするがちょっと趣旨と外れるのでやめとこう。
 


ほな移行したユーザでログインしてみよか。

# ssh sawano@localhost
sawano@localhost's password: *******
Last login: ----
-bash-3.2$

 

OKOK。
 
 

ついでに "/etc/shadow" に書かれているものをチェック

shadow ってそのままペタっとしちゃって大丈夫なの？ってちょっと心配だったので、'man shadow' で そもそも shadow に何が書かれているのかを確認した。

--snip--
DESCRIPTION
shadow manipulates the contents of the shadow password file, /etc/shadow. The structure in the
#include file is:
 
struct spwd {
char *sp_namp; /* user login name */
char *sp_pwdp; /* encrypted password */
long int sp_lstchg; /* last password change */
long int sp_min; /* days until change allowed. */
long int sp_max; /* days before change required */
long int sp_warn; /* days warning for expiration */
long int sp_inact; /* days before account inactive */
long int sp_expire; /* date when account expires */
unsigned long int sp_flag; /* reserved for future use */
}
 
The meanings of each field are:
・ sp_namp - pointer to null-terminated user name
・ sp_pwdp - pointer to null-terminated password
・ sp_lstchg - days since Jan 1, 1970 password was last changed
・ sp_min - days before which password may not be changed
・ sp_max - days after which password must be changed
・ sp_warn - days before password is to expire that user is warned of pending password expiration
・ sp_inact - days after password expires that account is considered inactive and disabled
・ sp_expire - days since Jan 1, 1970 when account will be disabled
・ sp_flag - reserved for future use
--snip--

特に保持しなきゃいけない重要な情報はないね、完全にパスワード周りの管理用ファイル。
パスワードのハッシュ以外は特に気にしなくてよいことが確認できた。
 
 

tar でうまく固めて、UID・GID を引き継いだファイルを持ってくればホームディレクトリの再現も簡単かしら。
また今度色々試してみたい。

rpmforgre の cacti (とRRDtool) を yum で入れたらグラフの文字が出てこなか った

yum で rpmforge(DAG) から Cactiを 入れたら、グラフに文字が全く出てこなかった。
 

こんな感じ → http://forums.cacti.net/about28677.html
(って、画像探しのため cacti font でググったページだけど、解決策書いてあるやん．．．まあいい)
 
 

結局、RRDtool 1.2系の バージョン 1.2.30 を配布元からダウンロードしてソースから入れて使ったら治った。
 

yum で入れた RRDtoolは v1.2.28 で、v1.2.30 をソースから入れてもデフォルトではパスが通ったところに入らない。
yum のは "/usr/bin/rrdtool" だったかな？ ソースのは "/ur/local/rrdtool1.2.30/bin/rrdtool" となるので Cacti 専用にしちゃっても問題ない。
 
 

Cactiha 0.8.7b だったかな？ たぶん 0.8.7 以上では共通っぽい。

php5をyumでいれたCentOS5でphp4も使わせる（CGI版）

php4を使っているサーバは結構ある。
そこで動かしているものを新規に作ったサーバに移そうとするといろいろ弊害、phpもその1つ。
 

CentOS5.2では php を楽なパッケージ管理で導入すると php5 が入る。そこでphp4を動かす情報が沢山あったので好みのやつを試してみた。
 
 

ということで、こちらで紹介されている方法ですんなりできた。
PHP4とPHP5を安全に共存させる方法 < < ぎじゅっやさん
 

サイトの例とは逆なんだけどね。

PHP4をApacheのモジュールとして、
PHP5をCGIとしてインストールする仕様で考える。
自身がメインで使用する方をモジュールにするといいだろう。
PHP4のインストールは特別変わらないので割愛。
引用：ぎじゅっやさん

 

じゃあちょっと php4.4.9 を入れてみる。オプションはとりあえず最低限で。
./configure --prefix=/data/php4 --exec-prefix=/data/php4 --enable-force-cgi-redirect
他のサイトで "/data/" と切っているのがあったから、実験という事もあってまねてみた。
 

こういうとき実際は"/usr/local/php4.4.9" に入れて、"/usr/local/php4" というリンクを張るのが好きだったりする。
 
 

後も同じ、ScriptAlias の指定があるところ (ScriptAlias /cgi-bin/ "/var/www/cgi-bin/") にphpのバイナリ (/data/php4/bin/php) をコピーして、apacheのコンフィグを下記のように。
 

Actionは何処かに1つ。php.conf に書いちゃってもいいかな。
あとは お好きなﾃﾞｨﾚｸﾃｨﾌﾞで AddHandler を指定すればOK.

Action php4-script /cgi-bin/php4
<Directory "/var/www/html/php4">
Options ExecCGI
AddHandler php4-script .php
</Directory>
 

結果．．．
 

http://{サーバ}/phpinfo.php
コレはphp5 で動いて (Server API Apache 2.0 Handler )
http://{サーバ}/php4/phpinfo.php
コレはphp4 で動く (Server API CGI )
 
 


phpinfo.php の中身は言うまでもないけどこんな感じ。
<?php phpinfo() ?>
 

ところでCGIってことは、Perlみたいにphpスクリプトの一行目に "#!/data/php4/bin/php" で、phpのバイナリコピーしておかなくても動くかな？
 

とやってみたらエラーが出た。
Security Alert!
The PHP CGI cannot be accessed directly.
 
This PHP CGI binary was compiled with force-cgi-redirect enabled. This
means that a page will only be served up if the REDIRECT_STATUS CGI variable is
set, e.g. via an Apache Action directive.
 

あ、駄目だった。しかもあのオプションのせいなのね。
オプションつけなかったら出来るかもね、危なっかしそうだからやめたほうがよさげだが。

ヘッドホンのイヤーパッドを交換した

というか、出来るもんだったのか。交換用が売ってる機種もあるんですね。
 
 


ヘッドホンがありまして、
[caption id="attachment_1227" align="alignnone" width="480" caption="写真：HP-W80 (Victor)"][/caption]
 

イヤーパッドが破れてしまった。ワイヤレスなのをいいことに、つけたままブートキャンプのまねごとなんかするからだ。
[caption id="attachment_1228" align="alignnone" width="480" caption="写真：破れたイヤーパッド"][/caption]
 

代わりになりそうなものを買ってきた。別メーカ・別機種の保守部品だがまあ何とかなるだろ、安かったし。
[caption id="attachment_1229" align="alignnone" width="480" caption="写真：買ってきたイヤーパッド"][/caption]
 

大きいかな？
[caption id="attachment_1230" align="alignnone" width="480" caption="写真：交換直前"][/caption]
 

アラピッタリ。
[caption id="attachment_1231" align="alignnone" width="480" caption="写真：交換完了"][/caption]
 
 


本日の出演は
ビクター製赤外線ワイヤレスヘッドホンのHP-W80と
交換用イヤーパッドのSONY EP-G1
さんでした。

SyntaxHighlighter Plus の v0.18 → v1.0b1 はだいぶ見た目が変わる

WordPress用のプラグイン、ソースコードを綺麗に見せてくれる SyntaxHighlighter Plus というのを使ってるんだけど、最近 v0.18 → v1.0b1 というバージョンアップがあった。
 

WordPressダッシュボードで更新が通知されたので、自動アップデートをかけてみたら、えらい見た目が変わってしまったのでちょっと元に戻した次第。
 
 

ロールバック、元に戻す際はpluginディレクトリから一旦、SyntaxHighlighter Plus を消して、公式のダウンロードリストから旧バージョンを落として再度pluginフォルダにアップロードすればOK。
 
 

自動アップデートは便利なのでつい押しちゃうが、ちゃんと試したほうが良いなやっぱり。

ブレーカー落ちるのは心臓に悪いがPCにもよろしくないので対策したい

一昔前のJPOP某レーベルが出しそうなタイトルになってしまったが、心情察してもらえると。
 

冬場の風呂上りにヒーターで部屋を暖めながら、ポットでお湯を沸かしつつレンジで熱燗の出来上がりを待つ間にドライヤーで髪を乾かせばブレーカーも落ちよう。
 
そうそう、PCではOfficeのインストールを仕掛けてから風呂に入ったなぁ。
 
 

と、いうわけで。
不意のブレーカー落ちを含む停電、落雷とかからPCは保護しておきたい、会社の監視センター向けに買ったAPCのバッテリ付きタップを家にも買うべきだな。これは立派なセキュリティ事故だ。
 
 


APC SurgeArrest 雷ガードタップ+電源バックアップ BACK-UPS ブラックBE325-JP

 

結構安いな、自宅で使うPC1-2台ならこれで充分。
ダッシュでブレーカーをあげるなり、高速でシャットダウンするなりという間は確保できる。
 

ほな交換用バッテリもついでに。3年ごとくらいで交換したほうがよさげ。

 
 

ついでに、サーバ用途ならこっちがいい
APC ES500 BACK-UPS ブラック BE500JP

「PowerChute Personal Edition」やUSB接続ケーブル付きでこのお値段は安いよね？容量も前出のタップより多そうだしね。
 
 


そういえば昔、落雷でISDNのTAがやられたな。当時は知らなかったが、家財の火災保険が適用できるみたいね。

9arrows導入でつまづいた点をメモる

プロジェクト管理ツール 9arrows というのがあるという記事を見て興味を持ったが、手近に有効なメモがなかったので忘れないようにインストールしてみた。
 

CentOS5.2 に RubyGEMS が入ってる環境でつまづいた点をメモっておく。
 

rake でこけた

環境にもよるんだけどRubyからPostgres接続用のアダプタが入ってないので怒られた。
"Please install the postgresql adapter: `gem install activerecord-postgresql-adapter` (no such file to load -- pg)"
で、言う通りに"gem install activerecord-postgresql-adapter" とすると失敗する。
”gem install pg” でOK、これはメッセージで一応案内されているが。
 
 

Readmeに不備

"rake db:fixture:load" fixturesのsが抜けとる。
Railsマスターならつまづかないんだろうけどさあ。
 
 

デフォルトユーザーに不備

これもReadmeの内容と言えるんだけど、 まずは"id：ninearrows , password：ninarrows" でログインできるとなってるけど入れない。新規ユーザを作ろう。
追記：DBを参照したところ、サンプルユーザは "9arrows@example.com" / "9arrows" だと思うんだ。
 
 

ユーザ名はメールアドレス

これは使用上の注意だけど、ユーザ登録の際にアカウントとメアドを入力するけど、次からログインはメアド＋パスワード。
 
 
 

なんだかのう。推奨されている？(チェックアウト先)ディレクトリ名も "9arrows-read-only" と妙な感じ。
 
とまあやっと使えるようになったが、標準のWebrick起動スクリプトを指示どおりに実行すると、デーモンでも何でもなく3000番街受けのWEBサーバアプリが動く、ログは標準出力へ。
 

…しかたない、apache2.2 + Phusion Passenger(mod_rails) で動かそう。

Apache上でサブディレクトリを切って使うときの設定

サブディレクトリ"/9arrows" で動かすために マニュアル4.3のとおり "/usr/local/9arrows-read-only/public" のリンクをつくって RailsBaseURI で "/9arrows" 指定と。所有者 root ではPassengerは動かないから変えて。
バーチャルホストはしなかった。
 

Apacheコンフィグにひと工夫

9arrows の実行ファイルが"*.cgi" だからなのか？ 500番エラーで止まる。
ディレクトリのディレクティブを切って、.cgi を removehandler, OptionsをNone にしたらよくなった。どっちかというとハンドラかな？
 

development と production

database.yml の設定なんだけど、9arrows はデフォルトで development を使う、READMEの設定指示もそこまで。
Passenger は production を使う、Apache側で RAILS_ENV をdevelopmentにするか、database.yml の設定を両方同じにするか。
というか何でdevelopment なんだろう？
 
 
ともかく完了、Passengerのデバッグ出力がなかったらもっと解決に時間がかかったかもしれない。
 
 
 

しかし似たようなところで、Redmineのインストール手順なんてやたら手厚い感じがしたなあ。
9arrowsも中身よさそうなのに、導入支援が添付のREADMEだけなのはいただけないんじゃないのかな。

カーネルコンフィグどこだっけ？(Linux 2.6系)

忘れるのでメモ
 

CONFIG_IKCONFIG と CONFIG_IKCONFIG_PROC を有効にしてカーネルをビルドしている場合は、
"/proc/config" か "/proc/config.gz" に稼働中カーネルのコンフィグが出力されている。
 
zcat なり cat で見れる。
 
 

カーネルをyumで管理している場合は IKCONFIG は無効なので(CentOS5.2だとそう)、まず現在動作しているカーネルの開発用パッケージを入れる必要がある。
 
要は "kernel-devel" をyum install したらいい。
 

"/usr/src/kernels/{現在のカーネルバージョン}/" ディレクトリにある ".config" にカーネルのコンフィグが記述されている、と。
 
 


とにかくカーネルイメージからコンフィグ状況を取り出したいというときは丁寧に解説しているサイトにリンクさせていただく。
●カーネルのコンフィグを知る方法 < < アジアのペンギン
●kernelイメージから設定情報を取り出す < < IRORI.ORG

 
 

---

追記：折角なのでその辺のカーネルソースを見てみよう、"kernel/config.c" かな？
 
".config" にある理由と、フラグ立てたら"config.gz" 作るぜ、という事がほのかに匂う。まあはっきり言って全然わかんないが。
 

[sourcecode language='c']/*
* kernel/configs.c
* Echo the kernel .config file used to build the kernel
*
* Copyright (C) 2002 Khalid Aziz
* Copyright (C) 2002 Randy Dunlap
* Copyright (C) 2002 Al Stone
* Copyright (C) 2002 Hewlett-Packard Company
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 2 of the License, or (at
* your option) any later version.
*
* This program is distributed in the hope that it will be useful, but
* WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE, GOOD TITLE or
* NON INFRINGEMENT. See the GNU General Public License for more
* details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software
* Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
*/

#include
#include
#include
#include
#include
#include

/**************************************************/
/* the actual current config file */

/*
* Define kernel_config_data and kernel_config_data_size, which contains the
* wrapped and compressed configuration file. The file is first compressed
* with gzip and then bounded by two eight byte magic numbers to allow
* extraction from a binary kernel image:
*
* IKCFG_ST
*
* IKCFG_ED
*/
#define MAGIC_START "IKCFG_ST"
#define MAGIC_END "IKCFG_ED"
#include "config_data.h"


#define MAGIC_SIZE (sizeof(MAGIC_START) - 1)
#define kernel_config_data_size \
(sizeof(kernel_config_data) - 1 - MAGIC_SIZE * 2)

#ifdef CONFIG_IKCONFIG_PROC

static ssize_t
ikconfig_read_current(struct file *file, char __user *buf,
size_t len, loff_t * offset)
{
return simple_read_from_buffer(buf, len, offset,
kernel_config_data + MAGIC_SIZE,
kernel_config_data_size);
}

static const struct file_operations ikconfig_file_ops = {
.owner = THIS_MODULE,
.read = ikconfig_read_current,
};

static int __init ikconfig_init(void)
{
struct proc_dir_entry *entry;

/* create the current config file */
entry = proc_create("config.gz", S_IFREG | S_IRUGO, NULL,
&ikconfig_file_ops);
if (!entry)
return -ENOMEM;

entry->size = kernel_config_data_size;

return 0;
}

static void __exit ikconfig_cleanup(void)
{
remove_proc_entry("config.gz", NULL);
}

module_init(ikconfig_init);
module_exit(ikconfig_cleanup);

MODULE_LICENSE("GPL");
MODULE_AUTHOR("Randy Dunlap");
MODULE_DESCRIPTION("Echo the kernel .config file used to build the kernel");

#endif /* CONFIG_IKCONFIG_PROC */[/sourcecode]

destroy した zpool を復活させる

Solarisで構築したZFSを他のサーバに移す時は、
「移行元：zpool export」 → 「移行先：zpool import」
とやればよい。exportは省略できるので、移行元がいきなり潰れたとしてもまあOK。
 
 

のように便利なimportだけど、マニュアルによると destroy したプールの復活にも使えると。
ということでやってみた。
 
 


ZFSでは ufs上に作成されたフツーのファイルをデバイスとしてプール構築できるので、それで試そう。

$mkdir /zdev
$mkfile 500m /zdev/file01
$zpool create test01 /zdev/file01

これだけで500MBで作成した1つのファイルをデバイス扱いして「test01」というzpool ができる。
確認してみよう。

$zpool status test01
プール: test01
状態: ONLINE
スクラブ: 何も要求されませんでした
構成:

NAME STATE READ WRITE CKSUM
test01 ONLINE 0 0 0
/zdev/file01 ONLINE 0 0 0

エラー: 既知のデータエラーはありません


$zfs list test01
NAME USED AVAIL REFER MOUNTPOINT
test01 120K 460M 18K /test011

OK。
 

早速だがプールを壊す。
zpoolの操作は何も出力されないので、いつも不安なんだが。。。

$zpool destroy test01
$zpool status test01
cannot open 'test01': no such pool

 
デストロイ完了！「test01」プールは葬られた。
 
 


それではimportして行こう。
"zpool import" とすると接続されているデバイスから使えそうなzpoolを見繕ってくれる。
 
これは"/dev/dsk" を自動で探索してリストアップしてくれるんだけど、今回はデバイスの場所が違うので "-d" オプション で探索場所を指定して実行。

$zpool import -d /zdev
インポートできるプールがありません

普通にやるとこうなる。移行元で export したものはここでリストアップされるが、destroy だとしてくれない。
 
destroy済みも表示するには "-D"オプション、ラージでー だ。

$zpool import -Dd /zdev
プール: test01
ID: *******************
状態: ONLINE (DESTROYED)
アクション: プールの名前または数値識別子を使用してプールをインポートできます。
構成:

test01 ONLINE
/zdev/file01 ONLINE

DESTROYEDなプールが表示された、後は"-f"オプションをつけ、インポートするzpoolを指定するだけだ。
 

$zpool import -fDd /zdev test01

相変わらず何も出力してくれないが、うまくマウントできているはず。。
 
 

$zpool status test01
プール: test01
状態: ONLINE
スクラブ: 何も要求されませんでした
構成:

NAME STATE READ WRITE CKSUM
test01 ONLINE 0 0 0
/zdev/file01 ONLINE 0 0 0

エラー: 既知のデータエラーはありません

$zfs list test01
NAME USED AVAIL REFER MOUNTPOINT
test01 120K 460M 18K /test01

見事復活。ちなみに名前を指定してインポートも可能(引数をもう一個追加する)なので、プールの名前がかぶっていても大丈夫だ。
 
 


ファイルで作る zpool は練習用に色々使えていいですね、mkfileの使いやすさとあいまって良好な感じ。