2009.08.16
smbclientよりmount_smbfsでリモートのWindowsのディレクトリーをマウントする方が、良く使われると思われるので、これも書いておく。
# mount_smbfs -I 192.168.1.100 //nakamura@hogehoge/share /mnt
Password:xxxxxx
# ls /mnt
Thumbs.db calendar.tcl mn8300.pdf pspbrwse.jbf satoru
# umount /mnt
こちらの方が使い易いと思うのだが、好みの問題か。
極めて簡単なのだが、やはりしばらく使わないと使用方法を忘れてしまう。
まず、Windows XPで動いているデスクトップPCのホスト名がhogehogeとすると、下記のコマンドで、アクセス可能なディレクトリーを表示させる。
# smbclient -I 192.168.1.100 -L hogehoge/C$ -U nakamura
Password:xxxxxxx
Domain=[HOGEHOGE] OS=[Windows 5.1] Server=[Windows 2000 LAN Manager]
Sharename Type Comment
--------- ---- -------
E$ Disk Default share
EPSONPM- Printer EPSON PM-A850
IPC$ IPC Remote IPC
D$ Disk Default share
print$ Disk プリンタ ドライバ
share Disk
ADMIN$ Disk Remote Admin
C$ Disk Default share
Domain=[HOGEHOGE] OS=[Windows 5.1] Server=[Windows 2000 LAN Manager]
Server Comment
--------- -------
Workgroup Master
--------- -------
この中で、共用設定をしているディレクトリーはE Drive内に作ったshareだけなので、そこをアクセスしてみる。
# smbclient //hogehoge/share
Password:
Domain=[HOGEHOGE] OS=[Windows 5.1] Server=[Windows 2000 LAN Manager]
smb: > ls
. D 0 Sun Jun 28 16:57:47 2009
.. D 0 Sun Jun 28 16:57:47 2009
calendar.tcl A 3234 Sat Jan 17 09:05:48 2009
mn8300.pdf A 1471542 Sat Sep 27 01:01:34 2003
pspbrwse.jbf A 25967 Sun May 17 09:56:50 2009
satoru D 0 Sun Jun 28 16:57:21 2009
Thumbs.db AHS 97280 Tue Aug 4 20:39:23 2009
38534 blocks of size 2097152. 29452 blocks available
smb: > q
#
2009.03.28
FreeBSDやLinuxでは、bootの過程で何が起きたかをdmesgコマンドで見ることが出来る。
しかしながら、表示内容が長くなると最初の部分が消えて見ることができない。私の例では、Firewallを設定して韓国、中国からのアクセスをブロックした途端に、その表示の長さのために、boot過程は全く見えなくなってしまった。
これを解決するためには、dmesgのバッファーサイズを広げればよいが、このためには、MSGBUF_SIZE というオプションを指定してカーネルの再構築をする必要がある。
/usr/src/sys/i386/confに移動して、GENERICを別名(MYPCなど)でコピーして、編集する。
# cd /usr/src/sys/i386/conf
# cp GENERIC MYPC
# vi MYPC
そして、下記のようにoptionsでMSGBUF_SIZE=xxxxxを追加する。
サイズはデフォルトでは4096であり、この整数倍に設定する。
options STOP_NMI # Stop CPUS using NMI instead of IPI
options AUDIT # Security event auditing
options MSGBUF_SIZE=409600
これで、kernelをコンパイルして入れ替えれば、バッファーサイズが増え、全てのメッセージを見ることが出来るようになる。
2009.03.07
FreeBSDではATAインターフェイスをコマンドでattach, detach出来る機能があり、gmirror構成したディスクの1台が壊れても、サーバの運用を続けながらhot replaceで交換きる。まず、root権限でatacontrolでlistを表示してみる。
# atacontrol list
ATA channel 0:
Master: acd0 <TSSTcorp CD-ROM TS-H192C/B504> ATA/ATAPI
Slave: no device present
ATA channel 1:
Master: no device present
Slave: no device present
ATA channel 2:
Master: ad4 <ST3808110AS/3.AJJ> Serial ATA v1.0
Slave: no device present
ATA channel 3:
Master: ad6 <Hitachi HDS721680PLA380/P21OABEA> Serial ATA II
Slave: no device present
使用しているサーバはHPのProLiant M110であり、IDEのPrimaryとSecondaryがATA channel 0とATA channel 1として表示され、SATAがそれぞれATA cahnnel 2とATA channel 3として表示されている。
この例ではATA channel 2のMasterにad4が接続されており、ATA channel 3にad6が接続されている。
atacontrolでは、channel単位にattach, detachができるので、例えばATA channel 3につながっているad6を交換したいのであれば、このチャネルをdetachする。detachしてリストを表示すると、
# atacontrol detach ata3
# atacontrol list
ATA channel 0:
Master: acd0 <TSSTcorp CD-ROM TS-H192C/B504> ATA/ATAPI
Slave: no device present
ATA channel 1:
Master: no device present
Slave: no device present
ATA channel 2:
Master: ad4 <ST3808110AS/3.AJJ> Serial ATA v1.0
Slave: no device present
ATA channel 3:
Master: no device present ← HDDが消えた
Slave: no device present
となり、ad6として動作していたHitachiの160GBのドライブが消える。
ここで、このドライブをサーバ運用のまま交換し、attachする。
# atacontrol attach ata3
# atacontrol list
ATA channel 0:
Master: acd0 <TSSTcorp CD-ROM TS-H192C/B504> ATA/ATAPI
Slave: no device present
ATA channel 1:
Master: no device present
Slave: no device present
ATA channel 2:
Master: ad4 <ST3808110AS/3.AJJ> Serial ATA v1.0
Slave: no device present
ATA channel 3:
Master: ad6 <Hitachi HDP725025GLA380/GM2OA5CA> Serial ATA II
Slave: no device present
ここの例では、Hitachの250GBのドライブに交換した。
あとはgmirrorを再構成するだけである。
# gmirror statua ← statusの表示
Name Status Components
gmirror/gm0 DEGRADED ad4
# gmirror forget gm0 ← 構成情報のリセット
# gmirror status ← 再度statusの確認
Name Status Components
gmirror/gm0 COMPLETE ad4 ← DEGRADEDからCOMPLETEになる
# gmirror insert gm0 ad6 ← ad6の組み込み
Name Status Components
gmirror/gm0 DEGRADED ad4
ad6(1%) ← 進行が%で表示される
あとは、同期化が進行して完了する。
2009.02.26
gmirrorでミラー構成が出来たので、故障状態を起こさせて、回復を試みる。
(1) FreeBSDを普通に起動した後に、最初にFreeBSDをインストールしたHDD(ad0)の供給電源ケーブルをHDDより引き抜いた。そのままでは、何も起こらなかったがviを起動しようとしたら、良く覚えてないがad0に書き込めないと言うようなメッセージが表示された。
下記のようにステータスを表示させると、DEGRADEDになっていた。
# gmirror status
Name Status Components
gmirror/gm0 DEGRADED ad2
もちろん、この状態でもサーバは問題なく動作を続けている。
(2) Shutdownして起動すると正常に立ち上がった。
(3) もう一度Shutdownしてad0に電源ケーブルをつなぎ、起動する。
ログインしてstatusを見ると、既に同期化が始まっていた。
ad0に全く新しいディスクを取り付けて起動すると、(5)の状態になるはずである。
# gmirror status
Name Status Components
gmirror/gm0 DEGRADED ad2
ad0(1%) ← 進行が%で表示される
(4) gmirror作成で使用したLivefs CDで起動して、ad0に書き込まれたメタデータをクリアした。
Fixit# chroot /dist
Fixit# kldload geom_mirror
Fixit# exit
Fixit# gmirror stop gm0 ← gmirrorの停止
Fixit# gmirror clear ad0 ← ad0のメタデータのクリア
(5) Livefs CDを抜いて普通に起動してステータスを確認し、今度は同期化は始まらず、ミラーはDEGRADED状態であることを確認する。
# gmirror status
Name Status Components
gmirror/gm0 DEGRADED ad2
(6)gm0の構成情報をリセットする。そしてステータスを確認する。DEGRADEDがCOMPLETEに変わる。
# gmirror forget gm0 ← 構成情報のリセット
# gmirror status
Name Status Components
gmirror/gm0 COMPLETE ad2
(7) ここで、ad0を組み込む。
# gmirror insert gm0 ad0 ← ad0の組み込み
GEOM_MIRROR:Device gm0:rebuilding provider ad0.
(8)上記メッセージの後、同期が始まり30分ほどで完了した。
# gmirror status
Name Status Components
gmirror/gm0 DEGRADED ad2
ad0(2%) ← 進行が%で表示される
# gmirror status
Name Status Components
gmirror/gm0 COMPLETE ad2
ad0