CentOS 6 32-bit の自宅サーバーメモ

6.5→6.6バージョンアップ時の「Your BIOS broken」エラー

サブPC機上のOSアップデート後、再起動してログインパスワード入力後に「Your BIOS broken」なるエラーメッセージが表示されました。

下の画像は、その時の自動バグ報告ツール ABRT（Automatic Bug Reporting Tool）のスクリーンショットです。

Your BIOS broken とは何なのかネット検索してみると CPUがintel VT-d（インテルバーチャライゼーション・テクノロジー）をサポートしている場合エラーメッセージが表示されるようです。

サーバー機は該当しませんがサブPCはこれに該当します。

対処法は２つ、①GRUB設定ファイルに起動オプションコマンドを追記。②BIOS設定メニューからVT-dを"無効"に設定。とのことなので、確認してみました。

（参照先：CentOS mailing list ）

①GRUB設定ファイルに起動オプションコマンド追記

grub.conf に「intel_iommu=off」を追記します。

IOMMU・・・I/O仮想化支援機能 （Intel VT-d, AMD-Vi）

端末から

 # nano /etc/grub/grub.conf

でgrub設定ファイルの16行目（fig1）

linux /boot/vmlinuz-2.6.32-504.el6.i686 ro … 

の行の最後尾にスペースを入れて

 … crashkernel=auto intel_iommu=off

の様に追記します（fig2）

編集保存後、再起動してみるも残念ながら当方の環境では変化はありませんでした。

念のため端末から

 # dmesg | grep -e DMAR -e IOMM

で IOMMU が無効になっているのを確認しました（fig3）

次は、②を試してみます。

②BIOS設定メニューからVT-dを「無効」に設定

下の画像は BIOS設定画面の写真です。設定保存後起動すると Your BIOS broken は表示されなくなりました。

しかし、これではサブPCにインストールしている全てのOSで仮想PCが使えなくなってしまうので有効な解決策にはならないですね。

VT-dの設定は「有効」に戻しておきます。

まとめ

結果的に①、②の方法では解決出来ませんでした。Your BIOS brokenなんて心臓に良くないですね。もう少し適切な表現があると思うのですが。

まあしかし、自宅サーバー機には影響しない事なので「6.6」へ バージョンアップしました。

2016年12月追記｜CentOS 6.8にバージョンアップしたところ上述のエラーメッセージは出なくなりました。

ダイナミックDNSの自動更新アプリ「DiCE」の不具合

我が家のグローバルIPアドレスは、固定IPではないので自宅サーバー運用のためダイナミックDNSに登録しています。

従って、ISPの都合やルーターの再起動等でグローバルIPアドレスが変更された時、或いはグローバルIPアドレスの変更がなくても一定期間内にグローバルIPアドレスを通知して登録を更新しなければなりません。更新しないと登録を削除されてしまうのです。

そこで、この更新手続きを自動的にやってくれる「DiCE」を導入しました。グローバルIPアドレスが変更された場合は問題なく動作しています。

グローバルIPアドレスに変更がない時は、1週間（７日）毎に自動更新するように設定しているのですが、これがうまく動作してくれないのです。

例えばパソコン（サーバー機）を再起動した後、3週目までは自動更新してくれるのですが、判で押した様に４週目以降ピタッと更新してくれません。こうなると手動でイベント実行するしかありません。そしてパソコンを再起動しないとそのままずっと更新してくれません。

再起動後は、また3週目までは自動更新して４週目以降更新しない。と、ずっとこの繰り返しです。さんざんネット上を彷徨ったのですが原因も解決策も見つけられませんでした。

そこで「crontab」を使って、毎月１日と15日にパソコン（サーバー機）を再起動するように設定して、暫らく様子を見る事にしました。

crontab を設定する

自宅サーバーに設定する前に、手持ちのサブPC（CentOS6.6）でテストします。テストのタスクは、「今から40分間10分毎に再起動する」を crontab の「run-parts」で設定します。（10分毎にしたのは、テスト終了後設定を無効化する時間を考慮しての事です）

まず、実行するスクリプトファイルを置いておくディレクトリ reboot.hourly を /etc 下に作成し、その中に再起動スクリプトファイル reboot.sh を作成します。

端末から

 # mkdir /etc/reboot.hourly
 # nano reboot.sh

#!/bin/sh
/sbin/shutdown -r now

保存後、実行権を付与します

 # chmod 755 reboot.sh

次に、/etc/crontab に「今から40分間10分毎に再起動する」を記述します。

 # nano /etc/crontab

00-40/10 * * * * root run-parts /etc/reboot.hourly

下の画像は、記述後の crontab のスクリーンショットです。

（管理人は、vimエディタが苦手なので「crontab -e」を使いたくありません）

