ここには、取りあえずのTipsを適当に置いておく。

ddコマンドにkill -USR1 を送ると、現在の転送状態が表示される。 知らなかった。

• ここで配られている。

VirtualBoxを利用していると、たまにDisk容量を増やしたくなることがある。というわけで、MacOS-X上のVirtualBoxでWindows Vistaを動かしているDiskを拡張する方法。

1. VirtualBoxの設定コンソールで、新規Diskを作成する
2. VirtualBoxのCommandLine toolで以下を実行
   • VBoxManage clonehd ~/VirtualBox¥ VMs/OriginalDisk.vdi ~/VirtualBox¥ VMs/NewDisk.vdi –existing
3. Virtualboxの設定コンソールで、Storageの設定を、OriginalDisk.vdiからNewDisk.vdiに切り替える
4. Windows Vistaを起動→コントロールパネル→管理ツール→コンピュータの管理→ディスクの管理を選択
   1. 起動したDiskを右クリック→ボリュームの拡張を選択し、容量を増やす

これだけ。

英語と米語でbillionの意味が違うというのは何となく覚えていたが、なんとこういうことだったのか？というのが出てたので転記しておく。

• 元URL
• 日本語の命数法

なお、塵劫記の写本次第で変化があるらしい。ここでは万進を前提（1万単位で表記が変わる）を採用しているものとする。

しかし、これだとその人の背景を知らないと正しい数字を理解できないかも。困ったものである。

これも毎回調べているので、メモにしておく。

# mkdir /path/to/repos
# svnadmin create /path/to/repos
# cd /path/to
# svn import data file:///path/to/repos -m "Initial Import"

毎回調べているので、メモにしておく。

# mkdir /path/to/repos
# cvs -d /path/to/repos init
# cd /path/to/data
# cvs import -m "Strings" modulename vendorTag ReleaseTag

例

# mkdir /REPOS/CVSroot/MUNCHKIN
# cvs -d /REPOS/CVSroot/MUNCHKIN init
# cd ~/Work/code/munchkin
# cvs import -m "Munchkin initial" munchikin seirios 1.0

普通は、こんな事をする必要がないんだが、どうしてもこの手を使わないといけないことがあったので、やり方のメモ。

1. netcatをinstallする
2. catしたいファイルを作成する(for ex. t)
3. nc server port < t

これでなんとかなる。

なお、今時のFreeBSDには nc は標準で入っている

ちょっと気になったのでARP Spoofing対策手法を調べてみた。

本当は、Xen Domain 0 の bridgeを使って、pfで色々頑張るか、bpfで頑張るのが筋だと思うんだけど、今の状態では難しいので、staticにarpを切る方法を。

# see man arp(8)

# arp -s hostname MACaddrs
もしくは
# arp -f filename
# cat filename
hostname1 MACaddr1
hostname2 MACaddr2
....
#

として、MAC Addressをstaticに書いておくのがよさそう。ただ、VRRPとかRIPで頑張っている場合などはちょっと問題。

まぁ、defaultを見てMACアドレス書き換えるような奴が現れたら考えよう。

そうそう、当然だけど、ICMP Router RedirectはDomain0で防御するのが吉です。

いつも忘れてしまうので、メモ

取りあえず、5秒で http://some.where/URL/に飛ぶようにするMETA Tag.

<META HTTP-EQUIV="Refresh" CONTENT="5; URL=http://some/where/URL/" />

ISO/IEC 15408でOSに関する安全性が規定されている。
もともとはTCSEC/ITSECであり、これが統合され、ISO/IEC15408 Common Criteria(CC)として定義された。

CCはセキュリティの評価基準であり、7段階の評価保証レベル(Evaluation Assurance Level / EAL)が規定されている。

CCは日本でも取り込まれ、JISECとして公表されている。

Mean Time Between Failureの略であり、機器もしくはパーツ単位での単体平均故障時間を表す。
MTBFが長いほど機器は故障しにくいことを意味する。
このMTBFを用いて、機器の保守対応や予備機材購入、システムの冗長化手法を数値化して検討することが可能になる。

機器の故障確率はMTBFを元に計算できる。
MTBFが同一の機器の場合、単体MTBFを機器数で割った値が同一機器群における(少なくとも1台が壊れるまでの)時間となる。
たとえば、MTBFが3年の機器が36台あるとすると、
3年 ÷ 36台 ＝ 36ヶ月 ÷36台 ＝ 1ヶ月／台
となり、1ヶ月に1台程度の頻度で機器が故障する可能性が高いと想定できる。

システム全体の故障機器発生確率を求める場合の例を以下に記載する。

例）故障確率がそれぞれ 1台/1ヶ月、1台/2ヶ月、1台/3ヶ月である機器群によって構成されたシステムの故障確率は
 1/1 + 1/2 + 1/3 = 11/6
従って、システム中の機器が故障する確率は6ヶ月に11台

以上の計算から、上記例の場合、おおむね1月に2台弱の機器が故障すると予測できる。
但し、上記計算は、「何が壊れるのか」は述べていない。また、当然「実際に壊れる台数」を述べている物でもない。 あくまで確率であることに注意。

mtreeを使う。マニュアルを見ても良くわからなかったので、適当に色々やってみる。

取りあえず、Hash Listを作成するなら

# mtree -c -K sha1digest -p . > HashList

取りあえず比較するなら

# mtree -p [Dir] < HashList

でなんとかなる。

今回InstallしたPCでは、kernelがこんなWarningを出した。

vendor 0x8086 product 0x0326 (interrupt system, interface 0x20, revision 0x09) at pci2 dev 0 function 1 not configured

で、ちょっと調べてみた。

こういうときはGoogle様のお告げを聞こう。

なんかDriver Agent(http://listing.driveragent.com/)というサイトがある。
ここで、ちまちま調べれば、必要な情報が見つかるだろう。（でも重たい）
これよりも、The PCI ID Repository(http://pci-ids.ucw.cz/)の方がいい。早いし。

これで、8086 → Intel がわかり、0326 → 6700/6702PXH I/OxAPIC Interrupt Controller A であることがわかる。

ああ、NetBSDでは対応していないっぽいなぁ。

RemoteのSSL接続サーバーの証明書の情報を見る方法

openssl s_client -connect [URL]:443 < /dev/null 2> /dev/null | openssl x509 -noout -subject -dates