Logical Rabbit.

さくらのVPS

CentOS

Vagrant+Ansible+VirsualBox on CentOS。

CentOS 7.5上でVagrantとAnsibleを使ってVirsualBoxを操作しようとしたら環境設定に色々ハマった記録。バグトラップな上にグーグル先生が的確な情報出してくれない!!

問題山積み

  1. VirsualBoxのインストールで失敗する (modprobe vboxdrv が云々)
    • secure bootの影響で、署名がないモジュールをロードできないのが原因。署名すればよい。
  2. だがしかし、署名に使った公開鍵がenrollできない
    • mokutilのバグ。1つ前のバージョンに戻す。
  3. Mac OS X用のVagrantfileとCentOS(Linux)用のVagrantfileではansible providerの名前が異なる
  4. なんかVagrantfileからは実行できないのに、ansible-playbookでは実行できるんですが… (これは秘密鍵のパスとか、そういう問題かも)
  5. NFSマウントが失敗する
    • firewalldがお仕事してた。vboxnet0をtrusted zoneへ叩き込む(いいのかそれで?)
  6. "CentOS VirtualBox Vagrant"とかでググると「Vagrantで(WIndowsの)VirtualBoxにCentOSを入れようず」いう話ばかりが出てくるんですよね…。しかし他に適当なキーワードもなく。

各々の対策記録

VirsualBoxのインストールで失敗する

CentOSのおそらく7.4以降~バグ修正版が出るまでは、先に「署名に使った公開鍵がenrollできない」を読んでください。二度手間になります。

RedHatの 26.8. セキュアブート用のカーネルモジュールの署名 が日本語ですし、「何をやっているのか」まで分かってよいです。

単にやるべきことを知りたいだけならば Signing VirtualBox & VMware modules 等があります。 なお、CN=以降はcommon nameを入れるところなので各自考えて置き換えることになります。

例に出ているのは「vboxdrv」だけなのですが、実際は同じディレクトリ内の全ファイルに署名しないとダメでした(全ファイル必要なのかは組み合わせテストが面倒なので確認していません)。

