シバリ

構築環境のCPUが対応しているか確認

cat /proc/cpuinfo |grep –color vmx

moduleを読み込んでいるか確認

lsmod | grep -i kvm
kvm_intel 54285 0
kvm 333172 1 kvm_intel

読み込まれていなければmodprobeで設定

modprobe kvm
modprobe kvm_intel

パッケージのインストール

yum groupinstall “Virtualization client” “Virtualization Platform” “Virtualization Tools”

ブリッジの設定。kvmは通常NATで動作するようで、使いづらいのでブリッジへ変更します。

cp /etc/sysconfig/network-scripts/ifcfg-eth0 /etc/sysconfig/network-scripts/ifcfg-br0

cat /etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE=eth0
BOOTPROTO=none
HWADDR=00:a0:d1:ee:2c:2c
IPV6INIT=yes
NM_CONTROLLED=yes
ONBOOT=yes
TYPE=Ethernet
UUID=”daa0d323-5288-4c23-8618-90a8cf1cc82b”
BRIDGE=br0

cat /etc/sysconfig/network-scripts/ifcfg-br0
DEVICE=br0
BOOTPROTO=none
HWADDR=00:a0:d1:ee:2c:2c
IPV6INIT=yes
NM_CONTROLLED=yes
ONBOOT=yes
TYPE=Bridge
UUID=”daa0d323-5288-4c23-8618-90a8cf1cc82b”
IPADDR=***.***.***.*** #eth0で設定していたIPをそのまま使います
NETMASK=255.255.255.0
GATEWAY=***.***.***.***　#eth0で設定していたGWを設定します
DNS1=8.8.8.8
USERCTL=no

iptablesで遮断されないように設定

vi /etc/sysctl.conf

net.bridge.bridge-nf-call-iptables = 0
net.bridge.bridge-nf-call-arptables = 0

保存して反映
sysctl -p

ネットワークの再起動をして疎通が出来ればブリッジの設定完了

前回書いたiptablesについて失敗したのでしたためて、後人が同じ轍を踏まないことを祈ります。

RH-Firewall-1-INPUT というチェインにおいてtargetがDROPのラインナンバーを抽出し、削除するという意図のワンライナーです。

iptables  -L RH-Firewall-1-INPUT -n –line-numbers |grep DROP | awk ‘{print $1}’ |xargs -i echo “/sbin/iptables -D RH-Firewall-1-INPUT {}”

これを実行してしまったときに、意図しないルールが削除されてしまいました。

実際に実行されたコマンド

/sbin/iptables -D RH-Firewall-1-INPUT 6
/sbin/iptables -D RH-Firewall-1-INPUT 7
/sbin/iptables -D RH-Firewall-1-INPUT 8
/sbin/iptables -D RH-Firewall-1-INPUT 9
/sbin/iptables -D RH-Firewall-1-INPUT 10
/sbin/iptables -D RH-Firewall-1-INPUT 11
/sbin/iptables -D RH-Firewall-1-INPUT 12
/sbin/iptables -D RH-Firewall-1-INPUT 13
/sbin/iptables -D RH-Firewall-1-INPUT 14
/sbin/iptables -D RH-Firewall-1-INPUT 15
/sbin/iptables -D RH-Firewall-1-INPUT 16
/sbin/iptables -D RH-Firewall-1-INPUT 17
/sbin/iptables -D RH-Firewall-1-INPUT 18
/sbin/iptables -D RH-Firewall-1-INPUT 19
/sbin/iptables -D RH-Firewall-1-INPUT 20
/sbin/iptables -D RH-Firewall-1-INPUT 21

昇順の値を順に削除していくと、番号はshiftしていくのが原因です。下のサンプルで説明します。

$ iptables -L RH-Firewall-1-INPUT -n –line-numbers | egrep “^6|^7”
6 DROP tcp — 10.0.0.1 0.0.0.0/0 state NEW tcp
7 DROP tcp — 10.0.0.2 0.0.0.0/0 state NEW tcp

$ iptables -D RH-Firewall-1-INPUT 6

$ iptables -L RH-Firewall-1-INPUT -n –line-numbers | egrep “^6|^7”
6 DROP tcp — 10.0.0.2 0.0.0.0/0 state NEW tcp
7 DROP tcp — 10.0.0.3 0.0.0.0/0 state NEW tcp

このように7番のルールが6番に繰り上げられます。

