※お断り

• 基本的に無保証です。自己責任にてお試しください。
• ご質問や問題点のご指摘は大歓迎です。何かありましたらお気軽にご連絡ください。

目次

• OpenVZでJavaMVが起動しない場合の対策
• XenHVMでCD-ROMイメージを入れ替える
• Fedora10/GDM+VNCサーバ 環境でX11フォワーディングに失敗する
• Kerberos認証利用中、SSH接続時になぜかチケットがフォワードされない
• PostgreSQLの認証にKerberosを利用する
• Xen domUをタグVLAN・bondingに接続する
• パケットの行き先毎に送信速度を制限する

OpenVZでJavaMVが起動しない場合の対策

OpenVZを利用していて、JavaVMが起動できない場合、最大メモリ容量を制限すると解決するかもしれません。
OSレベル仮想化を採用したVPSサービスでJavaが起動できない！と嘆いている方、お試しあれ...
(はい、私、嘆いていました...)

ava起動コマンド

[user@www ~]# java -Xmx256m -jar ******

この例では、最大256MBにメモリを制限しています。
通常、いくらメモリをアロケートしても、実際に書き込みを行わなければ物理メモリは消費されないわけですが、
OSレベル仮想化ではそうはいかないようです...。
ゆえに、Apache2のworkerMPMもアウトなんですよね...。

XenHVMでCD-ROMイメージを入れ替える

Xen HVMにてWindows(CD-ROM版)をインストールしようとすると、ディスク交換を行う必要があります。
しかし、単純にディスクを交換しただけでは、交換後のディスクが認識されません。
このような場合、QEMUコンソールから、ディスクの交換を行うことで解決することができます。

ディスクの交換を行うには、まずQEMUコンソール画面へ移動します。移動方法は以下の通りです。
１、フレームバッファ -> QEMUコンソール
　→“CTRL+ALT+2”
２、QEMUコンソール -> フレームバッファ
　→“CTRL+ALT+1”

ディスクの交換は、QEMUコンソール上で次のコマンドを用いて行います。

changeコマンド

(XenHVM) change hdc <ディスクイメージ> raw

※ディスクイメージにはisoファイル指定でなくても、実デバイス（/dev/cdrom等）でもかまいません。
※ディスクイメージの後ろに"raw"オプションを付けないと、正しくイメージが認識されないかもしれません。

changeコマンドを発行後、フレームバッファ画面へ移動すると、交換したディスクが認識されているかと思います。
なお、ディスクの状態は「info block」コマンドにて確認できます。

ディスク状態の確認

(XenHVM) info block ←交換前の状態
hda: type=hd removable=0 file=********.disk
hdc: type=cdrom removable=1 locked=0 file=*******.disc1.iso
(XenHVM) change hdc *******.disc2.iso raw
(XenHVM) info block ←交換後の状態
hda: type=hd removable=0 file=********.disk
hdc: type=cdrom removable=1 locked=0 file=*******.disc2.iso

Fedora10/GDM+VNCサーバ 環境でX11フォワーディングに失敗する

Fedora10 GDM+VNCServer (Xvnc on XDMCP)環境で、ssh -Xで他サーバのディスプレイを飛ばそうとすると、

Warning: No xauth data; using fake authentication data for X11 forwarding.

が出てしまい、XAuthによるディスプレイ認証が失敗します。
いまいち詳細は分からないのですが、xauth listの結果が変わったために生じる現象のようです。

on Fedora10

> xauth list
#ffff#3132372e302e302e31#:1 MIT-MAGIC-COOKIE-1 ************************

on Fedora8

> xauth list
127.0.0.1:1 MIT-MAGIC-COOKIE-1 ************************