modinfo -n vboxdrv でこのモジュールファイルのフルパスが出てくるので、そこでパス名から必要なファイルを見つけてください。ちょっとイイ感じにやりたければ ls $(dirname $(modinfo -n vboxdrv) )/* |xargs -l1とかすればイケるんじゃないかとは思う。

署名に使った公開鍵がenrollできない

問題は、上記でモジュールに署名したあと、その公開鍵を mokutil へ登録した後で、再起動するとUEFI コンソールで mokutil にセットしたパスワードを聞かれ、パスすれば以後は公開鍵がOSへ永続登録される、という部分です。何度再起動してもそんな画面出てこないのです…っ

原因は、最新版の mokutil にバグがあり、肝心のUEFIコンソールが起動しないとのこと。 以下にその説明があります。

0014050: Failed to Enter Shim UEFI key management screen while rebooting on CentOS7 if upgrade to 7-4.1708

元々問題に気付いたのはこのあたりの記事。 "The uefi secure boot bug" の文言を読んだ時の脱力感がハンパない。

Red Hat Bugzilla – Bug 1477735 Shim was unable to measure state into the TPM

対策ですが、バグのない1つ前の mokutil はCentOSの場合7.3にあります。 http://vault.centos.org/7.3.1611/os/x86_64/Packages/ から mokutilshim のRPMをダウンロードして、最新版を yum remove で削除後にインストールします。

成功すれば、ブート時にきっちり止まりますので確実に分かります。

この作業前に mokutil へ鍵を登録したりパスワードをセットしていた場合、その作業からやり直しになるので注意してください。

Mac OS X用とCentOS(Linux)用とのVagrantfile差異

一覧に書いた通りです。Mac OS X 用は ansible 。CentOS用は ansible_local 。このあからさまな違いから見て、CentOS用は何か使い方を変えると ansible になるのかもしれませんが。

参考記事は以下。

Ansible Local Provisioner

NFSマウントが失敗する

原因がわからないときは、 vagrant ssh でゲストOSに入ったのち、おそらく画面に表示されているであろうコマンド( mount -o vers=3,udp <ホスト側IP>:<ホスト側Path> /vagrant 等)を実行してみるのがよいです。この際、mount コマンドに --verbose を追加することで、ある程度情報が増えます。

私のケースの場合 mount.nfs: portmap query failed: RPC: Unable to receive - No route to host が出ていたので、これは経路が切れてるな…と考えた次第。その後sshでゲスト→ホスト接続を試してみて、接続できたのでfirewallかな、と。

  1. firewall-cmd --add-interface vboxnet0 --zone=trusted
  2. firewall-cmd --list-all --zone=trusted (確認)
trusted (active)
  target: ACCEPT
  icmp-block-inversion: no
  interfaces: vboxnet0
  sources: 
  services: 
  ports: 
  protocols: 
  masquerade: no
  forward-ports: 
  source-ports: 
  icmp-blocks: 
  rich rules: 

のような結果になればOK。

PRIMERGY MX130 S2にCentOS 7を入れたらハマった。

AMD CPUのPRIMERGY MX130 S2 にCentOS 7をいれてyum upgradeしたら microcode: failed to load file amd-ucode/microcode_amd.bin などと言う謎のエラーを吐いて起動しなくなっているお話(現在進行形) (解決したのでオチを追記)。

古の激安サーバー()であるPRIMERGY MX130 S2が職場に2台あるわけですが、うち1代のHDDがS.M.A.R.T.エラーを噴いて撃沈したのをいいことに、CentOS 7で再構築を始めたわけですよ。とりま、 yum upgrade でまるっと更新かけたわけですよ。 kernel が更新リストに入っていたから、何も考えずリブートしたわけですよ。

…カーネルパニックみたいな状態になって起動どころかCTRL+ALT+DELすら受け付けない状態になったわけですよ(汗)

電源断して起動時に1つ前のkernelを指定したところ無事起動したので、dmesg.oldを見たところ、最後のメッセージが冒頭の “microcode: failed to load file amd-ucode/microcode_amd.bin”。

で、このメッセージでGoogle検索してみると、以下のバグトラックが出てきた。どうも同じ現象っぽい。

0007331: Failed to load file microcode_amd.bin

実際、 /lib/firmware/ の中に amd-ucode/ というディレクトリ自体が存在しないのでそりゃファイルのロードもできないよね、という状態ではあるのだけど、今一つ分からないのが、今回の現象が意図的に行われたのか誰かのミスなのか、というところ。

英文なんで斜め読みで取り敢えず解決方法だけ探してる状況なのですが、解決方法自体はまあ、バグトラックに言及があるURLからmicrocode一式をダウンロードして入れてしまえば良さげです。

ただ仮に今回の現象が意図的なもので、今後kernelにはこのファイル群が入らないとなると、このサーバー機はCentOS 6止まりにしておくとか、運用終了も考えたほうが良い気がします。ただ、意図的な足きりならば、この手のバグトラックは割と早い段階で開発当事者の人が出てきて「そいつはもうサポート外だ」で 終わると思うんですよね。なにやら話題は継続している様子だし、足りないファイル入れておしまいなら早々にバグフィックス版が出てもよさそうなのに、1年以上もスレッドが続いている。

そして何より気にかかるのが、PRIMERGY MX130 S2を買った、CentOS入れたという日本語記事はわりとGoogle検索にひっかかるのに、このバグに遭遇したという日本語記事が出てこない。みなさんなんで大丈夫なの??

ともあれ、明日(というか今日)出勤したら、問題のファイル群を押し込んで経過観察する予定。

[2015.12.29 追記]

いや本当は12/17に解決していたのだけど、記録する暇が無くて…。

結論。microcodeは関係なかった。つか然るべきファイルを置いてみても「ファイルが無い」というエラーは出ていないもののフリーズする現象は止まらず。再度ググったところ、以下と同じ現象だった模様。

Kernel 3.10.0-327 issue on AMD Neo processor

同じ方法で対策してみたところ、安定稼働するようになりました。その後本格的なシステム構築を始めて仕事納めの12/25まで24時間動作続けています。

しかしclocksource_done_bootingってなんだろう…。名前から察してタイマー割り込み系かしら。

CentOSを使用したリモート操作についての備忘。

CentOSで他のマシンをリモート操作することに関するメモ。必要に応じて追記されていると思われ。

コマンドプロンプトから他のマシンを起動する (Wak on LAN)

ether-wake <MAC address>

実行にはroot権限が必要。

CentOS 7 だと標準で導入されているっぽい? うちでは主要マシン向けに以下のようなシェルスクリプト書いてあります。(sudoで実行して機動確認のためにpingを打ちつづける)

#!/bin/sh

sudo /usr/sbin/ether-wake <MAC address>
ping <IP address>

リモートデスクトップ接続

EPELの xrdp パッケージ ( http://xrdp.sourceforge.net/ ) を導入します。

xrdp.x86_64 : Open source remote desktop protocol (RDP) server

以下のようなシェルスクリプトを書いておくと便利。この例ではフルHDモニタいっぱいに表示します。また、起動後コンソールを占拠されるのが嫌なのでバックグラウンドに回しています。

ポート番号は標準のままならば指定不要。うちの場合ブロードバンドルーターを介してINTERNETから繋ぐので、アタック対策も兼ねてポート番号を適当に割り当てています。としてINTERNET側のIPアドレスを指定、として割り当て済みの番号を指定すると、ルーター内でイントラ側の特定Windowsマシンに転送する次第。

#!/bin/sh

rdesktop -g 1920x1080 <IP address>:<port> &

alternativesでslaveに指定し忘れた項目があった場合。

特にたくさんの --slave を指定していた場合、一度削除して再登録するのがめんどうくさい。

alternativesシステムの構造を調べて、手動で対策できたのでメモ。

例: ソースコードからインストールしたPostgreSQLを /usr/bin に配置したい。が、pg_ctlを --slave に含め忘れてしまい、postmasterが止まらなくなった orz

(やだなぁ、あくまで例ですよ?)

一連のコマンド群を配置した際の実行パラメータは、次のようになっていた(可読性優先のためコマンドラインオプションごとに改行しています)。

alternatives
 --install /usr/bin/postgres postgresql /usr/local/postgresql-9_3_4/bin/postgres 100
 --slave /usr/bin/postmaster postgresql-postmaster /usr/local/postgresql-9_3_4/bin/postmaster
 --slave /usr/bin/psql postgresql-psql /usr/local/postgresql-9_3_4/bin/psql
 --slave /usr/bin/pg_config postgresql-pg_config /usr/local/postgresql-9_3_4/bin/pg_config
 --slave /usr/bin/pg_dump postgresql-pg_dump /usr/local/postgresql-9_3_4/bin/pg_dump
 --slave /usr/bin/createdb postgresql-createdb /usr/local/postgresql-9_3_4/bin/createdb
 --slave /usr/bin/dropdb postgresql-dropdb /usr/local/postgresql-9_3_4/bin/dropdb
 --slave /usr/bin/initdb postgresql-initdb /usr/local/postgresql-9_3_4/bin/initdb
 --slave /usr/bin/vacuumdb postgresql-vacuumdb /usr/local/postgresql-9_3_4/bin/vacuumdb
 --slave /usr/lib64/postgresql postgresql-lib /usr/local/postgresql-9_3_4/lib

当初はねー、主に使うのはこのあたりのコマンドだけかなー、と思ってたですよ。

この場合のalternativesシステムデータの構造は次のようになっていた。

  1. /usr/bin/postgres (シンボリックリンク) は /etc/alternatives/postgresql を示す
  2. /etc/alternatives/postgresql (シンボリックリンク) は /usr/local/postgresql-9_3_4/bin/postgres (実体) を示す
  3. --slave 指定した /usr/bin/postmaster (シンボリックリンク) は /etc/alternatives/postgresql-postmaster (シンボリックリンク) を示す
  4. /etc/alternatives/postgresql-postmaster (シンボリックリンク) は /usr/local/postgresql-9_3_4/bin/postmaster (実体) を示す
  5. 以後、 --slave 指定のものは同様に /usr/bin (リンク) → /etc/alternatives/<名前> → <パス> のようになる

ここで問題なのが、 --install--slave の関係性、リンクに指定した優先度の情報はどこに行ったのか?、という点。特に優先度の情報が見えていない。

これらは /var/lib/alternatives に --install に指定した <名前> というファイル名で保存されていた。

/var/lib/alternatives/postgresql の内容は次のようになっている。

$ cat /var/lib/alternatives/postgresql 
auto
/usr/bin/postgres
postgresql-postmaster
/usr/bin/postmaster
postgresql-psql
/usr/bin/psql
postgresql-pg_config
/usr/bin/pg_config
postgresql-pg_dump
/usr/bin/pg_dump
postgresql-createdb
/usr/bin/createdb
postgresql-dropdb
/usr/bin/dropdb
postgresql-initdb
/usr/bin/initdb
postgresql-vacuumdb
/usr/bin/vacuumdb
postgresql-lib
/usr/lib64/postgresql

/usr/local/postgresql-9_3_4/bin/postgres
100
/usr/local/postgresql-9_3_4/bin/postmaster
/usr/local/postgresql-9_3_4/bin/psql
/usr/local/postgresql-9_3_4/bin/pg_config
/usr/local/postgresql-9_3_4/bin/pg_dump
/usr/local/postgresql-9_3_4/bin/createdb
/usr/local/postgresql-9_3_4/bin/dropdb
/usr/local/postgresql-9_3_4/bin/initdb
/usr/local/postgresql-9_3_4/bin/vacuumdb
/usr/local/postgresql-9_3_4/lib

1行目の auto …はまあ今回無視するとして、2行目に --install で指定した<リンク>、3行目以降に --slave で指定した <リンク>と<名前>が1行ずつ列挙されている。

また、一連の列挙の後1行空けて、 --install で指定した <パス>、<優先度>、 --slave で指定した <パス> が1行ずつ列挙されている。

ということで、指定し忘れた項目(この場合 pg_ctl )を手動で追加するには、次の手順となる。

  1. /var/lib/alternatives/postgresql の上段(1行目~空行まで)の末尾に以下を追記
    postgresql-pg_ctl
    /usr/local/postgresql-9_3_4/bin/pg_ctl
    
  2. /etc/alternatives/postgresql-pg_ctl という名前で usr/local/postgresql-9_3_4/bin/pg_ctl へのシンボリックリンクを作成
  3. /usr/bin/pg_ctl という名前で /etc/alternatives/postgresql-pg_ctl へのシンボリックリンクを作成
  4. alternatives —display postgresql で手動追加が反映されたことを確認(以下、結果)
    $ alternatives --display postgresql
    postgresql -ステータスは自動です。
    リンクは現在 /usr/local/postgresql-9_3_4/bin/postgres を指しています。
    /usr/local/postgresql-9_3_4/bin/postgres - 優先項目 100
     スレーブ postgresql-postmaster: /usr/local/postgresql-9_3_4/bin/postmaster
     スレーブ postgresql-psql: /usr/local/postgresql-9_3_4/bin/psql
     スレーブ postgresql-pg_config: /usr/local/postgresql-9_3_4/bin/pg_config
     スレーブ postgresql-pg_dump: /usr/local/postgresql-9_3_4/bin/pg_dump
     スレーブ postgresql-createdb: /usr/local/postgresql-9_3_4/bin/createdb
     スレーブ postgresql-dropdb: /usr/local/postgresql-9_3_4/bin/dropdb
     スレーブ postgresql-initdb: /usr/local/postgresql-9_3_4/bin/initdb
     スレーブ postgresql-vacuumdb: /usr/local/postgresql-9_3_4/bin/vacuumdb
     スレーブ postgresql-lib: /usr/local/postgresql-9_3_4/lib
     スレーブ postgresql-pg_ctl: /usr/local/postgresql-9_3_4/bin/pg_ctl
    現在の「最適」バージョンは /usr/local/postgresql-9_3_4/bin/postgres です。
    

…いやぁ、あくまで例デスよ?(汗)

USB3.0が相性問題っぽい原因でアクセス不能になったとき。

xhci-hcd モジュールをアンロードしてからロードすれば回復するっぽい。ちぃ覚えた。

具体的には CentOS 6.5 でのお話。USB3.0 は後付けの玄人志向 USB3.0R-P2H2-PCIE。Groovyの UD-3000SA でHDDを繋いだあたりで期限を損ねてしまい、以後は他の接続実績のあるUSB HDDを接続しても認識しない状態に。

OSリセットすべし、という情報もあったけど、それは何か負けのような気がする…というか別のプロセスで長時間かかる md5sum チェックをしていたのでリセットするわけにもいかず。どーせ何かを再起動すればいけるんじゃね? と色々あさった結論。

最初は usb_storage を再読み込みさせたけど、反応が変わらなかった。dmesgのエラーログを見ると、どうやらHUBあたりがエラーを起こしているっぽい。ていうかM/BのUSB2.0ポートは普通にUSBメモリとか認識するので、 usb_storage は悪くない、らしい。

usb_storage より下層の(ハード寄りの)部分ってなんだっけ? と漁った結果、uhciとかohciとかそのあたりよね、と。それっぽい名前を lsmod で探したところ、 xhci-hcd が見つかった。

"xhci-hcd" の正体を確認すべくググると、正体どころか "Bug 717633 - USB3.0 harddisk not working with xhci_hcd module " なんて記事が出てきたので、内容読むまでもなくあぁこれぢゃね、等と。

再読み込みにあたり念のためアンロードしたけど、USBまわりなのでアンロードと同時にUSBキーボードとか色々使用不能に陥る可能性を危惧(作業はssh接続してたけど)。予め sudo -v で認証も突破した上で、連続実行するように仕向ける。

$ sudo modprobe -r xhci-hcd ; sudo modprobe xhci-hcd

その後 dmesg 見たら認識しなかったUSB HDDも無事認識してマウントできるようになってた。

CentOS 3.9環境のbashを最新版に更新する

色々あってOSが古いままの環境で、せめてbashだけをshellshockから回避したい。

CentOS 3.9のbashはバージョン2.5が最終。

ログインシェルなので単純にyum erase bash とかやると依存関係がバギバギ出てくる。なので上書きインストールで行く(ていうか最終目標はOSの入れ替えなので、ここであまり丁寧に作業して時間をとりたくない)。

ということで以下作業記録。

現在bash関連物品が入っている場所の確認。個々のファイルは見ていられないのでdirnameで端折る。

rpm -q --list bash|xargs -l -i dirname {} |uniq
/bin
/etc/skel
/usr/lib
/usr/share/doc
/usr/share/doc/bash-2.05b
/usr/share/doc/bash-2.05b/bashdb
/usr/share/doc/bash-2.05b
/usr/share/doc/bash-2.05b/complete
/usr/share/doc/bash-2.05b
/usr/share/doc/bash-2.05b/functions
/usr/share/doc/bash-2.05b
/usr/share/doc/bash-2.05b/loadables
/usr/share/doc/bash-2.05b/loadables/perl
/usr/share/doc/bash-2.05b/loadables
/usr/share/doc/bash-2.05b
/usr/share/doc/bash-2.05b/misc
/usr/share/doc/bash-2.05b
/usr/share/doc/bash-2.05b/scripts.noah
/usr/share/doc/bash-2.05b
/usr/share/doc/bash-2.05b/scripts.v2
/usr/share/doc/bash-2.05b/scripts
/usr/share/doc/bash-2.05b
/usr/share/doc/bash-2.05b/startup-files
/usr/share/doc/bash-2.05b/startup-files/apple
/usr/share/doc/bash-2.05b/startup-files
/usr/share/info
/usr/share/man/man1

現状のタイムスタンプを確認。

$ ls -l /bin/bash*
-rwxr-xr-x 1 root root 585908 May 30 2006 /bin/bash
lrwxrwxrwx 1 root root 4 Mar 2 2007 /bin/bash2 -> bash

$ ls -l /usr/share/info/bash*
-rw-r--r-- 1 root root 94034 May 30 2006 /usr/share/info/bash.info.gz

$ ls -l /usr/share/man/man1/bash*
-rw-r--r-- 1 root root 64921 May 30 2006 /usr/share/man/man1/bash.1.gz

最新版をビルド。bash 4.3にパッチまで当ててやっとshellshockが解消するので、パッチも全部当てる(正確には28まで当てればよかったはず)。

このとき上書きされるようにprefix、bindir、sysconfdirをいじる。基本的に/usr以下に入っているのに実行コマンドだけが /bin にあるのがいやらしい。

$ tar xfz bash-4.3.tar.gz
$ cd bash-4.3
$ for patchfile in `ls -1 ../bash43-*`; do echo $patchfile; patch -p0 < $patchfile; done
$ grep "#define PATCHLEVEL" patchlevel.h
#define PATCHLEVEL 30

$ ./configure --prefix=/usr --bindir=/bin --sysconfdir=/etc
$ make ; make check ; echo $?

0
$ ./bash --version
GNU bash, version 4.3.30(1)-release (i686-pc-linux-gnu)
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 

This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

上書きインストールする。

$ sudo make install

インストール結果確認。

$ which bash
/bin/bash

$ bash --version
GNU bash, version 4.3.30(1)-release (i686-pc-linux-gnu)
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 

This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

$ ls -l /bin/bash*
-rwxr-xr-x 1 root root 1832115 Oct 15 06:51 /bin/bash
lrwxrwxrwx 1 root root 4 Mar 2 2007 /bin/bash2 -> bash
-r-xr-xr-x 1 root root 6800 Oct 15 06:51 /bin/bashbug

$ ls -l /bin/bash*
-rwxr-xr-x 1 root root 1832115 Oct 15 06:51 /bin/bash
lrwxrwxrwx 1 root root 4 Mar 2 2007 /bin/bash2 -> bash
-r-xr-xr-x 1 root root 6800 Oct 15 06:51 /bin/bashbug
$ ls -l /usr/share/info/bash*
-rw-r--r-- 1 root root 486450 Oct 15 06:51 /usr/share/info/bash.info
-rw-r--r-- 1 root root 94034 May 30 2006 /usr/share/info/bash.info.gz

$ ls -l /usr/share/man/man1/bash*
-rw-r--r-- 1 root root 299110 Oct 15 06:51 /usr/share/man/man1/bash.1
-rw-r--r-- 1 root root 64921 May 30 2006 /usr/share/man/man1/bash.1.gz
-rw-r--r-- 1 root root 1817 Oct 15 06:51 /usr/share/man/man1/bashbug.1

man bash とか info bash の結果はちゃんと4.3が出てくるけど、旧バージョンのgzファイルが後々混乱の元になりそうなので、新バージョンの非圧縮ファイルをgzip圧縮したもので上書きしておく。

/bin/bash へのシンボリックリンクになっている/bin/shも、ちゃんとバージョンアップされた。

$ sh --version
GNU bash, version 4.3.30(1)-release (i686-pc-linux-gnu)
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 

This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

/usr/share/doc/bash-2.05b は実害無いし面倒くさいので後で削除しよう(そして忘れる)。

どっとはらい。

CentOSに後から X Windowを入れるとき

モジュールのロードに失敗してno screens となるとき
xorg-x11-drivers パッケージが入っているか確認する。
インプットメソッドの導入
ibus パッケージをインストール…だが他にも色々必要な感じだったので、とりあえず groupinstall で Japanese support を入れたほうが早いっぽい。(というか面倒くさくなってこれで済ませた)

あとはお好みのデスクトップを入れればOK。職場の環境はできるだけ軽くしたかったのでXfceを使っています。