fedora16トラブル->復旧

2012/6//7に、fedora16でyum -y updateかけたら応答がなくなった。pingは返ってくるけど、ssh/http/vncがつながらない。リブートしても解決しない。（ディスプレイが接続されていない環境に置いていたのでできることがなかった...）

手元に持ってきて調査、復旧を試みた。
1. とりあえず電源ON。GRUBも出るしLinuxの起動メッセージも出るしなんだろう??っと思ったら起動プロセスの途中で停止した。
2. 何度か繰り返したがいつも同じところで止まる
3. rescueモードで起動試みる。上がってくれた。
4. /var/log/messagesを見ると /usr/sbin/sshd: error while loading shared libraries: /lib64/libcrypto.so.10: file too shortと /usr/sbin/sendmail: error while loading shared libraries: /usr/lib64/libssl.so.10: file too shortがが出ていた。/lib64/libcrypto.so.10のファイルサイズを見ると0になっている。opensslのライブラリが壊れてる模様。なぜだろう...
6. ネットワークにつなぐ
7. yum reinstall opensslを試みるが、↑と同じエラーになり接続できない。
8. libcrypto.soはsymbolic linkになっていて、実態はlibcrypto.so.1.0.0jだった。で、libcrypto.so.1.0.0jがサイズ0になっている。幸い、libcrypto.so.1.0.0iが残っていたので、symbolic linkを張り替えた。libssl.soも同様。
9. 再度yum reinstall openssl。接続はできたが、protected multilib versionが出てreinstall不可。installやupdateを試すと、すでに最新でnothing to doとメッセージが出る。
10. 強制インストールする。
yumdonloader openssl; rpm -Uvh --force openssl-1.0.0j-1.fc16.x86_64.rpm
11. 祈りながらsystemctl defaultすると起動してくれた。
12. これは必要かどうかちゃんとわかってないけど、yum reinstall opensslしといた。
13. 最後に再起動して無事sshで接続できることを確認できた！

壊れたときに手間がかかるので、再現試験する余裕は、すくなくとも今は無いなあ。。

fedora16にKVMインストール

参照したページ
http://www.aji.sakura.ne.jp/linux/fedora15_kvm_install.html

1. yum -y install qemu-kvm
2. yum -y install libvirt
3. yum -y install virt-manager
※他にも依存するパッケージが多数入るが、今回はひとつひとつを気にせずに進めました。

KVM入ったか確認
$ lsmod | grep kvm
kvm_intel 126426 0
kvm 351598 1 kvm_intel

libvirtd起動
$ systemctl start libvirtd.service

X WindwowでKVE/QEMU起動
（事前にコマンド実行するユーザーをKVMグループに入れておくこと）
$ qemu-kvm -monitor stdio

次にvirt-mangerを上げようとしたら、
RuntimeError: could not open display
とエラーが出て上がらない。
GUIを管理者権限で実行するためのbeesu（他のディストリだとgksuというのもあるらしい）をインストールし、virt-managerがエラーなく起動できた。

vnc-server

Fedora16にvncサーバーをインストールしたときのメモ。

1. sudo yum -y install tigervnc-server
2. sudo cp /lib/systemd/system/vncserver@.service /lib/systemd/system/vncserver@:1.service
3. sudo vi /lib/systemd/system/vncserver@:1.service で、を自分のユーザー名に変更
4. vncpasswd
5. sudo systemctl start vncserver@:1.service
6. sudo systemctl enable vncserver@:1.service

うまくいかなかったら、とりあえず/var/log/messagesを見る。
/lib/systemd/system/vncserver@:1.serviceを変更したら、
sudo systemctl disable vncserver@:1.service;sudo systemctl enable vncserver@:1.serviceしないと反映されない。

RFC 6585 (2)

511 Network Authentication Required
ネットワーク認証が必要。
ボディに認証ページへのリンクがあると良い（SHOULD）
511のページ自体には認証フォームがないほうがよい（SHOULD）
オリジンサーバーは511を出さないほうがよい（SHOULD）
キャッシュしてはいけない（MUST NOT）
具体例: 無線LANサービスで未認証のユーザーのアクセスを断るとき

セキュリティ考察
428: オプション（必須じゃない）なので、クライアントは衝突検知の仕組みとして使うべきでない（理解しきれてない...）
429: アタックを受けている場合、毎回エラーメッセージを出すのは負荷が高い。セキュリティ的にはドロップするだけのほうがよいよ。
431: これも429同様、ドロップするだけのほうがよい。
511: ドメイン詐称してcookie送れる(わかってない)、TLS/SSLで証明書エラーになる。

tcpdumpでmacアドレスを表示させる

tcpdump -i eth1 -e

manから抜粋
-e Print the link-level header on each dump line.

出力はこんな感じ。
00:54:48.434832 00:50:xx:xx:xx:xx > 00:0c:xx:xx:xx:xx, ethertype IPv4 (0x0800), length 66: 10.0.2.19.80 > 10.0.2.111.2095: Flags [S.], seq 3041195273, ack 3045363001, win 5840, options [mss 1460,nop,nop,sackOK,nop,wscale 4], length 0
※一応macアドレスはxxでマスクしてます

バージョン
$ tcpdump -V
tcpdump version 4.1.1
libpcap version 1.1.1

RFC 6585 (1)

やったね、HTTPのステータスコードが増えたよ！

428 Precondition Required
条件付きGETかPUTしてくれ。
レスポンス（body）に理由を書いた方がいい（SHOULD）
キャッシュサーバーはこのレスポンスをキャッシュしてはいけない（MUST NOT）

429 Too Many Requests
ある時間内で君（クライアント）からのリクエスト数が多すぎたので拒否する（rate limit）
これもエラーの理由を書いた方がいい（SHOULD）
Retry-After（何秒後にリトライしてくれ）を付けてもいい（MAY）
キャッシュしてはいけない（MUST NOT）

431 Request Header Fields Too Large
ヘッダの値が長すぎるので拒否した
長さを縮めて再試行してきたら許可しても良い（MAY）
レスポンスにどのヘッダが長かったのか書いた方がよい（SHOULD）
キャッシュしてはいけない（MUST NOT）
ちなみに、HTTPではヘッダの長さに上限はない。HTTPサーバーの実装に依存する。