RHEL6/CentOS6向けの3rdパーティーrepo

RHEL6/CentO6で使われているphpがver5.3.3と古い。
より新しいバージョンのphpを要求されている。

そんな時に、頼る先は、公式以外からリリースされているRPM群

yumでとってこれる先として代表的なもの

EPEL
Fedoraプロジェクトから出ているレポジトリ。
標準にないものを追加する方が主体で、オリジナルより新しいバージョンの提供はあまりやらない。
Cent OS6の場合「yum install epel-release」で追加できる。

RepoForge
旧名:RPMforge
標準に対するアップデートも行うし、オリジナルにないのの追加も行うし、で手広いもの。
ただ、範囲が広いので、問題が発生しやすいところがある。

IUS Community Project
mysql,php,pythonのバージョンアップを目的としたレポジトリ。
それ以外のソフトウェアについては基本的に提供されていない。
また、phpの細かいソフトウェアパッケージ群についても提供せず、基本部分のみとなっている。

Les RPM de Remi – Repository
phpのバージョンアップと、phpの細かいソフトウェアパッケージ群の提供を目的としている。
php関連をがっつり入れたい場合はコレになるかな?

・Oracle Linux
番外的なところがあるが、Oracle Linuxだと、追加のレポジトリで、MySQL 5.5/5.6対応のレポジトリが存在している。
状況によってはそちらを選択してもよいかもしれない。
参考:「Oracle Linux用の公開レポジトリについて」と「RHEL6/CentOS6をOracle Linuxにしてみる

CVE-2015-0235はRHEL4/CentOS4に影響する&修正版提供開始(2015/01/30 20:40版)

CVE-2015-0235 というglibcに大きめのバグが見つかった模様。

RedHat Enterprise Linux 4 / CentOS 4に対して影響があるのかどうかを調べてみた。

まずは、RedHat公式情報系

・RedHat Bugzilla:Bug 1183461 – (CVE-2015-0235) CVE-2015-0235 glibc: __nss_hostname_digits_dots() heap-based buffer overflow
 ・RHEL Knowledgebase Articles:GHOST: glibc vulnerability (CVE-2015-0235) / GHOST: glibc 脆弱性 (CVE-2015-0235)
 ・RHEL CVEデータベース:CVE-2015-0235
 ・RHEL4向け:RHSA-2015:0101:Critical: glibc security update
 ・RHEL5向け:RHSA-2015:0090:Critical: glibc security update
 ・RHEL6,RHEL7向け:RHSA-2015:0092:Critical: glibc security update

はい、RHEL4も対象になっています。

実際に確認してみるため、openwallにあるCVE-2015-0235についての詳細報告書「Qualys Security Advisory CVE-2015-0235 – GHOST: glibc gethostbyname buffer overflow」の「4 – Case studies」の記述を試してみる。

実行した際に「vulnerable」と出たら、問題あり。
「not vulnerable」だったら問題なし、というもの。

[root@cent4 201501]# mkdir security
[root@cent4 201501]# cd security/
[root@cent4 security]# rpm -qa|grep glibc|sort
警告: only V3 signatures can be verified, skipping V4 signature
glibc-2.3.4-2.57
glibc-2.3.4-2.57
glibc-common-2.3.4-2.57
glibc-devel-2.3.4-2.57
glibc-devel-2.3.4-2.57
glibc-headers-2.3.4-2.57
glibc-kernheaders-2.4-9.1.103.EL
[root@cent4 security]# cat > GHOST.c << EOF
> #include <netdb.h>
> #include <stdio.h>
> #include <stdlib.h>
> #include <string.h>
> #include <errno.h>
>
> #define CANARY "in_the_coal_mine"
>
> struct {
>   char buffer[1024];
>   char canary[sizeof(CANARY)];
> } temp = { "buffer", CANARY };
>
> int main(void) {
>   struct hostent resbuf;
>   struct hostent *result;
>   int herrno;
>   int retval;
>
>   /*** strlen (name) = size_needed - sizeof (*host_addr) - sizeof (*h_addr_ptrs) - 1; ***/
>   size_t len = sizeof(temp.buffer) - 16*sizeof(unsigned char) - 2*sizeof(char *) - 1;
>   char name[sizeof(temp.buffer)];
>   memset(name, '0', len);
>   name[len] = '\0';
>
>   retval = gethostbyname_r(name, &resbuf, temp.buffer, sizeof(temp.buffer), &result, &herrno);
>
>   if (strcmp(temp.canary, CANARY) != 0) {
>     puts("vulnerable");
>     exit(EXIT_SUCCESS);
>   }
>   if (retval == ERANGE) {
>     puts("not vulnerable");
>     exit(EXIT_SUCCESS);
>   }
>   puts("should not happen");
>   exit(EXIT_FAILURE);
> }
> EOF
[root@cent4 security]# ls
GHOST.c
[root@cent4 security]# gcc GHOST.c -o GHOST
[root@cent4 security]# ls
GHOST  GHOST.c
[root@cent4 security]# ./GHOST
vulnerable
[root@cent4 security]#

