muttを設定する
ちょっとミーハーな心持ちで、以前挫折したCLIのメーラーをインストールしてみる。
一応
GnuPG を使えるメーラーを探す - ログ日記
の続き。
大量のメールを処理できるNeomutt - Solist Work Blog
ここを読んでNeomuttが気になったけど
NeomuttでGmailにOAuth2.0する - Qiita
Debian(buster) の場合はMuttよりNeomuttの方が古いっぽいので。
bullseye なら大丈夫っぽい。
muttをインストールすると
/usr/share/doc/mutt/examples/mutt_oauth2.py
があるので、どこかのbinにコピーしてくる。
python のファイルの上の方に registrations 変数があって接続情報が書かれているので、直接編集。
ENCRYPTION_PIPE にもGPGで使っているメールアドレスを書く。
/usr/share/doc/mutt/examples/mutt_oauth2.py.README を読みつつ
Mutt - ArchWiki
ここも読みながら muttrc を設定する。
先にGoogleのAPIでoauthのIDを発行しておく。テスト用でいけた。
とりあえず接続テストは
./bin/mutt_oauth2.py user@example.com.tokens --verbose --authorize
のようにして質問に答えていってから
./bin/mutt_oauth2.py user@example.com.tokens --verbose --test
で確認。
muttrcでのGmailの設定は
set from="user@example.com"
set realname="User Name"
set imap_user="user@example.com"
set folder="imaps://imap.gmail.com/"
set smtp_url="smtps://${imap_user}@smtp.gmail.com:587/"
set imap_authenticators="oauthbearer:xoauth2"
set imap_oauth_refresh_command="/home/user/bin/mutt_oauth2.py /home/user/.mutt/${imap_user}.tokens"
set smtp_authenticators=${imap_authenticators}
set smtp_oauth_refresh_command=${imap_oauth_refresh_command}このように書いた。
あとは設定を適当なサンプルから持ってきた。
set spoolfile = "+INBOX" set imap_check_subscribed set hostname = gmail.com set mail_check = 120 set timeout = 300 set imap_keepalive = 300 set postponed = "+[GMail]/Drafts" set record = "+[GMail]/Sent Mail" set trash = "+[GMail]/Trash" set header_cache=~/.mutt/cache/headers set message_cachedir=~/.mutt/cache/bodies set certificate_file=~/.mutt/certificates set signature =~/.mutt/signature
Gmailを見れるようにはなった。
でも、使えるかと言われると…うーん。
初めてvimを起動して終了方法すら分からなかったときような感じ。
Claws MailじゃなくてSylpheedを試してみようか。
DebianでVMwareが遅い問題は解決してなかった
https://n314.hatenablog.com/entry/2021/01/28/104312
こっちの設定をやってしばらく使ってるけど、やっぱりVMwareの起動直後はkcompactd0がフルにCPUを使って3分ぐらいほとんど操作できない。
/sys/kernel/mm/transparent_hugepage/defrag の設定は madvise にしていた。これってアプリケーションが必要だからデフラグを要求してるってことだよねえ…。
VMware用にメモリを12GB設定しているから、その分のデフラグは必要だってことなんだろうか。
固まるのは起動時だけで、最初にちょっと待てば後は大丈夫なんだけど。
Debian の VMwareが遅いのでtransparent_hugepageを無効化する
LinuxのVMwareでWindowsを動かしていて、大きなファイルを開いたりすると固まるときがある。
kcompactd0 が CPU 100% になっている。vmwareも600%になっていたりする。
メモリは十分あってLinuxもWindowsもfreeが残っている。
transparent_hugepage を never にしてオフにすれば良い？
少し改善した気がする。
echo never > /sys/kernel/mm/transparent_hugepage/enabled echo never > /sys/kernel/mm/transparent_hugepage/defrag
defragだけneverにしてenabled にしてtransparent_hugepage/enabledは madvise にでも設定すれば良い？
まだあまり意味が分かってない。
説明だけ読むと、有効の方が良さそうな機能なんだけど。
Fixing khugepaged CPU usage VMware Workstation · GitHub
Solved: Client machines freeze momentarily but regularly -... - VMware Technology Network VMTN
Linux Host/Windows 10 Pro 64 Guest - Host Freezes ... - VMware Technology Network VMTN
VMwareを使うならオフにするのが良さそうだ。
Debian の rc.local は今はsystemd管理になっているっぽいので有効化する。
【2020年最新版】Debian 10 Busterに/etc/rc.localを導入する
起動が数秒遅くなった。
# 2/4 追記
/etc/rc.local の実行ファイルがある場合は自動でサービスが起動されるっぽい。
あと、rc.localが実行された場合はスピーカーがオンにならなかった。何かが干渉している？とりあえずオフに戻してブートパラメーターで設定した。
vi /etc/default/grub
GRUB_CMDLINE_LINUX_DEFAULT="transparent_hugepage=never"
update-grub
Linux Kernel 5.8 で Ansible の service, systemd がエラーになる
めっちゃハマった。
別のPCからAnsibleをそのまま持ってきてコンテナに実行したらエラーになった。
RUNNING HANDLER [common : reload nginx] ****************************************************************
[WARNING]: The service (nginx) is actually an init script but the system is managed by systemd
fatal: [app-php.local]: FAILED! => {"changed": false, "msg": "Service is in unknown state", "status": {}}ansibleのserviceをsystemdにしてもダメ。
変わったのはカーネルバージョンのみで、OSのバージョンは同じ。
Debianでカーネルだけ5.8にしたものでエラーが出た。
カーネル5.8のsystemdのバグらしい。
コンテナだから中のゲストカーネルも同じ5.8になっちゃうよねえ…。
現段階では、カーネルバージョンを下げるか、少し待って最新版をDLするか、修正を自分で適応させるしかないっぽい。
まだissueのスレッドは進行中。
２日前に回避用の修正はプルリクされたようだ。
github.com
カーネルのバージョン5.7にできれば一番良いんだろうけど、公式パッケージがないとつらい。buster-backports のカーネルって新しいカーネルが出るたびにバージョンアップされるのかな？
5.9になったら直っていることを祈りつつ。
ひとまず、設定が進まないのでパッケージで入れたansibleの /usr/lib/python3/dist-packages/ansible/modules/system/systemd.py を手動修正した。
Lenovo ThinkPad P17 に Debianをインストールする
今までMacBook Pro の VMware Fusion で Linux を使っていたんだけど、もう直接Linuxを使った方がいいかと思って。
新しいノートパソコンはLenovoのでかいやつ。17インチ。
www.lenovo.com
ThinkPad P17 はWindows用のドライブとは別に、空のSSDがもう一つ付けた。メモリも増やし、ディスプレイも3840 x 2160 に変更した。
これをDebian 10 とWindows 10 でデュアルブートにする。デュアルブートで設定するのは15年ぶりぐらい。
一つ前のバージョンなら、ここに公式のセットアップガイドがある。
https://download.lenovo.com/pccbbs/mobiles_pdf/lenovo_thinkpad_p53_p73_debian10_installation_v1.0.1.pdf
UEFI BIOSのデザインが全然変わっているが、項目はだいたい同じなのでここの通りに設定する。
注意点は、Windowsも使うなら、先にWindowsのBitLocker ディスクの暗号化を解除しておく。
これをやらずにBIOSのセキュリティを無効にしてしまうと、Windowsのディスクが読み込めなくなる。幸い、Windowsのアカウントでログインして回復キーを取得するように案内されるので、その通りにして事なきを得た。アカウントの種類によっては詰んでた可能性がなきにしもあらず。
Windows 10 Homeだったので適当にoutlookのメールを新規登録してアカウントは作ってあった。
Boot Order は、USB HDD？とりあえずUSB系を上に移動する。
「Section 2 – Discrete vs Hybrid Graphics」のハイブリッドもやめて、「Discrete Graphics」を選んでnvidiaだけを使う設定にする。
DebianのインストーラーはUSBにコピーする。
4.3. USB メモリでの起動用ファイルの準備
# cp debian.iso /dev/sdX # sync
特にddとかツールとかではなく、ただコピーする。（mountはしない）
最近のインストーラーは、これだけで旧BIOSとUEFIと両方に対応したインストールメディアが作れるみたい。
有線LANは繋いでおく。ポートがあって良かった。有線がなかったら更に面倒なことになっていた。
taskselでデスクトップはKDEを選ぶ。本当はLXDEかMATEが良かったんだけど、スケーリング解像度に対応しておらずフォントやメニューのサイズがおかしくなるので、諦めてKDEに。
nvidia-settings でも倍率を設定できるけど、ダメっぽかった。
空のディスクで一つのパーティションでインストールする。
ドライバはPDFの通りにせずに、apt install nvidia-driver を入れる。Wi-Fiドライバはまだ入らない。
en:users:drivers:iwlwifi [Linux Wireless]
カーネルを5.2以上にバージョンアップする必要がある。
sources.list に backports を書いて、linux-image-5.8 を入れる。
細かいバージョンごとに全部選べるみたいだけど、昔はこんなのあったっけ？新しいカーネルが順次追加されていってるようで、これならDebianでハードウェアが認識せずに困ることは無くなるのかも。
取り敢えず一覧の中から新しい Linux Kernel 5.8.0-0.bpo.2-amd64 をインストールすることにした。
カーネルのバージョンを上げたら
apt install -t buster-backports nvidia-driver apt install -t buster-backports firmware-iwlwifi
でドライバのインストール。
この辺、ちょっと試行錯誤してPDFの通りにソースから入れたりもしたので、これだけで動かないこともあるのかも。
https://wireless.wiki.kernel.org/_media/en/users/drivers/iwlwifi/iwlwifi-qu-48.13675109.0.tgz
一応これもDLしてたけど、同じファイルが firmware-iwlwifiパッケージ（中身は違うっぽい） にあった。
ここでnvidia-driver を入れているので、ここまでの作業はコンソールの黒い画面に超小さい文字で作業しないといけない。ちょっとつらい。
あとDebianインストール時にGRUBのインストールをどうするかという質問がなかった。
勝手にデフォルトのブートローダーが書き換わってしまった？再起動したらGRUBになる。問題ないと言えば無いんだけど…。
ブートローダーはWindows Boot Managerのまま、WindowsとLinuxでデュアルブート/GRUB4DOSを使ってデュアルブート - LinuxJapanWiki - アットウィキ
こっちをやろうと思っていた。インストールはAdvancedを選ぶ必要があったかもしれない。ほとんど何の質問もなくすぐインストール完了までいくとは思わなかった。
次回、何らかのアップデートでブートローダーが書き換わることがあったらやってみる。
せっかくハードウェアに指紋認証があるので、Linuxでも使いたい。
https://gitlab.freedesktop.org/libfprint/libfprint/-/tags
最新版をexperimentalでインストールすれば、バージョン的には対応しているっぽいけれど
https://askubuntu.com/questions/1214592/fingerprint-reader-lenovo-thinkpad-l13-synaptics-driver
一筋縄ではいかないようだ。
lsusb | grep Synaptics Bus 001 Device 003: ID 06cb:00bd Synaptics, Inc.
今は無理だけど
apt install libpam-fprintd pam-auth-update
を実行すると一括でpam設定してくれる。
2020/10/16追記：
今試したらいけた。
元々インストールしていたfprintd関連のパッケージを全て apt remove --purge してから、もう一度
apt install -t experimental libpam-fprintd
でインストールし直した。それでrootでfprintd-verifyすると普通に動いた。
指紋の登録は
fprintd-enroll
を実行する。
その後、pam-auth-update で各種パスワード入力の場所で指紋認証が使えるようになる。
デスクトップへのログインは、一度パスワードでログインしないと対応されない？ログインしてからログアウトして、再びログインするときには指紋認証が出るんだけど。
sudo はデフォルトが指紋認証になっていて、パスワード認証はしばらく待つ？
ちょっと使い勝手が分からない。
2020/10/20追記：
Support fingerprint reader login · Issue #284 · sddm/sddm · GitHub
sddmじゃなくてgdmを使えということか…。
gdm3を入れたらgnome関連のパッケージが大量にインストールされた。見た目が良くなって指紋認証ログインも使えるようになった。
ただ、起動直後は10秒ぐらい待たないとデバイスが認識されない。
askubuntu.com
うーん…未解決。画面ロック時の指紋認証は、パスワードが空の状態でEnterを押せばすぐにできる。
それから、関係は不明だけれどWi-Fiのパスワードが記憶されなくなってしまった。パスワードの保存を all users (not encrypted) にすれば記憶できた。最初の設定がどうなっていたか分からん…。not encryptedでいいんだっけ？
kde wallet使ってないから元々encryptedは無理な気もする。
無停止でサーバーをデータセンターに引っ越し： OpenVPN, Ganeti, Xen, LVM, DRBD
社内に置いてあるサーバーをOSごとデータセンターに移したのでその作業ログ。
はじめに。
- 長いです
- タイトルは大げさです
- 同じような環境の参考情報が見つからなかったのでこれが妥当なやり方がは判別できていない
- 普通はこうするよ、というのがあれば是非
- 前提条件
調べつつハマりつつやったので、まぁ知らなくても大丈夫。
Ganetiを使っているのでXenやLVM、DRBDを直接は触っていない。Ganetiを使っていない場合でも手動でLVMやDRBDを設定すればいけるはず。
IP環境など
VPN構築
x.x.x.2 と x.x.x.3 のIPを使う。
eth0 と eth1（つまり全てのNIC） をブリッジする。
ネットワーク設定
サーバー側の /etc/network/interfaces を変更。
auto br0
iface br0 inet static
address 10.1.1.2
netmask 255.255.255.255
network 10.1.1.0
broadcast 10.1.1.255
gateway 10.1.1.1
bridge_ports eth0 tap0
pre-up openvpn --mktun --dev tap0
post-down openvpn --rmtun --dev tap0
auto br0:0
iface br0:0 inet static
address 192.168.10.2
netmask 255.255.255.0
network 192.168.10.0
broadcast 192.168.10.255
auto br1
iface br1 inet static
address 192.168.9.2
netmask 255.255.255.0
network 192.168.9.0
broadcast 192.168.9.255
bridge_ports eth1 tap1
pre-up openvpn --mktun --dev tap1
post-down openvpn --rmtun --dev tap1VPNのためにeth0などを消してブリッジを作る。
NICが二枚しかないところに三つのネットワークを作るのでIPエイリアスで。
一つのHUBにネットワークが混在する環境になる。NICやHUBがあるのなら分けた方が良い。
続いてクライアント側。
auto br0
iface br0 inet static
address 192.168.10.3
netmask 255.255.255.0
network 192.168.10.0
broadcast 192.168.10.255
gateway 192.168.10.1
bridge_ports eth0 tap0
pre-up openvpn --mktun --dev tap0
post-down openvpn --rmtun --dev tap0
auto br1
iface br1 inet static
address 192.168.9.3
netmask 255.255.255.0
network 192.168.9.0
broadcast 192.168.9.255
bridge_ports eth1 tap1
pre-up openvpn --mktun --dev tap1
post-down openvpn --rmtun --dev tap1
OpenVPNサーバーインストール・設定
aptitude install openvpn cd mkdir openvpn cd openvpn cp -a /usr/share/doc/openvpn/examples/easy-rsa/ . cd easy-rsa/2.0 vi vars # KEY_COUNTRYなどを変更する、自分用なのでそのままいく . ./vars ./clean-all ./build-ca # すべてデフォルトで ./build-key-server vpn.example.com # すべてデフォルトで ./build-dh cp keys/ca.crt /etc/openvpn/ cp keys/vpn.example.com.crt /etc/openvpn/ cp keys/vpn.example.com.key /etc/openvpn/ cp keys/dh1024.pem /etc/openvpn/ cd /etc/openvpn/ cp /usr/share/doc/openvpn/examples/sample-config-files/server.conf.gz . gunzip server.conf.gz vi server.conf
port 1194 proto tcp dev tap0 ca ca.crt cert vpn.example.com.crt key vpn.example.com.key dh dh1024.pem server-bridge keepalive 10 120 comp-lzo persist-key persist-tun status openvpn-status2.log verb 3
cp server.conf server2.conf vi server2.conf
- port 1195
- dev tap1
NICが二枚あるので、設定ファイルも二つ。ポートを分ける必要がある。
変なトラブルにハマるのも嫌なのでudpではなくtcpで。
OpenVPN クライアントインストール・設定
aptitude install openvpn cd /etc/openvpn/ cp /usr/share/doc/openvpn/examples/sample-config-files/client.conf . cp -a /usr/share/doc/openvpn/examples/easy-rsa/ . cd easy-rsa/2.0 . ./vars ./clean-all ./build-req vpnc.example.com echo "10.1.1.2 vpn.example.com" >> /etc/hosts scp keys/vpnc.example.com.csr vpn.example.com:~/openvpn/easy-rsa/2.0/keys/
クライアント側で署名済み証明書設定
scp vpn.example.com:~/openvpn/easy-rsa/2.0/keys/ca.crt keys/ scp vpn.example.com:~/openvpn/easy-rsa/2.0/keys/vpnc.example.com.crt keys/ cp keys/ca.crt /etc/openvpn/ cp keys/vpnc.example.com.crt /etc/openvpn/ cp keys/vpnc.example.com.key /etc/openvpn/ cd /etc/openvpn/ cp client.conf client.conf.org vi client.conf
client.conf
client dev tap0 proto tcp remote vpn.example.com 1194 resolv-retry infinite nobind persist-key persist-tun ca ca.crt cert vpnc.example.com.crt key vpnc.example.com.key ns-cert-type server comp-lzo verb 3
client2.conf も dev tap1 と port 1195 作る。
chmod og-r vpnc.example.com.key echo "192.168.10.3 vpnc.example.com" >> /etc/hosts echo "10.1.1.2 vpn.example.com" >> /etc/hosts
動作確認
サーバー側、クライアント側で openvpn stop start する。
サーバーからクライアント、クライアントからサーバーでローカルIPのping確認。また、ネットワーク上の他のマシンからも確認。
/proc/sys/net/ipv4/ip_forward を 1 にし、ついでにブロードキャストも応答するようにすると分かりやすい。
# cat /etc/sysctl.d/ipforward.conf net.ipv4.ip_forward = 1 # # cat /etc/sysctl.d/broadcast.conf net.ipv4.icmp_echo_ignore_broadcasts = 0 # # sysctl -p /etc/sysctl.d/ipforward.conf net.ipv4.ip_forward = 1 # # sysctl -p /etc/sysctl.d/broadcast.conf net.ipv4.icmp_echo_ignore_broadcasts = 0 # # ping -b 192.168.10.255 ...
ネットワークのマシンは全部ブロードキャストに答えるようにしている。
そうするとVPNを通じて双方から大量の応答が返ってくるようになる。
データセンター側にGanetiノード追加
Ganetiのインストールは割愛。本家のマニュアルを上から順にやっていくのが一番失敗がない。自分の環境では一度設定した流れをシェルスクリプトに書いていて、そのまま実行したり所々変えながら実行したりしている。xenやgrubの共通設定、Debianの共通設定はひな形からコピー。
ネットワーク設定
auto xen-br0
iface xen-br0 inet static
address 10.1.1.4
netmask 255.255.255.0
network 10.1.1.0
broadcast 10.1.1.255
gateway 10.1.1.1
bridge_ports eth0
bridge_stp off
bridge_fd 0
auto xen-br0:0
iface xen-br0:0 inet static
address 192.168.10.4
netmask 255.255.255.0
network 192.168.10.0
broadcast 192.168.10.255
auto eth1
iface eth1 inet static
address 192.168.9.4
netmask 255.255.255.0
network 192.168.9.0
broadcast 192.168.9.255
# mtu 9000Xenの普通の設定。eth1はDRBD用。普段はmtuを上げているが、今回はトンネルするので通常のままで。
こんな感じで datacenter1.example.com x.x.x.4 と datacenter2.example.com x.x.x.5 を追加する。
Ganetiマスターノードでの設定
vi /etc/hosts # datacenter1.example.com、datacenter2.example.com を追加
gnt-cluster command ifconfig eth1 mtu 1500 gnt-cluster command ifconfig eth1|grep MTU gnt-node add -s 192.168.9.4 datacenter1.example.com gnt-node add -s 192.168.9.5 datacenter2.example.com
gnt-cluster command は全ノードで同じコマンドを走らせるユーティリティ。
gnt-node add はノード追加。 -s はDRBD通信用。
vi /etc/hosts 192.168.10.11 dctest.example.com dctest
gnt-instance add -n datacenter1:datacenter2 -t drbd --disk 0:size=1G -B memory=1G,vcpus=1 -o debootstrap+default \ -H xen-pvm:kernel_path=/boot/vmlinuz-2.6-xenU,initrd_path=/boot/initrd-2.6-xenU \ --net 0:ip=192.168.10.11 dctest.example.com
datacenter1に入って
watch -n 1 pstree -al
で進捗確認。
gnt-node list gnt-instance list -o name,pnode,snodes,status,oper_ram,oper_vcpus,nic.ips,disk.sizes gnt-instance console dctest
passwd vi /etc/network/interfaces
auto eth0
iface eth0 inet static
address 192.168.10.11
netmask 255.255.255.0
network 192.168.10.0
broadcast 192.168.10.255
gateway 192.168.10.1/etc/init.d/networking start aptitude update aptitude upgrade aptitude install ssh vim exit ^]
instance移動テスト
ssh で dctestに繋ぎ
vmstat 1
などを実行しておく。接続が途切れないかの確認用。
masterでの操作。
gnt-instance list -o name,pnode,snodes,status,oper_ram,oper_vcpus,nic.ips,disk.sizes gnt-node list gnt-instance replace-disks --new-secondary node1 dctest.example.com
node1 は移動前のLAN側にあるGanetiノード。
タイムアウトエラーになったら
gnt-job list gnt-job watch <id>
gnt-instance migrate dctest
今回はデータセンター側から逆に移動。
動作が確認できたら削除。
gnt-instance remove dctest
引っ越し
ネットワーク設定
引っ越しする仮想マシンに入る。
vi /etc/iproute2/rt_tables
# 追加 100 dc
ifdown eth0 vi /etc/network/interfaces
auto eth0
iface eth0 inet static
address 192.168.10.21
netmask 255.255.255.0
network 192.168.10.0
broadcast 192.168.10.255
gateway 192.168.10.1
post-up ip addr add 10.1.1.21/24 dev eth0 brd 10.1.1.255
post-up ip route add 10.1.1.0/24 dev eth0 src 10.1.1.21 table dc
post-up ip route add default via 10.1.1.1 table dc
post-up ip rule add from 10.1.1.21 table dc
pre-down ip rule del from 10.1.1.21 table dc
pre-down ip route del default via 10.1.1.1 table dc
pre-down ip route del 10.1.1.0/24dev eth0 src 10.1.1.21 table dc
pre-down ip addr del 10.1.1.21/24 dev eth0 brd 10.1.1.21ifup eth0
eth0:0でやろうとしたのだが、post-upなどはエイリアスには設定できなさそうだったので。
ip route と rule を使ってマルチホーミングの設定。ゲートウェイをネットワークごとに持てる。ping -I ip_or_iface でIPやインターフェースを指定してpingを打てるので、どちらのIPでも通信できていることを確認する。
外部からも古い方のグローバルIPと新しい方のグローバルIPにpingを打ってテスト。
移動
Ganetiマスターノードでの作業。引っ越しするホストをhost1とする。
gnt-instance replace-disks --new-secondary datacenter1 host1.example.com
時間がかかるので、その間に
などをやっておく。
本来の引っ越し作業は、引っ越し時刻のTTL秒前からTTLを徐々に減らしていって引っ越し時刻に数分にすることでDNSキャッシュを調節するのだが、今回はVPNによって両方のグローバルIPが生きているので神経質になる必要はない。VPNを通す側のグローバルIPはちょっと遅くなるが。
セカンダリノードの付け替えが終わったらライブマイグレーションする。
gnt-instance migrate host1
残念ながら、正常終了したように見えたがカーネルパニックで止まっていた。
Dom0から見たら生きているが仮想マシンのコンソールを表示すると例のスタックトレースで停止している。
気を取り直して起動。
gnt-instance reboot host1 gnt-instance console host1
このままではVPNを通してDRBDミラーされているので、セカンダリも移動する。
gnt-instance replace-disks --new-secondary datacenter2 host1
これで完了。
まとめ
だいたい以下の流れ
色々ハマったが、実機での引っ越しに比べるとかなり楽にできたように思う。
書き忘れたが、DRBDのセカンダリ移動中は該当サーバーがかなり重い。せっかくNICやHUBを分けているのに、VPNしてるから結局同じ回線通るっていうね…。移動中のサーバーにあるwikiにこれをメモしていたのだが、ページ表示に数秒の待ち時間があった。これはDRBDの転送速度を調整してのんびり移行すればマシになるのかもしれない。
この後は旧環境のサーバーを全て移動して旧IPを破棄してVPN接続を終了する作業が待っているが、まだまだ先になりそう。
安全にいくならライブマイグレーションはやめて一度停止した方がいいかもしれない。
補足１：引っ越し先をNAT on Linux にする場合
一応試した。
Xen仮想マシンでLinuxルーター
IPは x.x.x.31 とする。
debootstrapではカーネルが入らないので、iptables利用のためのカーネルを入れる。
参考: http://shell.burgas.org/2009/06/debian-50-xen-domu-iptables-kernel-module-problem-on-fresh-install/
aptitude install linux-modules-2.6.32-5-xen-amd64
cat > /etc/sysctl.d/ipforward.conf net.ipv4.ip_forward = 1 ^D sysctl -p /etc/sysctl.d/ipforward.conf
NAT設定
参考: http://d.hatena.ne.jp/mirans/20120710/1341921817
# NAT 外から内 iptables -t nat -A PREROUTING -d 10.1.1.32 -j DNAT --to 192.168.10.32 # NAT 内から外 iptables -t nat -A POSTROUTING -s 192.168.10.32 -j SNAT --to 10.1.1.32
NATするIPを x.x.x.32とした場合。
OS起動時のiptables実行は、Debianでは iptables-persistentを使う。
aptitude install iptables-persistent vi /etc/init.d/iptables-persistent # Default-Start: 2 3 4 5 # Default-Stop: 0 1 6 update-rc.d iptables-persistent defaults
移動する仮想マシン上での設定
一つのIPでマルチホーミング。
参考: http://d.hatena.ne.jp/hirose31/20120822/1345626743 http://ap.atmarkit.co.jp/bbs/core/flinux/27359
aptitude install linux-modules-2.6.32-5-xen-amd64 vi /etc/iproute2/rt_tables # 100 dc を追加
外部からのpingに対応するMACアドレスを tcpdump -e で調べる。(192.168.10.31のmacアドレスになっていればOK)
mac アドレスを判別してマーク設定し、ゲートウェイを分ける。
iptables -t mangle -A PREROUTING -m mac --mac-source 00:00:00:00:5e:aa -j MARK --set-mark 1 iptables -t mangle -A PREROUTING -j CONNMARK --save-mark iptables -t mangle -A OUTPUT -j CONNMARK --restore-mark ip rule add priority 100 fwmark 1 table dc ip route add default via 192.168.10.31 dev eth0 table dc
192.168.10.31のmacアドレス 00:00:00:00:5e:aa で入ってきたパケットにマークを付けて、それを返すときは 192.18.10.31 に向ける。
設定がややこしくてNATなのに各サーバーのiptables設定が必要なので結局この案は中止。
グローバルIPノーガードでいくことに。Debianなので大丈夫でしょう。
補足２：DSRも一応考えた
参考: http://www.os.cis.iwate-u.ac.jp/wikky/wikky.cgi?s-book%3A%3ASLB%3A%3A3
iptables のmanpageを眺めていたら、arptables というコマンドがあってそれでmacアドレスを書き換えられそう。
ただ、負荷分散しないのにNATの代わりに…ってのでやっぱり複雑だから却下。こちらは試していない。
補足３：カーネルパニックログ
一部抜粋。
[42698172.104748] Setting capacity to 16777216 [42698172.109068] Setting capacity to 16777216 [42698173.097889] general protection fault: 0000 [#1] SMP [42698173.097903] last sysfs file: /sys/module/ip_tables/initstate [42698173.097910] CPU 0 ... [42698173.098096] Stack: [42698173.098100] ffffffff810cf60f ffff88000000da00 000000103fda9300 00000000000280d0 [42698173.098112] <0> ffff88000000da08 ffff88003d915fd8 00007f4ee5cf4fff ffff880002ae8b80 [42698173.098127] <0> ffff88003e53f180 ffff880001805180 ffff88003ee8a7f0 ffff88003d8c17f0 [42698173.098143] Call Trace: [42698173.098152] [<ffffffff810cf60f>] ? copy_page_range+0x3e0/0x711 [42698173.098163] [<ffffffff810e81d5>] ? kmem_cache_alloc+0x8c/0xf0 [42698173.098173] [<ffffffff8104d2b9>] ? dup_mm+0x2d9/0x40a [42698173.098181] [<ffffffff8104de5b>] ? copy_process+0xa3c/0x115f [42698173.098192] [<ffffffff8100c3a5>] ? __raw_callee_save_xen_pud_val+0x11/0x1e [42698173.098202] [<ffffffff8104e6d5>] ? do_fork+0x157/0x31e [42698173.098211] [<ffffffff8130f906>] ? do_page_fault+0x2e0/0x2fc [42698173.098220] [<ffffffff81011e63>] ? stub_clone+0x13/0x20 [42698173.098229] [<ffffffff81011b42>] ? system_call_fastpath+0x16/0x1b [42698173.098236] Code: 00 00 00 01 74 05 e8 78 9a e8 ff 48 89 d0 5e c3 ff 14 25 40 eb 47 81 3e 81 2f 00 00 00 01 74 05 e8 5e 9a e8 ff c3 b8 00 00 01 00 <3e> 0f c1 07 0f b7 d0 c1 e8 10 39 c2 74 07 f3 90 0f b7 17 eb f5 [42698173.098330] RIP [<ffffffff8130d3f8>] _spin_lock+0x5/0x1b [42698173.098340] RSP <ffff88003d915c58> [42698173.098348] ---[ end trace 492cb45db99e2316 ]--- [42698178.613836] BUG: Bad page map in process cron pte:fffffffffffff145 pmd:0cc15067 [42698178.613851] addr:00007ff84e3cc000 vm_flags:08100073 anon_vma:ffff88003d8c8720 mapping:ffff88003f8bc840 index:8 [42698178.613864] vma->vm_ops->fault: filemap_fault+0x0/0x2f6 [42698178.613879] vma->vm_file->f_op->mmap: generic_file_mmap+0x0/0x47 [42698178.613889] Pid: 3006, comm: cron Tainted: G D 2.6.32-5-xen-amd64 #1 [42698178.613897] Call Trace: [42698178.613905] [<ffffffff810cbe1b>] ? print_bad_pte+0x232/0x24a [42698178.613915] [<ffffffff8100c2f1>] ? __raw_callee_save_xen_pte_val+0x11/0x1e [42698178.613924] [<ffffffff810cbe83>] ? vm_normal_page+0x50/0x6b [42698178.613933] [<ffffffff810cf7ac>] ? copy_page_range+0x57d/0x711 [42698178.613942] [<ffffffff810e81d5>] ? kmem_cache_alloc+0x8c/0xf0 [42698178.613951] [<ffffffff8104d2b9>] ? dup_mm+0x2d9/0x40a [42698178.613960] [<ffffffff8104de5b>] ? copy_process+0xa3c/0x115f [42698178.613968] [<ffffffff8104e6d5>] ? do_fork+0x157/0x31e [42698178.613977] [<ffffffff810f3187>] ? sys_newstat+0x23/0x30 [42698178.613986] [<ffffffff81011e63>] ? stub_clone+0x13/0x20 [42698178.613994] [<ffffffff81011b42>] ? system_call_fastpath+0x16/0x1b [42698178.614013] BUG: Bad page map in process cron pte:fffffffffffff145 pmd:0ccfe067 [42698178.614023] addr:00007ff84e5fe000 vm_flags:08100073 anon_vma:ffff88003d8c8e00 mapping:ffff88003f883b30 index:3 [42698178.614034] vma->vm_ops->fault: filemap_fault+0x0/0x2f6 [42698178.614042] vma->vm_file->f_op->mmap: generic_file_mmap+0x0/0x47 [42698178.614050] Pid: 3006, comm: cron Tainted: G B D 2.6.32-5-xen-amd64 #1 [42698178.614058] Call Trace: [42698178.614065] [<ffffffff810cbe1b>] ? print_bad_pte+0x232/0x24a [42698178.614073] [<ffffffff8100c2f1>] ? __raw_callee_save_xen_pte_val+0x11/0x1e [42698178.614083] [<ffffffff810cbe83>] ? vm_normal_page+0x50/0x6b [42698178.614091] [<ffffffff810cf7ac>] ? copy_page_range+0x57d/0x711 [42698178.614100] [<ffffffff810e81d5>] ? kmem_cache_alloc+0x8c/0xf0 [42698178.614109] [<ffffffff8104d2b9>] ? dup_mm+0x2d9/0x40a [42698178.614117] [<ffffffff8104de5b>] ? copy_process+0xa3c/0x115f [42698178.614126] [<ffffffff8104e6d5>] ? do_fork+0x157/0x31e [42698178.614134] [<ffffffff810f3187>] ? sys_newstat+0x23/0x30 [42698178.614142] [<ffffffff81011e63>] ? stub_clone+0x13/0x20 [42698178.614150] [<ffffffff81011b42>] ? system_call_fastpath+0x16/0x1b [42698178.614503] BUG: unable to handle kernel paging request at ffffc7fffffff240 [42698178.614518] IP: [<ffffffff8100e15a>] make_lowmem_page_readonly+0x1b/0x38 [42698178.614531] PGD 0 [42698178.614537] Oops: 0000 [#2] SMP [42698178.614545] last sysfs file: /sys/module/ip_tables/initstate [42698178.614552] CPU 0 ... [42698374.424004] BUG: soft lockup - CPU#0 stuck for 61s! [cron:9707] ... [42698374.424004] Call Trace: [42698374.424004] [<ffffffff8100dd87>] ? xen_exit_mmap+0xf8/0x136 [42698374.424004] [<ffffffff8100922a>] ? hypercall_page+0x22a/0x1001 [42698374.424004] [<ffffffff810d14e8>] ? exit_mmap+0x5a/0x148 [42698374.424004] [<ffffffff8104b9b0>] ? __cond_resched+0x1d/0x26 [42698374.424004] [<ffffffff8104cc6d>] ? mmput+0x3c/0xdf [42698374.424004] [<ffffffff81050872>] ? exit_mm+0x102/0x10d [42698374.424004] [<ffffffff8100ec89>] ? xen_irq_enable_direct_end+0x0/0x7 [42698374.424004] [<ffffffff81052297>] ? do_exit+0x1f8/0x6c6 [42698374.424004] [<ffffffff8100ece2>] ? check_events+0x12/0x20 [42698374.424004] [<ffffffff811ba6e0>] ? dummycon_dummy+0x0/0x3 [42698374.424004] [<ffffffff8130e2cd>] ? oops_end+0xaf/0xb4 [42698374.424004] [<ffffffff810333a4>] ? no_context+0x1e9/0x1f8 [42698374.424004] [<ffffffff81033559>] ? __bad_area_nosemaphore+0x1a6/0x1ca [42698374.424004] [<ffffffff8130f68f>] ? do_page_fault+0x69/0x2fc [42698374.424004] [<ffffffff8130d7a5>] ? page_fault+0x25/0x30 [42698374.424004] [<ffffffff8100e15a>] ? make_lowmem_page_readonly+0x1b/0x38 [42698374.424004] [<ffffffff8100e151>] ? make_lowmem_page_readonly+0x12/0x38 [42698374.424004] [<ffffffff8100e1cf>] ? xen_alloc_ptpage+0x58/0x70 [42698374.424004] [<ffffffff810cd7c2>] ? __pte_alloc+0x6b/0xc6 [42698374.424004] [<ffffffff810cb674>] ? pmd_alloc+0x28/0x5b [42698374.424004] [<ffffffff810cd8eb>] ? handle_mm_fault+0xce/0x80f [42698374.424004] [<ffffffff8130d7a5>] ? page_fault+0x25/0x30 [42698374.424004] [<ffffffff8130d9da>] ? error_exit+0x2a/0x60 [42698374.424004] [<ffffffff8101251d>] ? retint_restore_args+0x5/0x6 [42698374.424004] [<ffffffff8130d42a>] ? _spin_unlock_irqrestore+0xd/0xe [42698374.424004] [<ffffffff8130f906>] ? do_page_fault+0x2e0/0x2fc [42698374.424004] [<ffffffff8130d7a5>] ? page_fault+0x25/0x30
ひたすら長い。
Xenでiptables使ったのがまずい？
domUを起動した後にdomUでカーネルイメージを入れたら起動時のカーネルからアップデートがかかって、domUのカーネルモジュールにだけ更新がかかった気もする…。
再現させるのも大変だし、dom0のカーネルアップデートもすぐにはできないので一旦保留。
他のサーバーも試したけれどダメだった。
カーネルが停止するか、停止しなくてもエラーログが流れるようになる。
考えられるのは…
- ネットワーク設定が間違っている、間違っていないまでも推奨されないことをやっている
- CPUなどのハードが違う
- Xenのバグ
- ネットワークで何らかのエラーまたは遅すぎてアウト
- HDDなどのトラブル
上から確率が高そうな順に。
一度はうまくいったんだけどなぁ。。。
今読み返していたら、成功した時はデータセンターから社内LANへの移動で、移動の方向が逆だった。
CPUとか移動先のハードが原因？