このように、Fedora8では127.0.0.1:1と素直なASCII文字列としてXホストが表示されますが、
Fedora10では#ffff#3132372e302e302e31#:1という、16進文字列として表示されます。
（なぜか、Xvncを使っているとき(というより、XDMCP on GDMのとき？）のみで、
使っていないときは普通にホスト名/unix:0としてXホストが表示され、フォワーディング問題も発生しない。）
sshクライアントはX11 MagicCookieの検索をプレーンなASCII文字列で行うため、結果的にXAuth認証に失敗する、という現象が生じます。
(検索に失敗する様子はssh -vvで確認可能）
しかし、実はこの16進文字列、単に"127.0.0.1"をバイナリとみなしhexdumpした結果と等価だったりします(^^;;
そこで、sshから受け取った引数のうち、ホスト名部分だけを勝手に16進文字列に変換した状態でxauthへ渡すラッパーを作ってみました。
このラッパーを挟むことで、問題なくディスプレイが飛ぶようになります。

xauthラッパー (/usr/bin/xauth.ssh)

#!/usr/bin/perl

my $cmd = $ARGV[0];
my $dis = $ARGV[1];

if ($dis =~ /(\d+\.\d+\.\d+\.\d+):(.+)/){
  $dis = '#ffff#'.unpack('H*',$1).'#:'.$2;
}

my $w = "bash -c \"xauth \"$cmd\" \"$dis\"\"";
system($w);

これを、/usr/bin/xauth.sshへ保存し、パーミッションを755にセットします。
その後、/etc/ssh/ssh_configの"Host *"以下、もしくは~/.ssh/configへ、

SSHクライアント設定 (/etc/ssh/ssh_config)

xauthlocation /usr/bin/xauth.ssh

を入れれば完了です。以降sshはxauth.sshをxauthの代わりに使うようになり、
フォワーディングに成功するようになるのではないかと思います。
もし不具合等発見された場合は、ぜひご連絡ください。

Kerberos認証利用中、SSH接続時になぜかチケットがフォワードされない

1. /etc/ssh/sshd_config中に、次の設定を記述。（GSSAPI経由の認証を有効化）
   
   /etc/ssh/sshd_config

   GSSAPIAuthentication yes
   GSSAPICleanupCredentials yes
   
2. ローカル認証(PAM含む)よりKerberos認証を優先させたい場合は、次の設定を記述。
   
   /etc/ssh/sshd_config

   KerberosAuthentication no
   KerberosTicketCleanup yes
   
3. ~/.ssh/config にチケットフォワーディングを許可する設定を記述
   
   (これを忘れると２台め以降へのログイン時パスワードが必要になるばかりでなくNFSv4 with Kerberosのマウントができなくなる。)
   ~/.ssh/config

   GSSAPIDelegateCredentials yes
   GSSAPIAuthentication yes
   

PostgreSQLの認証にKerberosを利用する

1. /var/lib/pgsql/data/postgresql.confにKerberosの設定を記述
   
   /var/lib/pgsql/data/postgresql.conf

   # Kerberos
   krb_server_keyfile = '/var/lib/pgsql/data/pgsql.krb5.key'               # (change requires restart)
   krb_srvname = 'postgres'                 # (change requires restart)
   krb_server_hostname = 'db1.****.****.jp' # empty string matches any keytab entry
                                            # (change requires restart)
   #krb_caseins_users = off                 # (change requires restart)
   
2. kadminでpostgresのprincipalを作成し、キーを1で指定した場所に保存する
   
   コマンド

   > kadmin
   Authenticating as principal root/admin@****.*****.JP with password.
   Password for root/admin@****.*****.JP:
   kadmin: addprinc -randkey postgres/db1.****.****.jp
   kadmin: ktadd -k /var/lib/pgsql/data/pgsql.krb5.key postgres/db1.****.****.jp
   kadmin: q
   
3. キーの所有権をpostgresに変更
   
   （これを忘れると正しく設定していても認証に失敗する）
   コマンド

   chown postgres:postgres /var/lib/pgsql/data/pgsql.krb5.key
   

Xen domUをタグVLAN・bondingに接続する

結論から言うと、Xenのブリッジスクリプトを利用しなければOKです。
あのスクリプトはちょっと変な挙動をしますので、
手動でブリッジを立ち上げるスクリプトを書くのがもっとも確実かつ安全です。
なお、この例ではタグVLANを例に取りますが、eth0.*を、bond0.*に置き換えることで、そのままボンディング+タグVLAN対応となります。

1. dom0上のXenブリッジ起動設定を無効にします
   
   /etc/xen/xend-config.sxp

   (network-script network-bridge)
   ↓
   (network-script /bin/true)
   
2. /root/以下に次のようなスクリプトを書きます。
   　　ここでは、既にeth0.4000、eth0.4001、というVLANインターフェースがあるものとします。
   このVLANインターフェースは 「/etc/sysconfig/netowrk-scripts/ifcfg-eth0.4000」
   「/etc/sysconfig/netowrk-scripts/ifcfg-eth0.4001」
   で作成した普通のVLANインターフェースです。
   　　また、それぞれが所属するブリッジはBridge1、Bridge2とします。
   
   bridge.sh

   #!/bin/sh
   
   brctl addbr Bridge1
   brctl addif Bridge1 eth0.4000
   ifconfig Bridge1 up
   echo "StartingBridge - Bridge1"
   
   brctl addbr Bridge2
   brctl addif Bridge2 eth0.4001
   ifconfig Bridge2 up
   echo "StartingBridge - Bridge2"
   
3. iptablesでBridge間の通信を許可します
   ここでは次のような設定スクリプトで通信を許可し、同時にスプーフィング対策も行います。
   
   iptables.sh

   #!/bin/sh
   
   /etc/rc.d/init.d/iptables stop
   
   #---------------------
   # デフォルト設定
   #---------------------
   iptables -P INPUT   DROP   # 受信はすべて破棄
   iptables -P OUTPUT  ACCEPT # 送信はすべて許可
   iptables -P FORWARD DROP   # 通過はすべて破棄
   
   #---------------------
   # セキュリティ設定
   #---------------------
   
   # SYN Cookiesを有効にする
   sysctl -w net.ipv4.tcp_syncookies=1 > /dev/null
   sed -i '/net.ipv4.tcp_syncookies/d' /etc/sysctl.conf
   echo "net.ipv4.tcp_syncookies=1" >> /etc/sysctl.conf
   
   # ブロードキャストアドレス宛pingには応答しない
   sysctl -w net.ipv4.icmp_echo_ignore_broadcasts=1 > /dev/null
   sed -i '/net.ipv4.icmp_echo_ignore_broadcasts/d' /etc/sysctl.conf
   echo "net.ipv4.icmp_echo_ignore_broadcasts=1" >> /etc/sysctl.conf
   
   
   #---------------------
   # INPUT設定
   #---------------------
   
   # localhostからの接続は全て許可
   iptables -A INPUT -i lo -j ACCEPT
   
   # 接続が確立したコネクションに対する応答は許可
   #iptables -A INPUT -p tcp ! --syn -m state --state NEW -j DROP
   iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
   
   # IDENT(ポート113)はReject ※サーバーのレスポンス低下対策
   iptables -A INPUT -p tcp --dport 113 -j REJECT --reject-with tcp-reset
   
   #---------------------
   # OUTPUT設定
   #---------------------
   iptables -A OUTPUT -p udp --dport 137:139 -j DROP
   iptables -A OUTPUT -p tcp --dport 137:139 -j DROP
   iptables -A OUTPUT -p tcp --dport 445 -j DROP
   
   #---------------------
   # BridgeNetwor
   #---------------------
   iptables -A FORWARD -i Bridge1 -o Bridge1 -j ACCEPT
   iptables -A FORWARD -i Bridge2 -o Bridge2 -j ACCEPT
   
   #---------------------
   # 各種サーバ設定
   #---------------------
   
   # SSHサーバー
   iptables -A INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT
   
   #----------------------
   # ログ記録
   #----------------------
   
   #iptables -A INPUT -m limit --limit 1/s -j LOG --log-prefix '[IPTABLES INPUT] : '
   iptables -A INPUT -j DROP
   
   #iptables -A FORWARD -m limit --limit 1/s -j LOG --log-prefix '[IPTABLES FORWARD] : '
   iptables -A FORWARD -j DROP
   
   
   #---------------------
   # 設定保存/有効化
   #---------------------
   
   # 再起動時にも上記設定が有効となるようにルールを保存
   /etc/rc.d/init.d/iptables save
   
   # ファイアウォール起動
   /etc/rc.d/init.d/iptables start
   
   このスクリプトに実行権を持たせて実行することで、Bridge内でのパケットフォワーディングが開始されます。
   ここではレイヤ２・レイヤ３レベルでのフィルタリングが定義出来ますので、BridgeをL2スイッチ代わりに利用することが出来ます。
   
4. boot.shを起動時に実行されるよう/etc/rc.d/rc.localへ登録します。
   
   コマンド

   echo "/root/boot.sh" >> /etc/rc.d/rc.local
   
5. スクリプトに実行権限を持たせます。
   
   コマンド

   chmod 755 /root/boot.sh
   

以上で完了です。再起動するか、boot.shを実行すると、VLANインターフェースが接続されたブリッジが出来上がります。
あとはここにdomUを接続していくだけです。
次に接続するためのdomU起動用設定ファイルの例を示します。

起動設定ファイル例

name = "DomUTest"
memory = "4096"
disk = [ 'phy:DomUServers/DomUTest,xvda,w', ]
vif = [ 'mac=00:00:01:00:00:01, bridge=Bridge1',
        'mac=00:00:01:01:00:01, bridge=Bridge2' ]

uuid = "00000000-0000-0000-0000-000000000001"
bootloader="/usr/bin/pygrub"
vfb = ["type=vnc,vncunused=1" ]

vcpus=8
on_poweroff = 'destroy'
on_reboot   = 'restart'
on_crash    = 'restart'

この例では、メモリ4GB、8コア、Bridge1、Bridge2に接続された２つのNICを搭載したdomU仮想マシンを立ち上げています。
この方法であればブリッジに好きな名前をつけることが出来ますので、非常に便利です。
この方法の難点は、ネットワークスクリプトをrestartしたとき、もう一度boot.shを実行しなければいけない点にありますが、
Xen附属のnetwork-bridgeスクリプトに任せるよりはましなのではないかと思います。
パフォーマンス的にも良好で、Supermicroマザー（BroadCOMチップ)、CentreCOM L2スイッチの組み合わせ（非ボンディング、タグVLAN）
で異なる物理サーバ上の仮想サーバ間通信は800MBps程度と十分な速度が出ますし、domU上ではタグVLANを意識する必要もありませんので、非常に便利です。

パケットの行き先毎に送信速度を制限する

tc(Traffic Control)コマンド+HTBを使います。

1. 次のようなスクリプトを作成します。ここでは30MBps、1000MBpsの２つのクラスを用意し、
   デフォルトは30MBps、192.168.0.0/24、172.16.0.0/16へのパケットのみ1000MBpsで送信します。
   
   /root/scripts/QoS.sh

   tc qdisc add dev eth0 root handle 1:0 htb
   tc class add dev eth0 parent 1:0 classid 1:1 htb rate 30mbit
   tc class add dev eth0 parent 1:0 classid 1:2 htb rate 1000mbit
   tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32 match ip dst 192.168.0.0/24 flowid 1:2
   tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32 match ip dst 172.16.0.0/16 flowid 1:2
   tc filter add dev eth0 protocol ip parent 1:0 prio 10 u32 match ip dst 0/0 flowid 1:1
   
2. これを起動時に実行できるよう/etc/rc.d/rc.localに登録します
   
   コマンド

   > echo "/root/scripts/QoS.sh" >> /etc/rc.d/rc.local
   > chmod 755 /root/scripts/QoS.sh
   

これで、再起動する、もしくはQoS.shを実行すると、eth0に対して帯域制限が開始されます。
設定状態を確認するには、次のコマンドを利用します。

コマンド

> tc filter show dev eth0

また、設定を削除するには、addをdelに変えて後ろから実行していけばOKです。