「vulnerable」なので、「問題あり」確定です。

修正版については、RHEL4の通常サポートは終了。現在はELSと呼ばれる特別な契約者向けに提供されているものだけが更新されています。

前述の「RHSA-2015:0101 Critical: glibc security update」にあるとおり、修正されたglibcのバージョンは「glibc-2.3.4-2.57.el4.2」となります。

ただ、このバージョンは通常の方法ではRHEL4およびCentOS4には提供されません。

しかし、RHEL4のソースを元にOracleで再構成した、Oracle Linux 4は、まだサポートを行っています。
こちらから、ファイルを持ってくることで対応が可能となっています。

Oracle Linux 4向けのSource RPMは、「https://oss.oracle.com/el4/SRPMS-updates/」にて提供されています。
Oracle LinuxではRHEL4とパッケージバージョンが若干異なり「glibc-2.3.4-2.57.0.1.el4.1」となります。
https://oss.oracle.com/el4/SRPMS-updates/glibc-2.3.4-2.57.0.1.el4.1.src.rpm

ただ、今回のことを受けて更新されたコンパイル済みのRPMは、glibc関連だけではなかったりします。
nptl-devel, nscdも更新されています。
このため、今回については、glibcのSource RPMだけを持ってきてコンパイルして適用、というのは、あまりお薦めできないような感じです。

コンパイル済みのRPMファイルについて、Oracle Linuxでは「Oracle Public Yum Server」としてレポジトリを公開しており、適切な設定を行うことで、RHEL4/CentOS4からOracle Linux 4に乗り換え、yumコマンドによるアップデートが行えるようになります。

コンパイル済みRPMファイル自体は「http://public-yum.oracle.com/repo/EnterpriseLinux/EL4/latest/」以下を探せば出てきますので、ページを「2015」で検索し出てくるパッケージが自分のサーバにインストールされているかを確認し、ダウンロードして適用する、ということが可能です。

しかし、依存関係解決とか面倒なので、これを機会にOracle Linux 4に乗り換えてしまう、というのも手かもしれません。

切り替え方法については、「RHEL4/CentOS4をOracle Linux4に!」にて紹介していますので、興味がある方は参照してみてください。
設定は非常に簡単です。

こちらの環境ではOralce Linux 4になっているため「yum update -y」で更新が完了しました。

更新後、再度テストプログラムを実行してみます。

[root@cent4 security]# ./GHOST
not vulnerable
[root@cent4 security]#

「not vulnerable」と出力されるので、脆弱性は修正されている、ということになります。

これで、一安心、といったところです。


<以下は修正版のglibcが出る前に書いたものです。資料として残しておきます>

glibcに大きめのバグが見つかった模様。
CVE-2015-0235

・RedHat Bugzilla:Bug 1183461 – (CVE-2015-0235) CVE-2015-0235 glibc: __nss_hostname_digits_dots() heap-based buffer overflow
 ・RHEL CVEデータベース:CVE-2015-0235
 ・RHEL5向け:RHSA-2015:0090-1:Critical: glibc security update
 ・RHEL6,RHEL7向け:RHSA-2015:0092-1:Critical: glibc security update