こうなってしまうと21番のルールは意図しなかったルールを削除してしまうことになりますね。

そのため一括削除を行う場合は降順にソートする必要があります。

sortのオプションも自然数（-n）で降順（-r）が必須です。気をつけましょう。

/sbin/iptables  -L RH-Firewall-1-INPUT -n –line-numbers |grep DROP | awk ‘{print $1}’ |sort -nr |xargs -i echo “/sbin/iptables -D RH-Firewall-1-INPUT {}”

 

本来実行されるべきコマンドはこっちなのでした。

/sbin/iptables -D RH-Firewall-1-INPUT 21
/sbin/iptables -D RH-Firewall-1-INPUT 20
/sbin/iptables -D RH-Firewall-1-INPUT 19
/sbin/iptables -D RH-Firewall-1-INPUT 18
/sbin/iptables -D RH-Firewall-1-INPUT 17
/sbin/iptables -D RH-Firewall-1-INPUT 16
/sbin/iptables -D RH-Firewall-1-INPUT 15
/sbin/iptables -D RH-Firewall-1-INPUT 14
/sbin/iptables -D RH-Firewall-1-INPUT 13
/sbin/iptables -D RH-Firewall-1-INPUT 12
/sbin/iptables -D RH-Firewall-1-INPUT 11
/sbin/iptables -D RH-Firewall-1-INPUT 10
/sbin/iptables -D RH-Firewall-1-INPUT 9
/sbin/iptables -D RH-Firewall-1-INPUT 8
/sbin/iptables -D RH-Firewall-1-INPUT 7
/sbin/iptables -D RH-Firewall-1-INPUT 6

なぜかlockファイル周りでエラーを吐いて動かない。

supervise: fatal: unable to acquire dnscache/supervise/lock: temporary failure

サービスは仮にdnscacheとしていますが、適宜お使いのサービスに置き換えて下さい。

これで解決

# svc -dx /service/dnscache/
# svc -dx /service/dnscache/log

init.d以下の起動スクリプトとsvscanの起動で多重起動している場合があるので、killすることもありました。

LDAPの設定をすると似たような名前のファイルがあり、混乱しがちです。

各設定ファイルの違いをメモしておきたいと思います。

・LDAPサーバーとしての設定ファイルです。
/etc/openldap/slapd.conf

・pam_ldap、nss_ldap から参照されるファイルです。
nsswitch.conf で 「ldap」 を設定すると、このファイルをみて処理されます。
/etc/ldap.conf

・ldapsearch コマンドを実行する際に -x のみを指定すると、他に必要なパラメータはこのファイルから読みこまれます。　ldapsearch はLDAPサーバとの接続性を確認するものであって、正しくLDAPの情報が参照できても、PAM認証が正常に動くわけではないらしい。
/etc/openldap/ldap.conf

・pamモジュールの設定
/etc/pam.d/system-auth-ac
/etc/pam.d/password-auth-ac
/etc/pam_ldap.conf

・LDAPサーバーに問い合わせるデーモンの設定ファイル
/etc/nslcd.conf

・名前サービスの解決順序を設定するファイル
/etc/nsswitch.conf

・TCPwrapper　slapd: 許可IP
/etc/hosts.allow

・iptables 389空いてる？
/etc/sysconfig/iptables or /sbin/iptables -L -n

上記のファイルを見直せばなんとかなるんじゃないでしょうか。

slapcat -l /path/to/hoge.ldif

slapadd -l /path/to/hoge.ldif

chown -R ldap. /var/lib/ldap

chown -R ldap. /etc/openldap/slapd.d

service slapd start

嵌まったこと

ldapで設定しているグループをsshd_configに設定していたがsshdの再起動をしていなかった。

実際には嵌まってないけど、nslcdの設定はOSの再起動しないと反映しないとか、なんとか。
 

nginxは起動時にDNSを解決したものを保持し続けるらしい。

例えば、upstreamやリバースproxyの設定をhostで指定していると、IPが変わったときにずっと待ち状態になる。

下記の様な設定で回避できるそうだ。

resolverで/etc/resolv.confとは別に名前解決のホストを指定して、validで内部的なキャッシュ有効時間を設定。

http {

　resolver 8.8.8.8 valid=5s;

　　server {

　　　　location / {

　　　　　　proxy_pass http://hogemoge.com;

　　　　}

　　}

}