保存して、nanoエディタを閉じます。すると10数分後再起動が実行され、10分毎に再起動が繰り返される事を確認しました。テスト終了後は、crontabの記述はコメントアウトしておきます。

サーバー機も同様に、実行するスクリプトファイルを置いておくディレクトリ reboot.monthly を /etc 下に作成し、その中に再起動スクリプトファイル reboot.sh を作成します。忘れずに実行権を付与しておきます。

次に、/etc/crontabに「毎月1日と15日の午前4時00分に再起動する」を を記述します。

 # nano /etc/crontab

00 4 1,15 * * root run-parts /etc/reboot.monthly

下の画像は、記述後の crontab のスクリーンショットです。

保存して、nanoエディタを閉じます。

以上で設定完了です。

ダイナミックDNSの自動更新方法の変更

前項の設定で2ヵ月程様子を見ていたのですが、やはり更新は停止していました。

ここで DiCE による自動更新は諦めて、自宅サーバー機が利用しているダイナミックDNSサイト MyDNS.JP 推奨の方法に変更しました。

その方法は、「crontabで5分毎に通知するスクリプトを実行する」です。つまり前項と同じ手順で設定します。

crontabの設定

まず、実行するスクリプトファイルを置いておくディレクトリ cron.every5min を /etc/ 下に作成し、その中に通知スクリプトファイル mydns.sh を作成します。

端末から

 # mkdir /etc/cron.every5min
 # nano /etc/cron.every5min/mydns.sh

#!/bin/sh
/usr/bin/wget -O - 'http://ユーザーID:パスワード@www.mydns.jp/login.html' 

保存後、実行権を付与します

 # chmod 755 mydns.sh

次に、/etc/crontab に「今から5分毎にmydns.shを実行する」を記述します。

 # nano /etc/crontab

*/5 * * * * root run-parts /etc/cron.every5min

この時前項で設定していた DiCE の設定はコメントアウトもしくは削除します。

下の画像は記述後の crontab のスクリーンショットです。

保存して、nanoエディタを閉じます。およそ10分後位に MyDNS.JP にログインして IPアドレスが更新されていることを確認しました。

以上で設定完了です。

2018年7月追記｜MyDNS.JP推奨のcrontab設定後、運用開始から現在まで問題なく動作しています。

glibcの脆弱性「GHOST」への対応

Linuxで使用されているGNU C Library（glibc）にバッファオーバーフローの脆弱性が存在するようです。

対象となるディストリビュージョンは、2015年1月以前の「RedHat Enterprise Linux 6 および CentOS 6他」です。

該当するバージョンは

• glibc-2.12-1.132 以前のもの

修正バージョンは

他。（上記は当方の環境に必要なパッケージのみ）

我が家の自宅サーバー（CentOS 6.6）はこれに該当していないのですが、修正バージョンより低いバージョン（glibc-2.12-1.149.el6_6）なのでアップデートしてバージョンアップしました。

まず、現在のバージョンを確認します。

端末から

 # rpm -qa | grep glibc

を実行してみると下画像のように修正バージョンと違う事が分かります。

次に、glibcをアップデートします。

端末から

 # yum update glibc
  これでいいですか？[y/N] y

を実行（fig4,fig5）します。最後にglibcのバージョンを確認（fig6）します。

以上で、glibcの脆弱性への対応完了です。

Sambaの脆弱性への対応

Windows互換のファイルサーバー Samba（サンバ）に脆弱性が存在するようです。Sambaクライアントから任意コードの実行が可能との事です。

http://www.samba.gr.jp/doc/whatsamba.html
 Sambaとは 日本 Samba ユーザ会

対象となるディストリビュージョンは「RedHat Enterprise Linux 6 および CentOS 6他」です。

該当するバージョンは

• samba 3.5.0からsamba 4.2.0rc4まで

修正バージョンは

他。（上記は当方の環境に必要なパッケージのみ）

我が家のSambaサーバーはこれに該当しているのですが、自宅のサブネット内のみの使用で外部との接続はしていません。

しかしアップデートしてバージョンアップしました。

下の画像はアップデート前のSambaのバージョンの確認と、アップデート可能なSambaのバージョンを表示させた時のスクリーンショットです。

現在のバージョンの確認は端末から

 # rpm -qa | grep samba

を実行。アップデート可能なバージョンは

 # yum check-update samba*

で表示。そして

 # yum update samba
 # yum update samba-libs

でSamba脆弱性への対応完了です。

パーティション管理コマンド「fdisk」の不具合？

ふと自宅サーバー機のHDDパーティション構成はどうだったか確認しておこうと思い立って、サブネット内リモートからfdiskコマンドを実行したら表示内容がおかしい事に気が付きました。

リモート端末から

 $ sudo fdisk -l

とfdiskコマンドを実行するとなんと第1パーティションの開始位置が「1セクター」とありえない値が表示されているのです。