RHEL4/CentOS4についての記載が見付からない。

Oracle LinuxのSource RPM置き場 https://oss.oracle.com/el4/SRPMS-updates/ を見ても、2015/01/28 10:35時点では何も無し。

(2015/01/28 23:00 追加)
1時間ぐらい前に「GHOST: glibc vulnerability (CVE-2015-0235)」にRed Hat Enterprise Linux 4 Extended Life Cycle Supportに関する記述が追加された。
いまのところ修正版に関する記述はないが、RHEL4に脆弱性がある、という公式告知になっている。

(2015/01/29 19:30追加)
Red Hat Enterprise Linux ELS (v. 4)に対するSecurity Advisoryが公開された。
RHSA-2015:0101 Critical: glibc security update

ELS契約者向けに glibc-2.3.4-2.57.el4.2 としてリリースされたので、そのうちOracle Linuxにも波及してくるものと想定されるが、現状はまだ公開されていない。

(2015/01/30 14:20追加)
https://oss.oracle.com/el4/SRPMS-updates/ に、glibc-2.3.4-2.57.0.1.el4.1.src.rpmが置かれました。
Oralce Linux 4のpublic yumレポジトリのほう(repo url)にはまだ登録されていないようです。

(2015/01/30 16:30追加)
Oracle Linux 4のpublic yumレポジトリでの配布が始まりました。

以下の16:20ぐらいの段階ではi386(32bit)版のみだったのですが、16:37にはx86_64(64bit)版のディレクトリにもファイルが置かれ始めました。

i386(32bit)版
 http://public-yum.oracle.com/repo/EnterpriseLinux/EL4/latest/i386/getPackage/glibc-common-2.3.4-2.57.0.1.el4.1.i386.rpm
 http://public-yum.oracle.com/repo/EnterpriseLinux/EL4/latest/i386/getPackage/glibc-devel-2.3.4-2.57.0.1.el4.1.i386.rpm
 http://public-yum.oracle.com/repo/EnterpriseLinux/EL4/latest/i386/getPackage/glibc-headers-2.3.4-2.57.0.1.el4.1.i386.rpm
 http://public-yum.oracle.com/repo/EnterpriseLinux/EL4/latest/i386/getPackage/glibc-profile-2.3.4-2.57.0.1.el4.1.i386.rpm
 http://public-yum.oracle.com/repo/EnterpriseLinux/EL4/latest/i386/getPackage/glibc-utils-2.3.4-2.57.0.1.el4.1.i386.rpm
 http://public-yum.oracle.com/repo/EnterpriseLinux/EL4/latest/i386/getPackage/nptl-devel-2.3.4-2.57.0.1.el4.1.i386.rpm
 http://public-yum.oracle.com/repo/EnterpriseLinux/EL4/latest/i386/getPackage/nptl-devel-2.3.4-2.57.0.1.el4.1.i686.rpm
 http://public-yum.oracle.com/repo/EnterpriseLinux/EL4/latest/i386/getPackage/nscd-2.3.4-2.57.0.1.el4.1.i386.rpm

64bit(x86_64)版
 

(追加部分おわり)

openwallにあるCVE-2015-0235についての詳細報告書「Qualys Security Advisory CVE-2015-0235 – GHOST: glibc gethostbyname buffer overflow」の「4 – Case studies」には事象確認方法が記載されている。

下記をコンパイルして、実行した際に「vulnerable」と出たら、問題あり。
「not vulnerable」だったら問題なし、というもの。

#include <netdb.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <errno.h>

#define CANARY "in_the_coal_mine"

struct {
  char buffer[1024];
  char canary[sizeof(CANARY)];
} temp = { "buffer", CANARY };