そこで同サブネット内のサブPCの第4HDD（/dev/sdd）にインストールしているCentOS6.6を起動して第2HDD（/dev/sdb）に対してfdiskコマンドを実行して見るとやはり第1パーティションの開始位置が 1セクターと表示（fig7）されます。

次にパーティションエディタ Gparted を起動して/dev/sdbを検索すると第1パーティションの開始位置は「2048セクター」と正常に表示（fig8）されました。

確認のため同じ第2HDDの第2パーティション（/dev/sdb2）にインストールしているPearLinux6.1を起動してfdiskコマンドを実行してみると正常に表示（fig9）されます。

どうもCentOS6.6のfdiskコマンドはよく分かりません。少し前の古い仕様のfdiskコマンドとも違う感じがします。

いずれにしてもHDDやSSD内のパーティション状態を正しく表示出来ていない訳なのでCentOS6.6のfdiskコマンドは使用不可としましょう。

...と書いてはみたもののよくよく調べてみれば、始点・終点はセクター単位ではなく「シリンダー単位」で表示している事が分かりました。

これはつまりパーティション開始セクターが63であっても2048であっても同じ始点1シリンダーと表示するのでしょうか？

シリンダー単位でパーティションを作成して物理セクターやOSエミュレートセクターとの整合性は保たれるのでしょうか？ 一抹の不安を感じます。

SSDや4K-HDD等の物理4096バイトセクターが主流のこのご時世にパーティションテーブルをシリンダー単位で表示しているとは思ってもみませんでした。

なお、セクター単位での表示も出来る事が分かったので参考までに載せておきます。

下の画像はオプションコマンド「-u」でfdiskを実行した時のスクリーンショットです。

端末から

 $ sudo fdisk -u /dev/sdb

コマンド（ｍでヘルプ）：m
     ⋮
コマンド（ｍでヘルプ）：p

を実行すればセクター単位でパーティションテーブルが表示されます。

ntpdの脆弱性への対応

ホスト機のシステム時間のズレを補正するアプリ ntpd（Network Time Plotocol Daemon）に幾つかの脆弱性があったようです。（2014-12-22公開）

対象となるディストリビュージョンは「RedHat Enterprise Linux 6 および CentOS 6他」です。

該当するバージョンは JVNによると

• ntpd 4.2.8 およびそれ以前

となっていますが CentOS 6での修正バージョンは

以降です。

我が家のサーバー機の ntpdは 4.2.6p5-1.el6.centos でこれに該当していたのですが ntpクライアントのみの稼働で ntpサーバーは設定していないのでこの脆弱性の影響はなく一年近く放置していました。

この度 CentOS 6.6を6.7にバージョンアップしようと思いリリ－スノートを見るとその必要はなさそうなので ntpd脆弱性のみアップデートしました。

下の画像はアップデート後のスクリーンショットです。

アップデート後のバージョンは

• 4.2.6p5-5.el6.centos.2

となりました。

現在のバージョンの確認は端末から

 # rpm -qa | grep ntp

を実行。

 # yum update ntp
 # service ntpd restart

でntpd脆弱性への対応完了です。

glibcの脆弱性への対応

Linuxで使用されているGNU C Library（glibc）にバッファオーバーフローの脆弱性が存在するようです。

対象となるディストリビュージョンはインターネットに接続されている全ての Linuxです。

該当するバージョンは

• glibc-2.12-1.166.el6 以前のもの

修正バージョンは

他。（上記は当方の環境に必要なパッケージのみ）

参照先｜[CentOS-announce] CESA-2016:0175 Critical CentOS 6 glibc Security Update

glibcをアップデートします。

端末から

 # yum update glibc
  これでいいですか？[y/N] y

を実行します。

以上で glibcの脆弱性への対応完了です。

2016年9月現在のバージョンは

CentOS 6の脆弱性にまとめて対応｜6.6を6.8へアップグレード

2016年1月から11月まで公開された CentOS 6に関係すると思われる脆弱性の発生件数と、その中で深刻度が危険とされているパッケージををざっと挙げてみました。参照先｜JVN iPedia 脆弱性対策情報データベース

とまあこんな具合で自宅サーバーといえば 2014年11月にバージョン6.5から6.6へアップグレードして以降、個別のパッケージの対応だけしていました。

しかしこのように表にしてみると流石にのまま運用していくのはまずいと思うのでこの際 CentOS 6の最新バージョンである 6.8 にアップグレードしました。

端末から

 # yum update

を実行し、595件のパッケージ更新とインストールは無事完了し各サーバーも問題ないことを確認しました。

2017年 5月バージョン 6.8 から 6.9 へアップグレードしました

2018年11月バージョン 6.9 から 6.10 へアップグレードしました

▲ 目次へ