int main(void) {
  struct hostent resbuf;
  struct hostent *result;
  int herrno;
  int retval;

  /*** strlen (name) = size_needed - sizeof (*host_addr) - sizeof (*h_addr_ptrs) - 1; ***/
  size_t len = sizeof(temp.buffer) - 16*sizeof(unsigned char) - 2*sizeof(char *) - 1;
  char name[sizeof(temp.buffer)];
  memset(name, '0', len);
  name[len] = '\0';

  retval = gethostbyname_r(name, &resbuf, temp.buffer, sizeof(temp.buffer), &result, &herrno);

  if (strcmp(temp.canary, CANARY) != 0) {
    puts("vulnerable");
    exit(EXIT_SUCCESS);
  }
  if (retval == ERANGE) {
    puts("not vulnerable");
    exit(EXIT_SUCCESS);
  }
  puts("should not happen");
  exit(EXIT_FAILURE);
}

さて・・・CentOS4ではどうなっているのか?

[root@cent4 201501]# mkdir security
[root@cent4 201501]# cd security/
[root@cent4 security]# rpm -qa|grep glibc|sort
警告: only V3 signatures can be verified, skipping V4 signature
glibc-2.3.4-2.57
glibc-2.3.4-2.57
glibc-common-2.3.4-2.57
glibc-devel-2.3.4-2.57
glibc-devel-2.3.4-2.57
glibc-headers-2.3.4-2.57
glibc-kernheaders-2.4-9.1.103.EL
[root@cent4 security]# cat > GHOST.c << EOF
> #include <netdb.h>
> #include <stdio.h>
> #include <stdlib.h>
> #include <string.h>
> #include <errno.h>
>
> #define CANARY "in_the_coal_mine"
>
> struct {
>   char buffer[1024];
>   char canary[sizeof(CANARY)];
> } temp = { "buffer", CANARY };
>
> int main(void) {
>   struct hostent resbuf;
>   struct hostent *result;
>   int herrno;
>   int retval;
>
>   /*** strlen (name) = size_needed - sizeof (*host_addr) - sizeof (*h_addr_ptrs) - 1; ***/
>   size_t len = sizeof(temp.buffer) - 16*sizeof(unsigned char) - 2*sizeof(char *) - 1;
>   char name[sizeof(temp.buffer)];
>   memset(name, '0', len);
>   name[len] = '\0';
>
>   retval = gethostbyname_r(name, &resbuf, temp.buffer, sizeof(temp.buffer), &result, &herrno);
>
>   if (strcmp(temp.canary, CANARY) != 0) {
>     puts("vulnerable");
>     exit(EXIT_SUCCESS);
>   }
>   if (retval == ERANGE) {
>     puts("not vulnerable");
>     exit(EXIT_SUCCESS);
>   }
>   puts("should not happen");
>   exit(EXIT_FAILURE);
> }
> EOF
[root@cent4 security]# ls
GHOST.c
[root@cent4 security]# gcc GHOST.c -o GHOST
[root@cent4 security]# ls
GHOST  GHOST.c
[root@cent4 security]# ./GHOST
vulnerable
[root@cent4 security]#

駄目でした。

とりあえず、続報待ちということで・・・

(2015/01/30 16:50追記)
Oralce public yum repoで提供されたのでアップデートを行い、試験実施。

[root@cent4 security]# ./ghost
not vulnerable
[root@cent4 security]#

問題がなくなったことを確認できました。

なお、Oracle Linux public レポジトリからyumコマンドを使ってファイルを持ってこれるようにするには「RHEL4/CentOS4をOracle Linux4に!」で紹介しているようにOracle Linuxに切り替えてしまう、というのが簡単でいいと思います。

GULEEK i8というバッテリー付小型Win8.1 PCが$104

dealextremeを見ていたら、面白そうなものを発見

GULEEK i8という名前のWindows 8.1 PCです。

スペックは

・Windows 8.1
・RAM 2GB ROM 16GB
・Intel 4コア Baytrail Z3735 1.8GHz

という、まぁ、マウスコンピュータのスティックPCみたいな感じのものですが、「バッテリー 3000mAh搭載」しています。

「FIRST WIRELESS MINI BOX」と書かれているので、ディスプレイ出力もワイヤレス可能なのかなぁ?と思いつつも、はっきりと記載されていないのでちょっとわからないところだったりします。

年明け1月6日から出荷開始だそうで、ちょっと面白いかもしれませんね。

RHEL6でSAN Boot multipath構成時、initramfsを再作成するとmultipath関連が組み込まれないことがある

RedHat Enterprise Linux/Cent OS6.5環境で、SAN Boot multipath構成を作成した。

構築後、バックアップを取得し、別のLUNにリストアし、そのディスクからブートをさせた。

ディスク自身が持つ、WWIDが変更になったため、multipath構成が外れた状態で起動してくる、というのは想定通りだったのだが、設定を修正し、initramfsを再作成して、再起動しても、multipath構成にならず、悩んだ。

原因は「How do I rebuild the initramfs with multipath.」であった。

普通にdracutでinitramfsを再作成すると、multipath関連モジュールが組み込まれていないものができあがっていた。
これをmultipathモジュールを組み込むことを強制させるようにして、解決した。

手順

1. とりあえず起動
2. 現在のディスクのwwidを確認
現在のディスクの「/dev/sd?」を確認し、そのディスク名に対して「scsi_id –whitelist /dev/sd?」を実行して確認する。

# df -h
/dev/sdb3 ~ /
tmpfs ~ /dev/shm
/dev/sdb1 ~/boot
# scsi_id --whitelist /dev/sdb
<wwid>
#

3. /etc/multipath.conf内のwwid変更
multipath.conf内に「wwid 値」という記述があるので、現在の値に変更する。

4. /etc/multipath/bindings内のwwid変更
bindings内に「mpatha 値」といった記述があるので、現在の値に変更する。
(注: mpathaをsdbとかに変更しないこと)

5. 古いinitramfsをバックアップ

6. intiramfsを作成

# dracut -v -f -a multipath --include /etc/multipath /etc/multipath
#

もしくは、/etc/dracut.confに以下の記述を行ってから、dracutを実行する。

# Dracut modules to add to the default
add_dracutmodules+="multipath"

7. 再起動

Windows Vistaで4KセクタディスクにシステムコピーしたらWindows Updateなどがエラーになる

Windows VistaのThinkCentreのHDDに不良セクタが発生し始めた。

仕方がないので新しいディスクを買い、CloneZillaを使い、不良セクタがあっても無視して次へ進む、というオプションを選んでデータ移行を行った。
(ちなみに、320GB HDD→1TB HDD)

移行後、新しいディスクから起動はしたものの、Windowsのアプリケーションログに以下のエラーが・・・

エラー 2014/11/23 10:45:12 ESENT 412 Logging/Recovery
wuaueng.dll (1416) SUS20ClientDataStore: ログ ファイル C:\Windows\SoftwareDistribution\DataStore\Logs\edb.log のヘッダーを読み取れません。エラー -546 が発生しました。

エラー 2014/11/23 10:43:16 ESENT 412 Logging/Recovery
InputPersonalization (3844) InkStore: ログ ファイル C:\Users\liliy\AppData\Local\Microsoft\InputPersonalization\edb.log のヘッダーを読み取れません。エラー -546 が発生しました。

また、Windows Updateを実行しても、Windows Updateサービスが起動していない、と修正プログラムが適用できない。

いろいろ調べてみると、どうやら、「Applications that are built on ESENT and that run on a Windows Vista-based or Windows Server 2008-based computer may not work correctly after the reported physical sector size of the storage device changes 」らしい。

旧来の512バイトセクタのディスクではなく、4Kバイトセクタのディスクに変えたことによる問題らしく、Windows VistaとWindows Server 2008では発生する事象らしい。
修正は、上記のページで配布されている修正プログラムを適用すること。

問題は、現象が発生してからでは修正プログラムが適用できない、ということ。(Windows Updateサービスが正常に起動しないため、適用できない)

なので、ディスクコピーを行う前に、修正プログラムを適用する必要がありました。

適用後、再度ディスクコピーを行うことで、エラーは解消されました。

モバイルバージョンを終了