SIOS "OSSよろず" ブログ出張所

Trouble-Maker モジュールを作成しました

2012-02-27T16:00:00.000+09:00

2月がそろそろ終わり、暖かな春が訪れることを心待ちにしている鎌田です。

以前、「Trouble Maker を触ってみました」という記事で Trouble-Maker を軽く触りましたが、今回は Trouble-Maker のトラブルを引き起こすモジュールを作成しました。

SIOS-OSS / sios-troublemaker-modules: https://github.com/SIOS-OSS/sios-troublemaker-modules

この記事を公開する時点ではまだモジュールが1つしかありませんが、今後増やしていく予定です。また、現時点では対応 OS は RHEL5 とそれに準ずるクローン OS のみです。

Trouble-Maker のインストール方法 (おさらい)

以前の記事のインストール方法は大きく変わりませんが、RHEL に含まれていないモジュールを RPMforge から入手するという方法を紹介していましたが、今回は Fedora プロジェクトで RHEL 向けにメンテナンスしている EPEL を使う方法を紹介します。

# rpm -Uvh http://dl.fedoraproject.org/pub/epel/5/i386/epel-release-5-4.noarch.rpm
# yum install perl-Archive-Tar perl-YAML
# wget http://sourceforge.net/projects/trouble-maker/files/trouble-maker/0.11/trouble-maker-0.11.tgz/download
# cd /
# tar xzvf /path/to/trouble-maker-0.11.tgz

モジュールのインストール方法

今回、モジュールを github で公開していますので、入手に git コマンドが必要になります。EPEL に git が存在しますので、以下のように yum コマンドでインストールしてください。

# yum install git

次に、以下のコマンドを実行し、github から Trouble-Maker モジュールを入手します。

# git clone http://github.com/SIOS-OSS/sios-troublemaker-modules.git

これで、カレントディレクトリに sios-troublemaker-modules というディレクトリが作成され、その中には今回公開した Trouble-Maker モジュールが含まれています。

次に、入手した Trouble-Maker モジュールをインストールします。以下のコマンドを実行してください。

# /usr/local/trouble-maker/bin/pack_kitbag.pl ./sios-troublemaker-modules/ /usr/local/trouble-maker/kitbag/

これで Trouble-Maker モジュールのインストールが完了しました。

今回公開したモジュールは1つだけですので、試される方は以下のコマンドを実行してトラブルを発生させてください。

# /usr/local/trouble-maker/bin/trouble-maker.pl  --version=RHEL_5 --selection=dns-cannot_resolve

Mac 風 Linux をインストールしてみました

2012-02-23T13:00:00.000+09:00

ご無沙汰しております、サイオステクノロジーの稲垣です。

先日某 IT ニュースサイトで Mac 風 Linux を見かけたので、気になってインストールしてみました。
今回はインストールのみで、ほとんどいじっていません。触れてみた感想については又の機会に…。

今回インストールしてみたのは、この 2 つの OS です。

Comice OS 4.0
Fake OSX

※Comice OS は、Pear OS の後継にあたるものです。

ログイン後のデスクトップ画像を比較してみましょう。

まずは Comice OS からいきます。

Dock もそうですが、Mac の App Store の様なアイコンの Pear Appstore というものまであります。

そして左上に注目してください。なんと Apple のものにそっくりなロゴがあります。comice は洋梨の品種みたいなので、このロゴは洋梨ということで間違いないでしょう。それにしても林檎と洋梨…似てますね。

次は Fake OSX のデスクトップ画面です。

こちらは Comice OS 以上にアイコンが似ているものが多いです。Mac の Finder、メールのアイコンなどですね。2 枚目の画像には、新旧 iTunes のアイコンまであります。

両方共 Mac OS に似ている部分はありますが、個人的には Dock と洋梨のロゴが決め手で Comice OS の方がより似ている気がします。

ちなみにこれらの OS は Ubuntu がベースとなっているので、Ubuntu 使いで気になった方はぜひ試してみてください。

サブドメインの管理を委任する

2012-02-22T12:00:00.000+09:00

こんにちは。サイオステクノロジーの小川です。

Google Appsを導入しよう(BIND9設定編) では、DNSサーバのマスター、スレーブの構築方法を紹介をしました。今回は、サブドメインの管理を別のDNSサーバに委任する方法について簡単に紹介をします。

サブドメインの管理を委任する目的として、組織のゾーンが大きくなったときに DNSサーバの管理の負担を減らすことや、ネットワークのトラフィックを分散させること、等が挙げられます。

例として、ある組織 (example.com) に OSS という組織が新設されたので、oss.example.com のサブドメインを追加します。サブドメインの管理は別のDNSサーバに委任します。

マスターサーバの設定例

ゾーンデータファイルを編集します。


# vim example.com.db

< ゾーンデータファイルの記述例 >


$TTL 86400
@                     IN  SOA    ns1 root (
                      2012022001 ; Serial
                      10800      ; Refresh   
                      3600       ; Retry     
                      604800     ; Expire   
                      86400 )    ; Minimum

                      IN NS      ns1
                      IN NS      ns2
ns1                   IN A       xxx.xxx.xxx.147 ; マスターサーバ
ns2                   IN A       xxx.xxx.xxx.91 ; スレーブサーバ

ns1.oss               IN A       xxx.xxx.xxx.87 ; サブドメインのマスターサーバ
ns2.oss               IN A       xxx.xxx.xxx.89 ; サブドメインのスレーブサーバ

ここでは、サブドメインのマスターサーバを ns1.oss.example.com、サブドメインのスレーブサーバをns2.oss.example.com としています。

サブドメインのマスターサーバの設定例

zone ステートメントを記述します。


# vim oss.example.com.zone

< zone ステートメントの記述例 >


zone "oss.example.com" IN {
 type master;
 allow-update { none; };
 allow-transfer { xxx.xxx.xxx.89; };
 file "oss.example.com.db";
};

※ named.conf で oss.example.com.zone を include しています。

ゾーンデータファイルを作成します。


# vim oss.example.com.db

< ゾーンデータファイルの記述例 >

 
$TTL 86400
@                    IN  SOA    ns1 root (
                     2012022001 ; Serial
                     10800      ; Refresh   
                     3600       ; Retry     
                     604800     ; Expire   
                     86400 )    ; Minimum

                     IN NS      ns1
                     IN NS      ns2
                     IN A       xxx.xxx.xxx.86

ns1                  IN A       xxx.xxx.xxx.87 ; サブドメインのマスターサーバ
ns2                  IN A       xxx.xxx.xxx.89 ; サブドメインのスレーブサーバ

サブドメインのスレーブサーバの設定例

zone ステートメントを記述します。


# vim oss.example.com.slave.zone

< zone ステートメントの記述例 >


zone "oss.example.com" IN {
                type slave;
                masters { xxx.xxx.xxx.89; };
                file "slaves/oss.example.com.slave.db";
};

※ named.conf で oss.example.com.slave.zone を include しています。

以上です。

連載「libvirt を利用して日々の作業を効率化」第２回

2012-02-21T18:00:00.000+09:00

こんにちは、OSSテクノロジーセンターの原です。

さて、前回は Ruby のスクリプトから libvirt にアクセスし、ゲストの一覧を取得するところまでできました。

連載「libvirt を利用して日々の作業を効率化」第１回

前回までのおさらいとしては

libvirt は Red Hat 社が中心に開発する、仮想化管理用の標準 API
libvirt には様々な言語バインディングがる
Ruby から API にアクセススして、仮想マシン一覧を出してみる

ここまでですね。

今回はここから一歩進んで、Web アプリとしての機能を持たせて行きましょう。

今回利用する sinatra についてですが、細かい使い方については割愛させて頂きます。

…と言っても、公式に非常にわかりやすいドキュメントがありますので、初めての方はそちらをざっと眺めてもらえればと思います。

Sinatra: README (Japanese)

ではお約束通り、前回インストールした sinatra の最も簡単な Hello world 画面をブラウザに表示するところまでやってみましょう。


# mkdir webvirt
# cd webvirt
# vim webvirt.rb

webvirt.rb:


#!/usr/bin/ruby
require 'rubygems'
require 'sinatra'

get '/' do
  'Hello world!'
end

実行権限を与えてアプリを立ち上げましょう。


# chmod +x webvirt.rb 
# ./webvirt.rb

ブラウザから http://webvirt:4567/ にアクセスしてみましょう。

(※ webvirt の部分は適宜 IP アドレス等に読み替えてください。また、ファイアウォールが閉まっている場合、該当ポート開放をお忘れなく。)

Hello world が表示できたでしょうか？アプリを止めるには Ctrl + c です。

できましたら libvirt との連携を考えてみましょう。

前回最後に書いたスクリプトをそのまま Web に出してみましょう。

前回の get_vm_list.rb:


#!/usr/bin/ruby
require 'libvirt'
conn = Libvirt::open("qemu+ssh://root@kvmhost/system")
vm_list = conn.list_defined_domains
puts vm_list

これと同じ機能を持つ Web 画面を作ってみましょう。

webvirt.rb:


#!/usr/bin/ruby
require 'rubygems'
require 'sinatra'
require 'libvirt'

get '/' do
  conn = Libvirt::open("qemu+ssh://root@kvmhost/system")
  @vm_list = conn.list_defined_domains
  erb :index
end


# mkdir ./views
# vim views/index.erb

views/index.erb:


<b>My KVM VMs</b>
<hr>
<% for vm in @vm_list %>
  <%= vm %><br>
<% end %>

1つのファイル(webvirt.rb)だけで全てを完結させても良いのですが、見通しが悪くなるので、処理系と画面のファイルは分けてみました。

中身を軽く見て行きましょう。

webvirt.rb で require 'libvirt' して、conn = Libvirt::open? で接続、conn.list_defined_domains でリストを取得しています。

ここまでは前回と同じですね。

views/index.erb で画面を作りつつ、@vm_list の中身を for 文で展開しつつ、改行を入れておきました。

ここまでできたら、再びアプリを起動して、ブラウザからアクセスしてみてください。


# ./webvirt.rb

画面にリストが表示できたでしょうか？

前回も最後に書きましたが、list_defined_domains メソッドは非アクティブなゲストマシンのリストを取得します。

次はアクティブなゲストマシンのリストも一緒に表示しましょう。

webvirt.rb:


#!/usr/bin/ruby
require 'rubygems'
require 'sinatra'
require 'libvirt'

get '/' do
  conn = Libvirt::open("qemu+ssh://root@kvmhost/system")
  @act_vm_list = conn.list_domains
  @sby_vm_list = conn.list_defined_domains
  erb :index
end

views/index.erb


<b>My KVM VMs</b>
<hr>
Active VMs<br>
<% for act_vm in @act_vm_list %>
  <%= act_vm %><br>
<% end %>

<hr>
Standby VMs<br>
<% for sby_vm in @sby_vm_list %>
  <%= sby_vm %><br>
<% end %>

どうでしょう？アクティブ・非アクティブ両方のゲストマシンの一覧がでましたね。

ところで、アクティブなゲストマシンの方は、名前でなくて ID で表示されていますね。

大変面倒なことに list_domains と list_defined_domains は若干挙動が違うのです。ちょっと格好が悪いのでこれは後々直すことにしましょう。

詳しくは各メソッドの詳細をご確認ください。

いかがでしたでしょうか。

少し長くなってしまいましたので、仮想マシンのパワーオン/オフは次回以降に回したいと思います。

ではでは。

連載「Linux コマンド動作徹底解析」"ls -l" 編第2回

2012-02-20T13:42:00.000+09:00

サイオステクノロジー金田です。
週１連載の予定でしたが、先週は諸事情により投稿できませんでした。申し訳ありません。

では、早速 "ls -l" 編第2回を進めていきます。

今回は以下の範囲を見ていきます。
以下ファイル名が省略されている場合は、前のコードと同じファイルです。行頭の数字は行番号です。

coreutils-8.4/src/ls.c:


1228 
1229 int
1230 main (int argc, char **argv)
1231 {
1232   int i;
1233   struct pending *thispend;
1234   int n_files;
1235 
1236   /* The signals that are trapped, and the number of such signals.  */
1237   static int const sig[] =
1238     {
1239       /* This one is handled specially.  */
1240       SIGTSTP,
1241 
1242       /* The usual suspects.  */
1243       SIGALRM, SIGHUP, SIGINT, SIGPIPE, SIGQUIT, SIGTERM,
1244 #ifdef SIGPOLL
1245       SIGPOLL,
1246 #endif
1247 #ifdef SIGPROF
1248       SIGPROF,
1249 #endif
1250 #ifdef SIGVTALRM
1251       SIGVTALRM,
1252 #endif
1253 #ifdef SIGXCPU
1254       SIGXCPU,
1255 #endif
1256 #ifdef SIGXFSZ
1257       SIGXFSZ,
1258 #endif
1259     };
1260   enum { nsigs = ARRAY_CARDINALITY (sig) };
1261 
1262 #if ! SA_NOCLDSTOP
1263   bool caught_sig[nsigs];
1264 #endif
1265 
1266   initialize_main (&argc, &argv);
1267   set_program_name (argv[0]);
1268   setlocale (LC_ALL, "");
1269   bindtextdomain (PACKAGE, LOCALEDIR);
1270   textdomain (PACKAGE);
1271 
1272   initialize_exit_failure (LS_FAILURE);
1273   atexit (close_stdout);
1274 
1275   assert (ARRAY_CARDINALITY (color_indicator) + 1
1276           == ARRAY_CARDINALITY (indicator_name));
1277 
1278   exit_status = EXIT_SUCCESS;
1279   print_dir_name = true;
1280   pending_dirs = NULL; 
1281                  
1282   current_time.tv_sec = TYPE_MINIMUM (time_t);
1283   current_time.tv_nsec = -1;

C言語のプログラムは main () 関数から始まります。ls コマンドの場合は、coreutils-8.4/src/ls.c の 1230行目が該当します。


1230 main (int argc, char **argv)

続いて変数の宣言がありますが個々の説明は省きます。
1237行目以降の以下の部分は少し説明しておきます。


1236   /* The signals that are trapped, and the number of such signals.  */
1237   static int const sig[] =
1238     {
1239       /* This one is handled specially.  */
1240       SIGTSTP,
1241 
1242       /* The usual suspects.  */
1243       SIGALRM, SIGHUP, SIGINT, SIGPIPE, SIGQUIT, SIGTERM,

SIGTSTP は Ctrl+Z を押した時のシグナルで、いわゆるサスペンドに相当します。

他にユーザキー操作で発生するシグナルとしては、SIGINT (Ctrl+C)、SIGQUIT (Ctrl+\) などがあります。
キーの割当はsttyコマンドで確認できます。

また、kill コマンドを -s オプションなしで実行すると SIGTERM が送れますし、-s を使用すれば他のシグナルも送れます。詳しくは man 1 kill や man 7 signal などを確認してください。

続いて、1266行目は、なにやら意味有りげな名前が付いていますが、


1266   initialize_main (&argc, &argv);

以下のように宣言されており、実体がありません(つまり何もしません)。

coreutils-8.4/src/system.h:


205 #ifndef initialize_main
206 # define initialize_main(ac, av)
207 #endif

次の行 1267行目は "ls" という文字列を program_name 変数に代入する処理です。

coreutils-8.4/src/ls.c:


1267   set_program_name (argv[0]);

※argv[0] とは、コマンドラインでのコマンド名部分を指します。

1268行目は、初期化の際のおまじないみたいなものです。man 3 setlocale 参照


1268   setlocale (LC_ALL, "");

次の２行 1269～1270行目のうち、bindtextdomain () は、メッセージファイルの読み先を"/usr/share/locale/*/*/coreutils.mo" に設定し、textdomain () は、gettext() 関連ライブラリ (ls コマンドにおいては dcgettext() )を呼んだ際のデフォルトドメイン ("coreutil" という文字列) を設定します。
詳細は man 3 bindtextdomain(※)、man 3 textdomain(※)、man 3 gettext を参照。
※：gettext-devel パッケージのインストールが必要

coreutils-8.4/src/ls.c:


1269   bindtextdomain (PACKAGE, LOCALEDIR);
1270   textdomain (PACKAGE);

coreutils-8.4/lib/config.h:


2043 #define PACKAGE "coreutils"

kernel-2.6.32-131.0.15.el6/scripts/kconfig/lkc.h:


 35 #define LOCALEDIR "/usr/share/locale"

次の 1272行目 initialize_exit_failure() は、関数の中に入ってみましょう。

coreutils-8.4/src/ls.c:


1272   initialize_exit_failure (LS_FAILURE);
  :
 102 /* Set exit_failure to STATUS if that's not the default already.  */
 103 static inline void
 104 initialize_exit_failure (int status)
 105 {  
 106   if (status != EXIT_FAILURE)
 107     exit_failure = status;
 108 }          

[LS_FAILURE 定義箇所]
 780     LS_FAILURE = 2

exit_failure 変数に 2 を代入していますね。
これは次に説明する close_stdout() の処理が失敗した時のための exit コードを設定しています。


1273   atexit (close_stdout);

atexit() は、exit() が呼ばれた時や main () 関数が終了する時に、実行する関数 (close_stdout) を登録するものです。詳細は man 3 atexit を参照。

ここで、先に close_stdout() を見ておきます。

coreutils-8.4/lib/closeout.c:


106 void
107 close_stdout (void)
108 {      
109   if (close_stream (stdout) != 0
110       && !(ignore_EPIPE && errno == EPIPE))
111     {
112       char const *write_error = _("write error");
113       if (file_name)
114         error (0, errno, "%s: %s", quotearg_colon (file_name),
115                write_error);
116       else   
117         error (0, errno, "%s", write_error);
118 
119       _exit (exit_failure);
120     }        
121 
122    if (close_stream (stderr) != 0)
123      _exit (exit_failure);
124 }

109行目で標準出力 (stdout) を、122行目で標準エラー出力 (stderr) をそれぞれ close_stream (中でfclose(3)が呼ばれる) していて、エラーの場合は exit_failure の値で exit しています。
つまり、ls コマンドの終了ステータスが 2 だった時、(この close_stdout() では) stdout を close する際は error () で出力されるメッセージを伴って終了しますので、エラー箇所の特定ができます。

では、main () に戻って、続きの処理を見ていきます。

1275～1276行目は、color_indicator 配列と indicator_name 配列の要素数を計算してしています。計算値が一致しないと assert () 内で exit が呼ばれ終了します。詳細は man 3 assert 参照

coreutils-8.4/src/ls.c:


1275   assert (ARRAY_CARDINALITY (color_indicator) + 1
1276           == ARRAY_CARDINALITY (indicator_name));
  :
 565 static const char *const indicator_name[]=
 566   {
 567     "lc", "rc", "ec", "rs", "no", "fi", "di", "ln", "pi", "so",
 568     "bd", "cd", "mi", "or", "ex", "do", "su", "sg", "st",
 569     "ow", "tw", "ca", "mh", "cl", NULL
 570   };
  :
 579 static struct bin_str color_indicator[] =
 580   {
 581     { LEN_STR_PAIR ("\033[") },         /* lc: Left of color sequence */
 582     { LEN_STR_PAIR ("m") },             /* rc: Right of color sequence */
 583     { 0, NULL },                        /* ec: End color (replaces lc+no+rc) */
 584     { LEN_STR_PAIR ("0") },             /* rs: Reset to ordinary colors */
 585     { 0, NULL },                        /* no: Normal */
 586     { 0, NULL },                        /* fi: File: default */
 587     { LEN_STR_PAIR ("01;34") },         /* di: Directory: bright blue */
 588     { LEN_STR_PAIR ("01;36") },         /* ln: Symlink: bright cyan */
 589     { LEN_STR_PAIR ("33") },            /* pi: Pipe: yellow/brown */
 590     { LEN_STR_PAIR ("01;35") },         /* so: Socket: bright magenta */
 591     { LEN_STR_PAIR ("01;33") },         /* bd: Block device: bright yellow */
 592     { LEN_STR_PAIR ("01;33") },         /* cd: Char device: bright yellow */
 593     { 0, NULL },                        /* mi: Missing file: undefined */
 594     { 0, NULL },                        /* or: Orphaned symlink: undefined */
 595     { LEN_STR_PAIR ("01;32") },         /* ex: Executable: bright green */
 596     { LEN_STR_PAIR ("01;35") },         /* do: Door: bright magenta */
 597     { LEN_STR_PAIR ("37;41") },         /* su: setuid: white on red */
 598     { LEN_STR_PAIR ("30;43") },         /* sg: setgid: black on yellow */
 599     { LEN_STR_PAIR ("37;44") },         /* st: sticky: black on blue */
 600     { LEN_STR_PAIR ("34;42") },         /* ow: other-writable: blue on green */
 601     { LEN_STR_PAIR ("30;42") },         /* tw: ow w/ sticky: black on green */
 602     { LEN_STR_PAIR ("30;41") },         /* ca: black on red */
 603     { 0, NULL },                        /* mh: disabled by default */
 604     { LEN_STR_PAIR ("\033[K") },        /* cl: clear to end of line */
 605   };

coreutils-8.4/lib/argmatch.h:


 29 # define ARRAY_CARDINALITY(Array) (sizeof (Array) / sizeof *(Array))

1278～1283行目は変数の初期化です。

coreutils-8.4/src/ls.c:


1278   exit_status = EXIT_SUCCESS;
1279   print_dir_name = true;
1280   pending_dirs = NULL;
1281 
1282   current_time.tv_sec = TYPE_MINIMUM (time_t);
1283   current_time.tv_nsec = -1;

以上、初期化が終わるまでを見てきました。
次回は、オプション解析関数 decode_switches () から進めていきたいと思います。

coreutils-8.4/src/ls.c:


1285   i = decode_switches (argc, argv);

(続く)

Google Appsを導入しよう (BIND9設定編)

2012-02-17T20:14:00.000+09:00

こんばんは。サイオステクノロジーの小川です。

最近、無償版の「Google Apps Standard Edition」で利用できる機能が増えてきて、便利に感じています。たとえば、シングルサインオンの機能は、以前まで有償版の「Google Apps for Business」でしか提供されていなかったのですが、現在は Standard Edition でも利用ができます。

Standard Edition は 10アカウントまで作成ができますので、色々な用途で使い分けることができます。Googleサイトでサークルのホームページを作ったり、チームの連絡用にGmailを使ってみるのも良いかもしれないですね。

今回はGoogle Appsの導入でBIND9の設定について紹介します。また、併せてマスターサーバとスレーブサーバの構築の手順についても簡単に説明します。OSはCentOS5 系を使用しています。

< Google Apps の導入に必要なもの >

ドメイン

Google Appsは最低 1つのドメインが必要

DNSサーバ

インターネット上にDNSサーバを公開するので、ポート53番は解放

取得したドメインのDNSサーバは自前のDNSサーバに設定を変更

まだCentOSにBINDをインストールされていない方は、以下の手順でインストールします。

# yum install bind bind-chroot 
# yum install caching-nameserver

なお、CentOS6 系では caching-nameserver は bind に統合された為、インストールする必要はありません。インストールしようとすると、以下のようなメッセージが表示されます。

# yum install caching-nameserver
Package 32:bind-9.7.3-8.P3.el6_2.2.i686 already installed and latest version

1. マスターサーバの構築手順

1-1. BIND の設定ファイル named.conf を編集。

# vim /etc/named.conf

< 追記項目の例 >

view "external" {
   allow-query { any; };
   recursion no;
   include "/etc/example.com.zone";
};

view

view の名称は特に決まりはありません。インターネットに公開している、外向けといった意味で「external」としています。

allow-query

すべての問い合わせに対して応答するよう any としています。Google Apps の導入の際に Google がDNSレコードを参照したり、メールのやり取りで不特定のユーザーが参照したりするので、必要な設定です。

recursion

DNSサーバへの問い合わせの応答は、このサーバが持っている情報だけ返せばいいので no にしてください。

include

named.conf の内容を別のファイルに分けて記述することができます。後述の example.com.zone のファイルを参照してください。

※ CentOS5系で caching-nameserver をインストールしている場合は、named.caching-nameserver.conf を利用して named.conf を作成することもできます。


# cd /var/named/chroot/etc/
# cp named.caching-nameserver.conf named.conf
# chown root:named named.conf
# ln -s /var/named/chroot/etc/named.conf /etc/named.ccnf

1-2. zone を記述するファイルを作成。


# vim example.com.zone

< 記述内容の例 >


zone "example.com" IN {
     type master;
     allow-update { none; };
     allow-transfer { xxx.xxx.xxx.91; };
     file "example.com.db";
};

zone

example.com ゾーンの設定を記述します。Google Apps で今後新しくサブドメイン oss.example.com を追加するような場合は、example.comゾーンの管理下に置かれます。

type

マスターサーバは master としてください。

allow-update

セキュリティの観点から、クライアントがDNSレコードを更新できないよう明示的に none としています。

allow-transfer

マスターサーバからスレーブサーバへ example.com ゾーンの情報を転送する為に、スレーブの IP アドレスを設定します。

file

ゾーンデータファイルの場所を指定します。ファイルの内容は後述の example.com.db を参照ください。

1-3. example.com.zone の所有者を named に変更。

# chown root:named example.zone

1-4. named.conf の内容に間違いがないかチェック。

# named-checkconf

1-5. 正引き用ゾーンデータファイルを作成。

# vim example.com.db

< 記述内容の例 >


$TTL 86400
@                          IN  SOA    ns1 root (
                           2012021307 ; Serial
                           10800      ; Refresh   
                           3600       ; Retry     
                           604800     ; Expire   
                           86400 )    ; Minimum

                           IN NS      ns1
                           IN NS      ns2
                           N A         xxx.xxx.xxx.145
                           IN MX      1 aspmx.l.google.com.
                           IN MX      5 alt1.aspmx.l.google.com.
                           IN MX      5 alt2.aspmx.l.google.com.
                           IN MX      10 aspmx2.googlemail.com.
                           IN MX      10 aspmx3.googlemail.com.
                           IN MX      10 aspmx4.googlemail.com.
                           IN MX      10 aspmx5.googlemail.com.

ns1                        IN A       xxx.xxx.xxx.147
ns2                        IN A       xxx.xxx.xxx.91

ゾーンデータファイルの書き方は好みが分かれるかと思いますが、私の場合、@ を使用しています。@ を利用することで、example.com.zone の zone で指定したドメイン名(example.com)を補完してくれます。

example.com のネームサーバとしてマスター(ns1.example.com)、スレーブ(ns2.example.com)を指定しています。ns1 の Aレコードにはマスターサーバの IP アドレス、ns2 の Aレコードにはスレーブサーバの IP アドレスを登録しています。

「2012021307」はシリアル番号です。2012年2月13日に7回更新しました、という意味となります。更新した年月日と回数を記述してください。ゾーンデータファイルを更新する際はシリアル番号の更新は忘れないように注意してください。

Gmail では Google Apps のメールサーバを利用してメールの送受信を行うので、example.com の MX レコードには Google Apps のメールサーバを登録してください。

注意！ Gmail の有効化が完了するまで、現在使用中のメールサーバのMX レコードは削除しないでください。メールの配送が止まってしまいます。

1-6. example.com.db の所有者を named に変更。


# chown root:named example.com.db

1-7. ゾーンデータファイルの構文に間違いがないかチェック。


# named-checkzone example.com example.com.db
zone example.com/IN: loaded serial 2012021307
OK

1-8. サービスを起動。


# service named start

1-9. example.com の MX レコードを確認。


# dig @8.8.8.8 example.com mx

[応答結果]


exmple.com.  86400 IN MX 10 aspmx2.googlemail.com.
exmple.com.  86400 IN MX 10 aspmx3.googlemail.com.
exmple.com.  86400 IN MX 10 aspmx4.googlemail.com.
exmple.com.  86400 IN MX 10 aspmx5.googlemail.com.
exmple.com.  86400 IN MX 1 aspmx.l.google.com.
exmple.com.  86400 IN MX 5 alt1.aspmx.l.google.com.
exmple.com.  86400 IN MX 5 alt2.aspmx.l.google.com.

2. スレーブサーバの構築手順

2-1. named.conf を編集。

# vim /etc/named.conf

< 追記項目の例 >


view "external" {
   allow-query { any; };
   recursion no;
   include "/etc/example.com.slave.zone";
};

2-2. zone を記述するファイルを作成。


# vim example.com.slave.zone

< 記述内容の例 >


zone "example.com" IN {
        type slave;
        masters { xxx.xxx.xxx.147; };
        file "slaves/example.com.slave.db";
};

type

スレーブサーバは slave としてください。

masters

マスターサーバの IP アドレスを指定してください。

file

マスターサーバから転送されるゾーンデータファイルの保存場所を slaves ディレクトリに指定して、ファイル名を決めます。

2-3. named.conf の内容に間違いがないかチェック。

# named-checkconf

2-4. サービスを起動。

# service named start

2-5. slaves ディレクトリにゾーンデータファイルが作成される。


# cat /slaves/example.com.slave.db

マスターサーバのゾーンデータファイルと同様の内容であることがわかります。


$ORIGIN .
$TTL 86400 ; 1 day
example.com  IN SOA ns1.example.com. root.example.com. (
                          2012021307 ; serial
                          10800      ; refresh (3 hours)
                          3600       ; retry (1 hour)
                          604800     ; expire (1 week)
                          86400      ; minimum (1 day)
                          )
                          NS ns1.example.com.
                          NS ns2.example.com.
                          A xxx.xxx.xxx.145
                          MX 1 aspmx.l.google.com.
                          MX 5 alt1.aspmx.l.google.com.
                          MX 5 alt2.aspmx.l.google.com.
                          MX 10 aspmx2.googlemail.com.
                          MX 10 aspmx3.googlemail.com.
                          MX 10 aspmx4.googlemail.com.
                          MX 10 aspmx5.googlemail.com.
$ORIGIN example.com.
ns1   A xxx.xxx.xxx.147
ns2   A xxx.xxx.xxx.91

以上で DNS サーバの構築は完了です。

※ 今回は Google Apps の導入が目的の為、逆引き設定の話は割愛させていただきます。

次は、Google Apps の申込み〜サービスの有効化の話に進みたいと思います。

3. Google Apps のサービス有効化までの手順

3-1. Google Apps の製品ページにアクセス。

「開始する」のボタンをクリックしてください。

http://www.google.com/apps/intl/ja/group/index.html

3-2. Google Apps に登録するドメイン名を入力。

「次へ進む」をクリックしてください。

3-3. アカウント管理者の情報と組織の情報を入力。

「次へ進む」のボタンをクリックしてください。

3-4.管理者アカウントの名前とパスワードを入力。

「文字の確認」に表示されている文字を入力してください。

利用規約を確認しましたら、「同意して、設定を続行 >>」ボタンをクリックしてください。

3-5.Google Apps の管理者コントロールパネルにログイン。

URLは「https://www.google.com/a/example.com」となります。

「example.com」はGoogle Apps に登録したドメイン名になります。

3-6.「Google Apps を有効にする」のボタンをクリック。

3-7.「所有権の確認」で「別の方法」をクリック。

3-8.「DNS レコードをドメインの設定に追加」を選択。

「ドメインレジストラまたはプロバイダを選択」から「その他」を選択してください。

3-9.「google-site-verification=文字列」の文字列をTXTレコードに登録。

example.comのDNSサーバに登録してください。

< 記述内容の例 >


$TTL 86400
@                          IN  SOA    ns1 root (
                           2012021601 ; Serial
                           10800      ; Refresh   
                           3600       ; Retry     
                           604800     ; Expire   
                           86400 )    ; Minimum

                           IN NS      ns1
                           IN NS      ns2

                           IN A       xxx.xxx.xxx.145
                           IN MX      1 aspmx.l.google.com.
                           IN MX      5 alt1.aspmx.l.google.com.
                           IN MX      5 alt2.aspmx.l.google.com.
                           IN MX      10 aspmx2.googlemail.com.
                           IN MX      10 aspmx3.googlemail.com.
                           IN MX      10 aspmx4.googlemail.com.
                           IN MX      10 aspmx5.googlemail.com.
                           IN TXT    "google-site-verification=xxxxxxxxxxxxxxxxxxxxxx"

ns1                        IN A       xxx.xxx.xxx.147
ns2                        IN A       xxx.xxx.xxx.91

TXT レコードの記述は "google-site-verification=xxxxxxxxxxxxxxxxxxxxxx" のようにダブルクォーテーションで括っています。

注意！シリアル番号の更新は忘れないようにしてください。

3-10.サービスを再起動。

# service named restart

3-11.TXT レコードが反映されているかどうか確認。

# dig @8.8.8.8 example.com txt

< 実行結果を抜粋 >

;; ANSWER SECTION:
example.com.  86399 IN TXT "google-site-verification=xxxxxxxxxxxxxxxxxxxxxx"

3-12.「所有権の確認」の画面で「確認」ボタンをクリック。

3-13.「example.com の所有権が確認されました。」と表示される。

「続行」のリンクをクリックしてください。

3-14.「ダッシュボード」の画面に戻るので、「設定」をクリック。

3-15.「メール」の「MXレコード」の項目で「MX 設定の手順」のリンクをクリック。

3-16.「メール配信の方法」は「Google サーバー」を選択し、「次へ >>」をクリック。

3-17.「MXレコードを更新しています...」と表示される。

有効化まで最大で48時間かかる場合があります。しばらくお待ちください。

3-18.「受信トレイ」のリンクをクリックし、Gmail のサービスにアクセス。

3-19.「作成」ボタンからメールを作成し、メールの送信ができるどうか確認をしてください。

以上で Google Apps の導入は完了です。お疲れさまでした！

Standard Edition をご利用いただき、Google Apps for Business の導入をご検討される場合は是非 SIOS にご相談ください！お客様に最適なソリューションのご提案やサポートをさせていただきます。

Google Apps の基本サポート/追加ソリューション/移行・サポート

http://www.sios.com/products/cloud/service/index.html

ここまでお付き合いくださった皆様、どうもありがとうございました。

パッケージ更新した後、古いパッケージをロードしたままになっているプロセスを見つける。

2012-02-16T17:49:00.000+09:00

こんにちは、OSSテクノロジーセンターの原です。

今回は yum update した後、古いパッケージをロードしたままになっているプロセスを見つけてくれる便利な yum plugin を紹介しようと思います。

パッケージ名は yum-plugin-ps です。

RHEL 6.x から利用可能で、RHEL Server Optional チャンネルにあります。

インストール：


# yum install -y yum-plugin-ps

使い方としては、何かをインストール、アップデートした後に実行します。

その前に、一旦 yum ps コマンドを使って、現在の状況を確認したいと思います。


# yum ps
Loaded plugins: product-id, ps, security, subscription-manager
Updating certificate-based repositories.
       pid proc                  CPU      RSS      State uptime
ps
#

特になにもないようです。では一例として apr パッケージをアップデートしてみます。


# yum update -y apr apr-util
Loaded plugins: product-id, ps, security, subscription-manager
Updating certificate-based repositories.
Setting up Update Process
Resolving Dependencies
--> Running transaction check
---> Package apr.x86_64 0:1.3.9-3.el6 will be updated
---> Package apr.x86_64 0:1.3.9-3.el6_1.2 will be an update
---> Package apr-util.x86_64 0:1.3.9-3.el6 will be updated
--> Processing Dependency: apr-util = 1.3.9-3.el6 for package: apr-util-ldap-1.3.9-3.el6.x86_64
---> Package apr-util.x86_64 0:1.3.9-3.el6_0.1 will be an update
--> Running transaction check
---> Package apr-util-ldap.x86_64 0:1.3.9-3.el6 will be updated
---> Package apr-util-ldap.x86_64 0:1.3.9-3.el6_0.1 will be an update
--> Finished Dependency Resolution

Dependencies Resolved

======================================================================
 Package               Arch     Version            Repository     Size
======================================================================
Updating:
 apr            x86_64   1.3.9-3.el6_1.2   rhel-x86_64-server-6  123 k
 apr-util       x86_64   1.3.9-3.el6_0.1   rhel-x86_64-server-6   87 k
Updating for dependencies:
 apr-util-ldap  x86_64   1.3.9-3.el6_0.1   rhel-x86_64-server-6   15 k

Transaction Summary
======================================================================
Upgrade       3 Package(s)

Total download size: 226 k
Downloading Packages:
----------------------------------------------------------------------
Total                                       25 MB/s | 226 kB     00:00
Running rpm_check_debug
Running Transaction Test
Transaction Test Succeeded
Running Transaction
  Updating   : apr-1.3.9-3.el6_1.2.x86_64                          1/6
  Updating   : apr-util-1.3.9-3.el6_0.1.x86_64                     2/6
  Updating   : apr-util-ldap-1.3.9-3.el6_0.1.x86_64                3/6
  Cleanup    : apr-util-ldap-1.3.9-3.el6.x86_64                    4/6
  Cleanup    : apr-util-1.3.9-3.el6.x86_64                         5/6
  Cleanup    : apr-1.3.9-3.el6.x86_64                              6/6
Installed products updated.

Updated:
  apr.x86_64 0:1.3.9-3.el6_1.2       apr-util.x86_64 0:1.3.9-3.el6_0.1

Dependency Updated:
  apr-util-ldap.x86_64 0:1.3.9-3.el6_0.1

Complete!
#

アップデートできたら、早速 yum ps コマンドで確認してみます。


# yum ps
Loaded plugins: product-id, ps, security, subscription-manager
Updating certificate-based repositories.
       pid proc                  CPU      RSS      State uptime
apr-1.3.9-3.el6_1.2.x86_64
     14216 httpd                0:00   3.8 MB   Sleeping: *07:01
     14218 httpd                0:00   2.4 MB   Sleeping: *07:01
     14219 httpd                0:00   2.4 MB   Sleeping: *07:01
     14220 httpd                0:00   2.4 MB   Sleeping: *07:01
     14221 httpd                0:00   2.4 MB   Sleeping: *07:01
     14222 httpd                0:00   2.4 MB   Sleeping: *07:01
     14223 httpd                0:00   2.4 MB   Sleeping: *07:01
     14224 httpd                0:00   2.4 MB   Sleeping: *07:01
     14225 httpd                0:00   2.4 MB   Sleeping: *07:01
apr-util-1.3.9-3.el6_0.1.x86_64
     14216 httpd                0:00   3.8 MB   Sleeping: *07:01
     14218 httpd                0:00   2.4 MB   Sleeping: *07:01
     14219 httpd                0:00   2.4 MB   Sleeping: *07:01
     14220 httpd                0:00   2.4 MB   Sleeping: *07:01
     14221 httpd                0:00   2.4 MB   Sleeping: *07:01
     14222 httpd                0:00   2.4 MB   Sleeping: *07:01
     14223 httpd                0:00   2.4 MB   Sleeping: *07:01
     14224 httpd                0:00   2.4 MB   Sleeping: *07:01
     14225 httpd                0:00   2.4 MB   Sleeping: *07:01
apr-util-ldap-1.3.9-3.el6_0.1.x86_64
     14216 httpd                0:00   3.8 MB   Sleeping: *07:01
     14218 httpd                0:00   2.4 MB   Sleeping: *07:01
     14219 httpd                0:00   2.4 MB   Sleeping: *07:01
     14220 httpd                0:00   2.4 MB   Sleeping: *07:01
     14221 httpd                0:00   2.4 MB   Sleeping: *07:01
     14222 httpd                0:00   2.4 MB   Sleeping: *07:01
     14223 httpd                0:00   2.4 MB   Sleeping: *07:01
     14224 httpd                0:00   2.4 MB   Sleeping: *07:01
     14225 httpd                0:00   2.4 MB   Sleeping: *07:01
ps
#

どうやら httpd が古い apr のパッケージをロードしたままになっているようですので、再起動しましょう。


# /etc/init.d/httpd restart
httpd を停止中:                                            [  OK  ]
httpd を起動中:                                            [  OK  ]
#

新しい apr を読みなおすことができたでしょうか。再度 yum ps を確認します。


# yum ps
Loaded plugins: product-id, ps, security, subscription-manager
Updating certificate-based repositories.
       pid proc                  CPU      RSS      State uptime
ps
#

めでたく古い apr のパッケージをロードしたままになっているプロセスはなくなったようです。

ちなみに SLES 11 でも同じような機能をもつ zypper ps というコマンド存在します。(むしろ zypper ps の方が実装されたのが早かったハズです)

利用方法は yum ps と同じですが、zypper の方は特別にプラグインを導入する必要はありません。


# zypper ps
No processes using deleted files found.
#

今回確認に利用した apr は yum ps (zypper ps) を利用しなくても、 Apache Portable Runtime (APR) の名前から、Apache の再起動が必要そうなイメージが付きますが、パッと見どのプロセスが関連しているのかわからないパッケージも時々あるかと思います。

そんな時は是非この yum ps (zypper ps) を利用してみてください。

ではでは。

連載「ZFS on Linux」第1回～ZFS on Linux のインストール～

2012-02-16T12:00:00.000+09:00

サイオステクノロジー鎌田です。お久しぶりです。

当ブログの連載記事としては、既に2名の方が libvirt と OS コマンドの解説で執筆されていますが、私は個人的に興味のある ZFS を Linux で使える ZFS on Linux に照準を当てたいと思います。

ZFS on Linux に関しては既に様々な情報がありますが、なぜあえて今やりたいのかと申しますと、私個人としては FreeBSD が好きであることと、FreeBSD が ZFS をネイティブ実装していて興味があることと、ZFS って名前だけよく聞くけど結局よくわかっていない、という理由でせっかくなので連載記事として追っていこうと思い立ったことが始まりです。

そういうわけでして、あまり詳しい情報を記載できるという保証ができないのですが、検証記録的なノリでぜひご覧いただければと思っています。それでは、第1回目として ZFS on Linux のインストールから始めたいと思います。

環境

今回の連載で使用する検証用の環境は次の通りです。

CentOS 6.2 (x86_64) : 最小インストール
ZFS on Linux 0.6.0-rc6

インストール手順

次に、インストール手順です。

ZFS on Linux のサイトから、以下の2つのファイルをダウンロードします。
- spl-0.6.0-rc6.tar.gz
- zfs-0.6.0-rc6.tar.gz
上記2つをコンパイルし、RPM 化するために必要なパッケージをインストールします。yum コマンドを使ってさくっと入れちゃいましょう。
```
# yum groupinstall "Development Tools"
# yum install zlib-devel libuuid-devel libblkid-devel libselinux-devel parted lsscsi
```
まずは SPL をコンパイルし、インストールします。"make rpm" の部分は結構時間かかります。
```
# tar xzvf spl-0.6.0-rc6.tar.gz
# cd spl-0.6.0-rc6.tar.gz
# ./configure
# make rpm
# rpm -Uvh *.x86_64.rpm
```
そして ZFS をコンパイルし、インストールします。ここも、"make rpm" の部分に結構時間かかります。
```
# tar xzvf zfs-0.6.0-rc6.tar.gz
# cd zfs-0.6.0-rc6
# ./configure
# make rpm
# rpm -Uvh *.x86_64.rpm
```
一旦 OS を再起動し、以下のコマンドを実行すると、ファイルシステムとして ZFS が利用可能になっていることがわかります。
```
# cat /proc/filesystems
 :
nodev   zfs
```

というわけで、ZFS が利用できる状況になりました。次回は ZFS 領域を作っていろいろさわってみます。

OpenShift で MTOS セットアップ

2012-02-15T17:02:00.000+09:00

お世話になっております。
OSSTC 佐藤です。

今日は Red Hat 社の PaaS で絶賛売り出し中の OpenShift を触ります。

Red Hat - OpenShift: https://openshift.redhat.com

OpenShift は以下の様な言語やフレームワークをサポートしています。
Databases も豊富です。ちなみに無料利用が可能な EXPRESS で割り当てられるディスクサイズはデフォルトで 512 MB です。

Languages and Frameworks: https://openshift.redhat.com/app/features

さて、まずは使ってみましょう。

"Sign up for OpenShift" で登録を行います。
"Promotional Code" は空欄で問題ありません。

登録後確認メールが飛んできますので、メール内容を確認の上記載されている確認用 URL へアクセスする事で準備は完了です。

ログインするとローカル環境のセットアップを行う為に説明があります。
いきなり動画を見てしまった私はどうやってコピペすんじゃ！とも思いましたが、それはただの短気っぷりを発揮したにすぎません。

ログイン後に左のメニューから Quickstart を確認してもらえば手詰まりはしないです。
"1. Install the client tools" に簡潔に書いてあります。

Red Hat 系はレポジトリを追加して yum にて簡単にセットアップが行えます。
Other Linux 環境では以下の手順で進めました。
# 諸処お察し下さい。


　$ su -c "zypper install git ruby rubygems"
　$ su -c "gem install rhc"

"Express Console" にてブラウザでも環境構築できますが CUI で進めてみます。

以下のコマンドは読み替えてください。

mydomain はユニークなものである必要があります。
rhlogin は申請時のメールアドレスです。
appname は git で管理するアプリケーション名です。

今回はフレームワークで何かしたりというのは後回しで、まずはアプリケーションを作成する(動かしてみる)事が目的なので MTOS でいきます。


　$ rhc-create-domain -n mydomain -l rhlogin
　$ rhc-create-app -a appname -t perl-5.10

TYPE 指定を perl にしたのでローカルに appanme/perl が生成されます。そこが DocumentRoot になるみたいです。


　$ cd appname/perl

MTOS をダウンロードして DocumentRoot に展開します。


　$ unzip ~/Download/MTOS-5.12-ja.zip
　$ cd MTOS-5.12-ja/
　$ mv * ..
　$ cd ../
　$ rm -rf MTOS-5.12-ja/

最後に htaccess で典型的な設定を施します。


　$ vi .htaccess

[ mt/perl/.htaccess ]
--------------------------------
<Files ~ "^\.(htaccess|htpasswd)&">
deny from all
</Files>
Options -Indexes
DirectoryIndex index.html index.pl      
order deny,allow
--------------------------------

一通りファイルは揃ったので push します。


　$ git add -A
　$ git commit -a -m 'MTOS upload'
　$ git push

push すると環境構築が開始されたりしますので待ちます。はい、待ちます。

無事完了したら http://appname-mydomain.rhcloud.com/mt.cgi にアクセスすると見慣れた設定ページが表示されます。

DB を SQLite に選択して、パスは "../../data/任意のデータベースファイル名" にて進めばそのままいけます。SMTP は sendmail 利用で進んでいけば OK。

まぁ便利な世の中になりました。

[参考] OPENSHIFT EXPRESS EVALUATION GUIDE - Redhat: https://www.redhat.com/openshift/community/sites/default/files/documents/RHOS_Express_Eval_Guide.pdf

Red Hat Enterprise Linux スタンダードサポート提供時間変更のお知らせ

2012-02-14T12:00:00.000+09:00

おはようございます。
本日はバレンタインデーですね。今年はなぜか芋焼酎を2本もらった村田です。

さて、今回の記事も前回の稲垣に続いて、Red Hat のサポートに関するお話です。

これまで、平日9時～21時のサポート（通称9時9時サポート）を提供していた Red Hat Enterprise Linux (以下:RHEL) スタンダードサポートが、2012年4月1日受注分以降、順次9時～17時へ変更されます。

夕方にトラブルが発生してサポート時間に間に合うようにと、17時前にバタバタすることはよくあることかと思いますが、RHEL スタンダードサポートは21時まで受付して頂けることで助けられていた方も少なくないのではないでしょうか。

少しでも長く21時までのサポートを受けたいという方は、 2012年3月23日（金）までに発注を頂くことで、切り替わる時期を後ろに延ばすことができるようです。夕方以降に RHEL スタンダードサポートをご利用された事がある方は、この機会にぜひ駆け込み発注をご検討ください。

注） 2014年4月1日以降は全ての契約が9時～17時サポートになります。

詳しくは以下の SIOS Web にて解説がありますのでご確認ください。
Red Hat Enterprise Linux スタンダードサポート提供時間変更のお知らせ

RHEL5,6 のサポート期間変更のお知らせ

2012-02-10T19:11:00.000+09:00

お久しぶりです、サイオステクノロジーの稲垣です。

今回は、RHEL のサポート期間延長に関するお話です。

今までの RHEL のサポート期間は、標準で 7 年でしたが、RHEL5、RHEL6 では標準で 10 年と、従来よりも 3 年長いサポート期間が提供されることになりました。

RHEL5、RHEL6 のサポート終了期間は、以下の様に公表されています。
ライフサイクルの詳細が載っている URL もあるので、併せて確認してみてください。

Red Hat Enterprise Linux 5
2017 年 3 月 31 日
Red Hat Enterprise Linux 6
2020 年 11 月 30 日

Red Hat Enterprise Linux Life Cycle

補足：
2012/2/10 現在、RHEL5、RHEL6 では、RHEL3、RHEL4 の Extended Lifecycle Support (ELS) に相当するサポートは提供されていません。そのため当初の記述から変更しております。
RHEL5、RHEL6 の Life Cycle に記載されている Extended Life Phase (ELP) については、テクニカルサポートは受けられないものの、サブスクリプションをお持ちであればカスタマーポータル上で、パッケージ、ISO イメージ、ドキュメント、ナレッジにアクセスが可能とのことです。

閏年 ~RHEL への影響は？~

2012-02-08T12:00:00.000+09:00

お久しぶりです、サイオステクノロジーの稲垣です。

今年は待ちに待った閏年です！…ということで、今回は閏年についての記事です。

1 年が例年より 1 日多いことで、使用しているシステムに影響があるかもしれないと考える方も多いのではないでしょうか。

Red Hat Enterprise Linux に含まれるすべてのアプリケーションは、閏年の処理を考慮して設計されているため、RHEL は閏年の影響を受けたという報告は今のところありません。

念のため Red Hat の Bugzilla を確認してみましたが、閏年に関する登録はありませんでした。
※仮に閏年に関する問題があったとしたら、既に大騒ぎになっているはずなので、今の時点で何もアナウンスが無いということは…という考え方もできます。

以上、閏年についての情報でした。

連載「libvirt を利用して日々の作業を効率化」第１回

2012-02-07T17:00:00.000+09:00

こんにちは。1月からサイオスに Join した原です。

libvirt は Red Hat 社が中心に開発する、仮想化管理用の標準 API です。

サポートされているプロダクトであれば、全て同じように扱えるのが魅力です。

まずはおさらいとして、どんなものに対応しているか見てみます。

libvirt: Internal drivers に一覧が出ています。


The KVM/QEMU Linux hypervisor
The Xen hypervisor on Linux and Solaris hosts.
The LXC Linux container system
The OpenVZ Linux container system
The User Mode Linux paravirtualized kernel
The VirtualBox hypervisor
The VMware ESX and GSX hypervisors
The VMware Workstation and Player hypervisors
The Microsoft Hyper-V hypervisor
Virtual networks using bridging, NAT, VEPA and VN-LINK.
Storage on IDE/SCSI/USB disks, FibreChannel, LVM, iSCSI, NFS and filesystems

Xen や KVM を触っている(いた)方なら、libvirt の CLI ツールである virsh コマンドや、GUI ツールの virt-manager を利用したことがある方が多いのではないでしょうか。

単に virsh コマンドを利用するのも複数の Hypervisor に対応しているだけあって便利なのですが、API にアクセスする、"ちょっとしたツール"を作り、日々の作業を自動化することで、より libvirt の醍醐味を味わうことが出来ます。

"ちょっとしたツール"を作るにあたって、どんな言語バインディングがあるのかは、libvirt: Bindings for other languages をご確認ください。

この連載では、libvirt を中心に、仮想化インフラストラクチャの自動化にスポットを当てて、日々の作業を効率化するためのヒントを紹介できればと思います。

例として libvirt API を利用して、Web 画面から仮想マシンを立ち上げるサイトを作成してみたいと思います。

今回のサーバの構成は下記のようになります。

ホスト名: kvmhost - ハイパーバイザ(KVM, libvirtd, Scientific Linux 6.1) 1台
ホスト名: webvirt - Webサーバ(Ruby, libvirt-client, Scientific Linux 6.1) 1台
仮想マシン数台

Webサーバの構成

Ruby
Sinatra(DSL)
WEBrick(httpサーバ)
ruby-libvirt(libvirtクライアント)

以下、ハイパーバイザ側を kvmhost、Webサーバ側を webvirt と呼びます。

また、明示的にユーザ名を指定しない場合は全て root での作業となります。

今回は Webサーバとして Ruby にビルドインされた werick を、libvirt-client の言語バインディングとしては Ruby を利用しますが、どのWebサーバ・言語でも基本的な設計はかわりません。

kvmhost側は、既に KVM 及び libvirtd が稼動しているものとして、webvirt側の構築をします。

まずは EPEL リポジトリを追加して、必要なパッケージを導入します。

補足になりますが、EPEL リポジトリは RHEL のアップストリームである、Fedora Project の有志によって運営されている RHEL 向けの高品質なアドオンパッケージリポジトリです。

また、CentOS や Scientific Linux (SL) のような RHEL からスピンオフしたディストリビューションとの互換性もあります。

# rpm -Uvh http://download.fedora.redhat.com/pub/epel/6/x86_64/epel-release-6-5.noarch.rpm
# yum install -y openssh-clients ruby rubygem-sinatra ruby-libvirt

次に、kvmhost と webvirt をどのように通信させるかを検討します。

libvirt の接続には ssh を始めいくつかの接続手段があります。

詳しくは libvirt: Remote support をご確認ください。

今回は最も簡単な ssh による接続を利用したいと思います。

webvirt側

# cd ~
# mkdir .ssh
# ssh-keygen
(質問は全てエンターで進んでしまって構いません)
# cd .ssh
# cat id_rsa.pub >> webvirt-id_rsa.pub
# scp ./webvirt-id_rsa.pub root@kvmhost/root/.ssh

kvmhost側

# cd .ssh/
# cat webvirt-id_rsa.pub >> authorized_keys

少しそれますが、例えば Ruby 組み込みの webrick ではなく、 Phusion Passenger(mod_rails for Apache)や、mod_perl、mod_php 等、他の言語で webサーバを Apache で動かしたい場合は下記の様に、Apacheユーザでノンパスワードログイン出来るようにしておきます。

# cd /var/www/
# mkdir .ssh
# chown apache.apache .ssh/
# sudo -u apache ssh-keygen
# cd .ssh
# cat id_rsa.pub >> webvirt-id_rsa.pub
# scp ./webvirt-id_rsa.pub root@kvmhost/root/.ssh

sudo で apache ユーザの ssh 鍵を作成するのがポイントです。

さて、話を戻して kvmhost側で ssh の受け入れが完了したら、webvirt からノンパスワードでログイン出来るか試してみましょう。

# ssh root@kvmhost

さて、ここまでで、libvirtd に接続できる環境が整いました。

Ruby で接続する前に virsh コマンドで接続できるか確認してみましょう。

# virsh -c qemu+ssh://kvmhost/system list --all
 Id Name                 State
----------------------------------
  - test1                shut off
  - test2                shut off

libvirt に登録されているゲストマシンの一覧が表示されればOKです。

できましたでしょうか？

できたら、今度は Ruby でゲストマシンの一覧を取得できるか試してみましょう。

get_vm_list.rb

#!/usr/bin/ruby
require 'libvirt'
conn = Libvirt::open("qemu+ssh://root@kvmhost/system")
vm_list = conn.list_defined_domains
puts vm_list

# chmod +x get_vm_list.rb
# ./get_vm_list.rb

Libvirt::open メソッドで接続し、list_defined_domains メソッドで非アクティブなゲストマシンの一覧を取得しています。

APIのドキュメントは下記に詳しく掲載されています。

Ruby bindings for libvirt

Ruby bindings for libvirt RDoc Documentation

いかがでしたしょうか。

次回はこの環境を使って、実際に Web画面から仮想マシンのパワーオン/オフが行えるようにしていきたいと思います。

ではでは。

連載「Linux コマンド動作徹底解析」"ls -l" 編第1回

2012-02-06T17:05:00.000+09:00

サイオステクノロジー金田です。

今日から「Linux コマンド動作徹底解析」と題した連載をスタートします。Linux でよく使われるコマンドを選んで、ソースコードを追いかけながらどのような動作をしているのかを見ていきます。途中に出てくるシステムコールや C言語のライブラリ関数も、man の情報だけではなく、必要に応じて kernel や glibc のソースコードを参照しながら説明できたらと思っています。

連載第1回は "ls -l" 編と題して、週1回、計4回の予定で連載していく予定です。

さて、RHEL/CentOS/Scientific Linux のバージョン 6 系がリリースされてから１年近く経過し、お客様のシステムの導入に携わったり、あるいは検証用でさわってみた方も結構いらっしゃるかと思います。

バージョン 5 系にからの変化は色々とありますが、CUI で使われる ls コマンド (-l オプション付) の表示結果にちょっとした変化があったことはお気づきでしたでしょうか？

・5 系の 'ls -l /' の結果例

$ ls -l /
合計 146
drwxr-xr-x   2 root root  4096 11月 10 06:48 bin
:

・6 系の 'ls -l /' の結果例

$ ls -l /
合計 1910
dr-xr-xr-x.   2 root root    4096  2月  5 03:32 2012 bin
:         ↑この赤いドット

上記のように、パーミッション情報の最後に一つフィールドが追加されています。この追加されたフィールドについては man を参照しても何も記載されていません。今回の連載を始めるきっかけになったのは「はてさて、これは何だ？」という疑問からでした。"ls -l" 編では、コマンドの動作の詳細とともに、この追加されたフィールドが何なのかというのも見ていきたいと考えています。

実際にソースコードで動作を見ていく前に、今回解析に使用するシステム情報などを整理しておきます。

OS は Scientific Linux 6.1 (以下 SL6.1) を使用します。

次に SL6.1 に含まれる ls コマンドのバージョンを確認しておきます。

$ rpm -qf /bin/ls
coreutils-8.4-13.el6.x86_64

※32bit 環境の場合、x86_64 の部分が i386 になります。

これに該当するソース RPM はミラーサイトなどからダウンロードします。ファイル名は
coreutils-8.4-13.el6.src.rpm です。
システムコールは kernel のソース RPM (kernel-2.6.32-131.0.15.el6.src.rpm)、
ライブラリは glibc のソース RPM (glibc-2.12-1.25.el6.src.rpm) をそれぞれ使用します。

もしご自分でソースコードをご覧になりたい方は、次のような手順でソース RPM を展開してみてください。

$ rpm -i coreutils-8.4-13.el6.src.rpm
$ rpmbuild -bp ~/rpmbuild/SPECS/coreutils.spec --nodeps

注：kernel のソース RPM を rpmbuild -bp で展開する際は gcc が必要になります。

ソースコードツリーは ~/rpmbuild/BUILD/ ディレクトリ配下に展開されます。(以降、~/rpmbuild/BUILD/ をトップディレクトリとして話を進めていきます。)

連載初回ということで、前振りや諸条件の説明でそれなりにスペースを使ってしまったので、今回はここまでとします。(初回からソースコード解説を期待されていた方には申し訳ない)

次回以降、実際にソースコードを引用しながら ls -l の動作を見ていきます。ls コマンドを実行した際に、最初に呼ばれるコードは coreutils-8.4/src/ls.c の 1230 行目 main() 関数です。

<coreutils-8.4/src/ls.c> より

   1230 main (int argc, char **argv)

(続く)

SUSE 系にしか存在しないサービス起動コマンド

2012-02-02T12:00:00.000+09:00

お元気ですか？私は元気です。稲垣です。

今回は SUSE 特有のコマンドをご紹介します。

皆さんは、サービスを起動するときに何というコマンドを使用していますか？

Red Hat 系 OS を使用している方は、基本的に以下の 2 つのコマンドのどちらかを使用してサービスの起動をしていると思います。


/sbin/service [サービス名] start
/etc/init.d/[サービス名] start

しかし SUSE 系の OS の場合は、この 2 つのコマンド以外にもサービスを起動するコマンドがデフォルトで存在します。

それは、rc[サービス名]コマンドです。これらのコマンドは、/etc/init.d/以下のコマンドのシンボリックリンクなので、/etc/init.d/以下のコマンドを実行するのと同じ様に動作します。

例:apache を起動する場合


/usr/sbin/rcapache2 start

rc コマンドは、/sbin、/usr/sbin、/usr/bin 以下にあります。


ls -l /sbin/rc*
/sbin/rcSuSEfirewall2 -> /etc/init.d/SuSEfirewall2_setup
/sbin/rcaaeventd -> /etc/init.d/aaeventd
/sbin/rcapparmor -> /etc/init.d/boot.apparmor

~省略~

/sbin/rcrpcbind -> /etc/init.d/rpcbind
/sbin/rcsubdomain -> /etc/init.d/boot.apparmor
/sbin/rcsyslog -> /etc/init.d/syslog


ls -l /usr/sbin/rc*
/usr/sbin/rcacpid -> /etc/init.d/acpid
/usr/sbin/rcalsasound -> /etc/init.d/alsasound
/usr/sbin/rcatd -> /etc/init.d/atd

~省略~

/usr/sbin/rcxfs -> /etc/init.d/xfs
/usr/sbin/rcxinetd -> /etc/init.d/xinetd
/usr/sbin/rcypbind -> /etc/init.d/ypbind


ls -l /usr/bin/rc*
/usr/bin/rcsmolt -> /etc/init.d/smolt

もしかすると、/etc/init.d/ 以下のコマンドを実行するより 1 秒くらい時間短縮ができるかもしれません。
SUSE ユーザの方は、使ってみてはいかがでしょうか。

以上、稲垣でした。

RHEL4 系のサポート期間について

2012-02-01T12:00:00.000+09:00

おはようございます、こんにちは、こんばんは。サイオステクノロジーの稲垣です。

来る 2012 年 2 月 29 日、以下の Red Hat Enterprise Linux 4 系のサポートが終了します。

Red Hat Enterprise Linux 4 - 30 day End Of Life Notice: https://rhn.redhat.com/errata/RHSA-2012-0073.html

[サポートが終了するプロダクト]: Red Hat Enterprise Linux AS 4; Red Hat Enterprise Linux ES 4; Red Hat Enterprise Linux WS 4; Red Hat Enterprise Linux Extras 4; Red Hat Desktop 4; Red Hat Global File System 4; Red Hat Cluster Suite 4

Red Hat 社では、より新しいバージョンである 5 系や 6 系へのアップデートを推奨しています。

アップデートが難しい場合には、Red Hat Enterprise Linux 4 Extended Lifecycle Support を契約することで、RHEL4 のサポート期間を最大 3 年延長できます。この契約は以下のプロダクトにしか適用することができないので注意が必要です。

[適用できるプロダクト]: Red Hat Enterprise Linux AS 4; Red Hat Enterprise Linux ES 4

しかし、以下の URL 内のパッケージ一覧に載っているものは、Extended Lifecycle Support を適用してもサポート対象外になるので注意してください。

Extended Life Cycle Support - Exclusions: http://www.redhat.com/rhel/server/extended_lifecycle_support/exclusions/
Red Hat Enterprise Linux 4 Extended Lifecycle Support の詳細はこちらから: ・レッドハット、RHEL 4のサポートを最大3年延長可能なオプション～最大10年間のサポートを提供; ・Red Hat Enterprise Linux Extended Life Cycle Support (RHEL ELS)延長サポートのご案内

アップデートを行うにしても、Red Hat 4 系を使用している場合は、早めの対応を行いましょう。

以上、稲垣からのお知らせでした。

SLES10でノベルカスタマセンターに接続できない問題

2012-01-31T12:00:00.000+09:00

ご無沙汰しております、サイオステクノロジーの稲垣です。

今回は、SLES10 でノベルカスタマセンターに接続できない問題について紹介します。
YaST を使用して [ノベルカスタマセンターの環境設定] を行った際に、以下のエラーが出力されてしまい、ノベルカスタマセンターへの接続に失敗する問題があります。


Execute curl command failed with '60':
curl: (60) SSL certificate problem, verify that the CA cert is OK. Details:
error: 14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
More details here ...

この問題は、SLES10SP4 のアップデートパッケージで修正が行われています。
また、新規に SLES10SP4 をインストールした場合は、既にセキュリティ証明書ファイルが置き換わっているため、対策を行わなくても接続できます。

しかし、セキュリティ証明書ファイルが置き換わる前に作成した SLES10SP4 のシステムや、SLES10SP4 以前のシステムは、対策を行わなければノベルカスタマセンターに接続できません。

これから、SLES10SP4 以前のバージョンと置き換わる前に作成した SLES10SP4 での対策を説明します。

SLES10SP4 以前のバージョンを使用している場合
SLES10SP4 以前のバージョンを使用している場合は、新しいセキュリティ証明書ファイルをダウンロードして置き換える必要があります。
1. /usr/share/curl/curl-ca-bundle.crt ファイルのバックアップを作成します。
```
cp /usr/share/curl/curl-ca-bundle.crt /usr/share/curl/curl-ca-bundle.crt.sav
```
2. root ユーザに変更します。
3. 以下の URL のファイルを、/usr/share/curl 以下と入れ替えます。
  http://support.novell.com/products/desktop/curl-ca-bundle.crt
```
# cd /usr/share/curl
# rm curl-ca-bundle.crt
# wget http://support.novell.com/products/desktop/curl-ca-bundle.crt
```
4. 以下のコマンドで、ダウンロードしたセキュリティ証明書のテストをします。
```
# curl -v https://secure-www.novell.com/home/
```
  ※このコマンドを実行したときにエラーが出力されなければ、対処が行われたことになります。
証明書が置き換わる前に作成した SLES10SP4 を使用している場合
SLES10SP4 については、パッケージで修正が行われています。以下の手順を実施して対処してください。
1. 以下の URL から、修正対応済みの suseRegister と openssl-certs パッケージをダウンロードします。
  
  The suseRegister
  
  http://download.novell.com/Download?buildid=Iedb9LC-InI~
  
  The openssl-certs
  
  http://download.novell.com/Download?buildid=_7Pup8oi5zw~
  
  ※これらのパッケージをダウンロードするには、ノベルカスタマセンターへのログインが必要になります。
2. rpm -Uvh を使用して、ダウンロードしたパッケージをインストールします。
```
rpm -Uvh suseRegister-1.2-9.55.1.noarch.rpm
```
```
rpm -Uvh openssl-certs-0.8.0-0.10.1.noarch.rpm
```
3. ノベルカスタマセンターへの接続を行います。
この手順を行なってもエラーが出力される場合は、以下の手順を実施します。
1. 以下のコマンドを実行し、/etc/ssl/certs ディレクトリを削除します。
```
rm -r /etc/ssl/certs/
```
2. 以下のコマンドを実行し、openssl-certs パッケージを再インストールします。
```
rpm -Uvh --replacepkgs openssl-certs-0.8.0-0.10.1.noarch.rpm
```
3. ノベルカスタマセンターへの接続を行います。

ノベル社のページにも同様の記載があります。

http://www.novell.com/support/viewContent.do?externalId=7010008&sliceId=1

以上、稲垣でした。

rootユーザに変更できるユーザの制限方法

2012-01-13T12:00:00.000+09:00

お久しぶりです、サイオステクノロジーの稲垣です。

今回は、root ユーザに変更できるユーザの制限方法について紹介します。
検証した OS は、RHEL4,5,6、SLES10,11、openSUSE10,11,12 です。
早速、su コマンドで root 権限を得ることができるユーザの制限を行う手順を記載していきます。

以下の設定は、ユーザ名 user1 と user2 のみ su コマンドで root 権限を得ることができるようにする設定です。

/etc/login.defs に下記を追記します。　　
```
SU_WHEEL_ONLY           yes
```
/etc/group の wheel グループの行に許可したいユーザを追記します。

[変更前]
```
wheel:x:10:
```
　
[変更後]
```
wheel:x:10:user1,user2
```
※複数ユーザを指定する場合は、 "," で区切ります。
※デフォルトで root が記載されている OS もあります。
以下の行を指定のファイルに追記します。
※SLES のバージョンによって追記するファイルが異なります。作業前に確認してください。
[追記する行]
```
auth     required       pam_wheel.so use_uid
```
[追記するファイル]
・RHEL4.x、SLES10、openSUSE10.x の場合
/etc/pam.d/su に追記します。
・RHEL5.x、6.x、SLES11、openSUSE11.x、12.x の場合
"su -" を制限したい場合は /etc/pam.d/su-l に追記、"su" を制限したい場合は /etc/pam.d/su に追記します。

これで、root ユーザに変更できるユーザを制限することができます。
なお、この設定は即時反映されるため、再起動等は必要ありません。

cscope と vim の連携

2012-01-06T12:00:00.000+09:00

寒い日々が続いていますが、いかがお過ごしですか？サイオステクノロジー稲垣です。
前回は cscope の使用方法についてご紹介しましたが、今回は cscope と vim との連携についてご紹介します。

cscope と vim を組み合わせて使うには cscope_map.vim プラグインを ~/.vim/plugin/cscope_maps.vim に配置します。
cscope_map.vim プラグインは sourceforge から取得できます。The Vim/Cscope tutorial もあわせてご覧ください。

インストール後、単語の先頭で下記のキー･バインディングをタイプすることで cscope のファンクションを呼び出すことが可能になります。

下記の記述で CTRL+\ s はコントロールキーと "\" を同時にタイプし、続けて "s" をタイプすることを示します。

CTRL+\ s : C シンボルの検索
CTRL+\ g : グローバルな定義の検索
CTRL+\ c : 呼び出す関数を検索
CTRL+\ t : この文字列を検索
CTRL+\ e : egrep パターンを検索
CTRL+\ f : ファイルを検索
CTRL+\ i : include しているファイルを検索
CTRL+\ d : 呼ばれる関数を検索

ソースコード解析ツール -cscope-

2012-01-05T12:00:00.000+09:00

明けましておめでとうございます。サイオステクノロジー稲垣です。
今回は、ソースコード解析ツールである cscope をご紹介します。

cscope は、C、lex、または yacc のソースファイル内のコードの特定の要素を探し出す対話型プログラムです。cscope を使用すると、従来のエディタよりも効率的にソースファイルを検索、編集できます。

cscope の初期起動オプション


$ cscope -b -q -i cscope.files

-b : インデックス作成後 cscope を起動しない
-q : 逆引き用インデックスを作成する
-i : インデックス作成に使うファイルリストを含んだファイルを指定する。
     通常は cscope.files

これでできるファイルは、以下の 3 つとなります。

cscope.in.out
cscope.out
cscope.po.out

cscope.files は下記コマンドを実行して作成します。


$ cscope-indexer -r

cscope は起動する毎にインデックスを作成しますが、-d オプションをつけて起動するとインデックス作成を行いません。

また cscope.files の先頭に "-q" と書いてあると、cscope 起動時に逆引き用インデックスを作成します。
(-q オプションを付けて起動するのと同じ動作をする)

-k オプションを指定すると /usr/include 以下のヘッダ･ファイルを参照しません。

worker MPM じゃないと ttl が動かない

2011-12-31T12:06:00.000+09:00

サイオス鎌田です。
2011年ももうすぐ終わりですね。
今回は、Apache のプロキシ設定に関するお話です。

Apache のプロキシ設定に、コネクションの生存時間を設定する ttl 設定があることはご存じでしょうか。

ProxyPass ディレクティブ: http://httpd.apache.org/docs/2.2/mod/mod_proxy.html#proxypass

実はこの ttl 設定、Apache のコンパイル時にデフォルトで選択されたり、RHEL 等のデフォルトである prefork MPM では動作しません。ソースコード上ではスレッド MPM が有効な場合のみ動作するよう設計されているんです。従って、worker MPM 等のスレッド MPM でなければ ttl が使えません。

そのため、例えば prefork MPM のまま ttl 設定を行い、プロキシ先のサーバ、例えば Tomcat で connectionTimeout を設定していると、Apache からコネクションを切断することがないため、Tomcat からコネクションの切断要求が送信されたままになってしまい、CLOSE_WAIT の状態になってしまいます。

現在の Apache の trunk 上にあるソースコードを見た限りでは、スレッド MPM 限定となるような設計にはなっていなかったので、おそらく Apache 2.4 からは prefork MPM でも ttl が動作すると思われますが、Apache 2.0 系または Apache 2.2 系で ttl を使う場合は、worker MPM を使う方がいいかもしれません。

Spam対策 -Postfix-

2011-12-28T12:00:00.000+09:00

こんにちは、サイオステクノロジー稲垣です。

前回に引き続き、Postfix の設定についてご紹介します。
今回は、Postfix での Spam 対策についてです。

Postfix で利用可能な Spam 対策を、以下に示します。

送信元の IP アドレスによる制限
Spam 送信者が利用する IP アドレスを元に制限します。この設定ではサーバに直接接続してくる IP アドレスのみに対して有効です。Spam 送信者がプロバイダの SMTP サーバを中継させて送信するようなケースでは利用できません。
1. /etc/postfix/main.cf に以下の行を追加します
  (一行で記述するか、折り返す場合は 2行目の先頭に TAB を入れます)
```
smtpd_client_restrictions =
 check_client_access hash:/etc/postfix/reject_client
```
2. /etc/postfix/reject_client を以下の形式で作成します
```
192.168.123.123 REJECT
172.16.1 REJECT
```
  これは、192.168.123.123 および 172.16.1.0/24 アドレスブロックからの SMTP 接続を却下する設定です。
3. postmap コマンドで reject_sender.db を作成します
```
# /usr/sbin/postmap /etc/postfix/reject_client
```
送信者による制限
送信者アドレス (envelope-from) またはそのドメイン部による受信制限の設定について説明します。ここで、送信者アドレスはヘッダ内の From: フィールドに書かれているアドレスではなく SMTP セッション中で MAIL FROM として指定されるアドレスです。
1. /etc/postfix/main.cf に以下の行を追加します
```
smtpd_sender_restrictions =
 hash:/etc/postfix/reject_sender
```
2. /etc/postfix/reject_sender を以下の形式で作成します
```
spammer@example.com REJECT
spammers.org REJECT
```
  これは、spammer@example.com および spammers.org ドメインを送信者アドレスに持つメールを却下する設定です。
3. postmap コマンドで reject_sender.db を作成します
```
# /usr/sbin/postmap /etc/postfix/reject_sender
```
ヘッダによる制限
Postfix では正規表現によるフィルタを行うことができます。ここでは、RHEL 標準の Postfix で利用できるようになっている pcre を利用する方法を述べます。
1. /etc/postfix/main.cf に以下の行を追加します
```
header_checks =
 pcre:/etc/postfix/header_checks
```
2. /etc/postfix/header_checks を以下の形式で作成します
```
/^X-Mailer: *Achi-Kochi Mail/i REJECT
/^X-Mailer: *IM200[0-9] Version/i REJECT
/^Subject:.*!!!/ REJECT
/^Subject:.*( \$\$\$|\$\$\$ )/ REJECT
```
  ここでは、X-Mailer: にバルク送信ツールが含まれているメール、Subject: に "!!!" や "$$$" が含まれているメールを却下します。("( \$\$\$|\$\$\$ )" としているのは、Subject: に生 JIS コードで日本語文字列が入っている場合の対策です) なお、i 修飾子は大文字と小文字を区別することを表わし、Perl などと正反対の動作を表わすので注意が必要です。
内容 (本文) による制限
1. /etc/postfix/main.cf に以下の行を追加します
```
body_checks =
 pcre:/etc/postfix/body_check_regex
```
2. /etc/postfix/body_check_regex
  ヘッダによる制限と同様に /etc/postfix/body_check_regex に正規表現を書いていきます。なお、現在のところは複数行に跨った文字列にマッチさせることは出来ません。

公開 RBL サービスの利用

Postfix では smtpd_client_restrictions に reject_rbl_client <利用する RBL のドメイン名> を加えることで利用することが出来ます。

設定例


smtpd_client_restrictions = permit_mynetworks,
 reject_invalid_hostname,
 reject_non_fqdn_sender,
 reject_non_fqdn_recipient,
 reject_unknown_sender_domain,
 reject_unknown_recipient_domain,
 reject_rbl_client bl.spamcop.net,
 reject_rbl_client blackholes.mail-abuse.org,
 reject_rbl_client dynablock.wirehub.net,
 reject_rbl_client korea.services.net,
 reject_rbl_client opm.blitzed.org,
 reject_rbl_client relays.ordb.org,
 reject_rbl_client relays.visi.com,
 reject_rbl_client sbl.spamhaus.org,
 reject_rbl_client sbl-xbl.spamhaus.org,
 permit

添付ファイルつきのメールを拒否する方法
Postfix では特定の拡張子を持つ添付ファイルのあるメールを拒否することができます。
1. /etc/postfix/main.cf に以下の行を追加します
```
header_checks = regexp:/etc/postfix/header_checks
```
2. /etc/postfix/header_checks を以下の形式で作成します
```
/name=.*\.scr/ REJECT
/name=.*\.exe/ REJECT
/name=\".*\.inf\"/ REJECT
/name=\".*\.scr\"/ REJECT
/name=\".*\.pif\"/ REJECT
/name=\".*\.bat\"/ REJECT
/name=\".*\.dll\"/ REJECT
/name=\".*\.vbs\"/ REJECT
/name=\".*\.reg\"/ REJECT
```
  「/name=」行は、「name=」が含まれるヘッダ内文字列に任意のファイル名（.*）に加え、「.」（\.）＋「scr」で終わる拡張子（.* \）が含まれている場合に拒否（REJECT）を意味する。以下、数行は拡張子のバリエーションを増やしているだけで、定義方法自体に変わりはない。

その他

Postfix とスパム対策ソフトウェア、ウィルス対策ソフトウェアを組合わせたもの。

メールサーバーでウィルス&スパムチェック

sendmail - ヘルプでのバージョン情報の隠蔽

2011-12-27T12:00:00.000+09:00

サイオス小川です。デフォルトの状態で telnet で sendmail にアクセスして、ヘルプを表示させると下記のように表示されます。


220 [FQDN] ESMTP Sendmail 8.13.7/8.13.7; Fri, 22 Oct 2010 12:04:15 +0900 (JST)
help
214-2.0.0 This is sendmail version 8.13.7
214-2.0.0 Topics:
214-2.0.0 HELO EHLO MAIL RCPT DATA
214-2.0.0 RSET NOOP QUIT HELP VRFY
214-2.0.0 EXPN VERB ETRN DSN AUTH
214-2.0.0 STARTTLS
214-2.0.0 For more info use "HELP ".
214-2.0.0 To report bugs in the implementation see
214-2.0.0 http://www.sendmail.org/email-addresses.html
214-2.0.0 For local information send email to Postmaster at your site.
214 2.0.0 End of HELP info

ヘルプの設定ファイルは、/etc/mail/helpfile となっています。内容は下記の通りです。


#vers 2
cpyr
cpyr Copyright (c) 1998-2000, 2002, 2004-2006 Sendmail, Inc. and its suppliers.
cpyr All rights reserved.
cpyr Copyright (c) 1983, 1995-1997 Eric P. Allman. All rights reserved.
cpyr Copyright (c) 1988, 1993
cpyr The Regents of the University of California. All rights reserved.
cpyr
cpyr
cpyr By using this file, you agree to the terms and conditions set
cpyr forth in the LICENSE file which can be found at the top level of
cpyr the sendmail distribution.
cpyr
cpyr $$Id: helpfile,v 8.47 2006/04/26 18:22:54 ca Exp $$
cpyr
smtp This is sendmail version $v
smtp Topics:
smtp HELO EHLO MAIL RCPT DATA
smtp RSET NOOP QUIT HELP VRFY
smtp EXPN VERB ETRN DSN AUTH
smtp STARTTLS
smtp For more info use "HELP ".
smtp To report bugs in the implementation see
smtp http://www.sendmail.org/email-addresses.html
smtp For local information send email to Postmaster at your site.
help HELP [ ]
help The HELP command gives help info.
helo HELO
helo Introduce yourself.
ehlo EHLO
ehlo Introduce yourself, and request extended SMTP mode.
ehlo Possible replies include:
ehlo SEND Send as mail [RFC821]
ehlo SOML Send as mail or terminal [RFC821]
ehlo SAML Send as mail and terminal [RFC821]
ehlo EXPN Expand the mailing list [RFC821]
ehlo HELP Supply helpful information [RFC821]
ehlo TURN Turn the operation around [RFC821]
ehlo 8BITMIME Use 8-bit data [RFC1652]
ehlo SIZE Message size declaration [RFC1870]
ehlo VERB Verbose [Allman]
ehlo CHUNKING Chunking [RFC1830]
ehlo BINARYMIME Binary MIME [RFC1830]
ehlo PIPELINING Command Pipelining [RFC1854]
ehlo DSN Delivery Status Notification [RFC1891]
ehlo ETRN Remote Message Queue Starting [RFC1985]
ehlo STARTTLS Secure SMTP [RFC2487]
ehlo AUTH Authentication [RFC2554]
ehlo ENHANCEDSTATUSCODES Enhanced status codes [RFC2034]
ehlo DELIVERBY Deliver By [RFC2852]
mail MAIL From: [ ]
mail Specifies the sender. Parameters are ESMTP extensions.
mail See "HELP DSN" for details.
rcpt RCPT To: [ ]
rcpt Specifies the recipient. Can be used any number of times.
rcpt Parameters are ESMTP extensions. See "HELP DSN" for details.
data DATA
data Following text is collected as the message.
data End with a single dot.
rset RSET
rset Resets the system.
quit QUIT
quit Exit sendmail (SMTP).
auth AUTH mechanism [initial-response]
auth Start authentication.
starttls STARTTLS
starttls Start TLS negotiation.
verb VERB
verb Go into verbose mode. This sends 0xy responses that are
verb not RFC821 standard (but should be) They are recognized
verb by humans and other sendmail implementations.
vrfy VRFY
vrfy Verify an address. If you want to see what it aliases
vrfy to, use EXPN instead.
expn EXPN
expn Expand an address. If the address indicates a mailing
expn list, return the contents of that list.
noop NOOP
noop Do nothing.
send SEND FROM:
send replaces the MAIL command, and can be used to send
send directly to a users terminal. Not supported in this
send implementation.
soml SOML FROM:
soml Send or mail. If the user is logged in, send directly,
soml otherwise mail. Not supported in this implementation.
saml SAML FROM:
saml Send and mail. Send directly to the user's terminal,
saml and also mail a letter. Not supported in this
saml implementation.
turn TURN
turn Reverses the direction of the connection. Not currently
turn implemented.
etrn ETRN [ | @ | \# ]
etrn Run the queue for the specified , or
etrn all hosts within a given , or a specially-named
etrn (implementation-specific).
dsn MAIL From: [ RET={ FULL | HDRS} ] [ ENVID= ]
dsn RCPT To: [ NOTIFY={NEVER,SUCCESS,FAILURE,DELAY} ]
dsn [ ORCPT= ]
dsn SMTP Delivery Status Notifications.
dsn Descriptions:
dsn RET Return either the full message or only headers.
dsn ENVID Sender's "envelope identifier" for tracking.
dsn NOTIFY When to send a DSN. Multiple options are OK, comma-
dsn delimited. NEVER must appear by itself.
dsn ORCPT Original recipient.
-bt Help for test mode:
-bt ? :this help message.
-bt .Dmvalue :define macro `m' to `value'.
-bt .Ccvalue :add `value' to class `c'.
-bt =Sruleset :dump the contents of the indicated ruleset.
-bt =M :display the known mailers.
-bt -ddebug-spec :equivalent to the command-line -d debug flag.
-bt $$m :print the value of macro $$m.
-bt $$=c :print the contents of class $$=c.
-bt /mx host :returns the MX records for `host'.
-bt /parse address :parse address, returning the value of crackaddr, and
-bt the parsed address.
-bt /try mailer addr :rewrite address into the form it will have when
-bt presented to the indicated mailer.
-bt /tryflags flags :set flags used by parsing. The flags can be `H' for
-bt Header or `E' for Envelope, and `S' for Sender or `R'
-bt for Recipient. These can be combined, `HR' sets
-bt flags for header recipients.
-bt /canon hostname :try to canonify hostname.
-bt /map mapname key :look up `key' in the indicated `mapname'.
-bt /quit :quit address test mode.
-bt rules addr :run the indicated address through the named rules.
-bt Rules can be a comma separated list of rules.
control Help for smcontrol:
control help This message.
control restart Restart sendmail.
control shutdown Shutdown sendmail.
control status Show sendmail status.
control memdump Dump allocated memory list (for debugging only).

ヘルプでのバージョン情報を表示させないようにするために /etc/mail/helpfile を下記のように変更します。


smtp This is sendmail version $v
↓
smtp This is Mail Server

変更後、sendmail を再起動します。（sendmail.cf の再作成は不要）

telnet で sendmail にアクセスしてヘルプを表示させると下記のようになります。


220 [FQDN] ESMTP Sendmail 8.13.7/8.13.7; Wed, 23 Aug 2006 12:17:35 +0900 (JST)
help
214-2.0.0 This is Mail Server
214-2.0.0 Topics:
214-2.0.0 HELO EHLO MAIL RCPT DATA
214-2.0.0 RSET NOOP QUIT HELP VRFY
214-2.0.0 EXPN VERB ETRN DSN AUTH
214-2.0.0 STARTTLS
214-2.0.0 For more info use "HELP ".
214-2.0.0 To report bugs in the implementation see
214-2.0.0 http://www.sendmail.org/email-addresses.html
214-2.0.0 For local information send email to Postmaster at your site.
214 2.0.0 End of HELP info

sendmail - メールヘッダのバージョン情報の隠蔽

2011-12-26T12:00:00.000+09:00

サイオス小川です。sendmail をデフォルト状態で使用するとメールヘッダに sendmail のバージョン情報が出力されます。下記 (8.13.8/8.13.8) の部分が該当します。

sendmail のバージョン情報を削除する方法


Received: from smtp (rhel5-5 [127.0.0.1])
by rhel5-5.labs.sios.com (8.13.8/8.13.8) with ESMTP id o913QBHg002003
for root@example.com; Fri, 1 Oct 2010 12:27:01 +0900

/etc/mail/sendmail.cf の設定を変更する。

sendmail.cf の変更は直接 sendmail.cf を変更するのでなく、sendmail.mc を変更して、これにマクロプロセッサで処理を行って sendmail.cf を生成します。

一連の作業は /etc/mail ディレクトリで行います。


# cd /etc/mail

エディタで sendmail.mc を開き、ファイルの最終行に以下を追加します。


define(`confRECEIVED_HEADER',`$?sfrom $s $.$?_($?s$|from $.$_)
$.$?{auth_type}(authenticated$?{auth_ssf} bits=${auth_ssf}$.)
$.by $j (unknown)$?r with $r$. id $i$?{tls_version}
(version=${tls_version} cipher=${cipher} bits=${cipher_bits} verify=${verify})$.$?u
for $u; $|;
$.$b')dnl

エディタで上書き保存後、make を実行します。


# make

ここまでで sendmail.cf の変更が終了しています。この設定を読みこますために sendmail のリロードを行います。(再起動の必要はありません)


# /sbin/service sendmail reload

以上で作業は完了です。

この作業で sendmail の (8.13.8/8.13.8) の部分を (unkown) と表示するようになります。


Received: from smtp (rhel5-5.labs.sios.com [10.1.1.129])
by rhel5-5.labs.sios.com (unknown) with ESMTP id o9143iLY002196
for root@examle.com; Fri, 1 Oct 2010 13:04:19 +0900

CentOS 6.2 リリースされました

2011-12-22T12:05:00.002+09:00

サイオステクノロジー金田です。

12/9 に CentOS 6.1 が出たばかりですが、12/20 には CentOS 6.2 が早々とリリースされたので、早速 CentOS 6.2 をインストールしてみました。

インストール手順などは CentOS 6.0 と特に変わっているところはありませんでしたが、個人的に気になっていた点として、CentOS 6.0 では「システム」→「設定」→「ウィンドウ」の項目が無かった(画像1)ので、CentOS 6.1/6.2 で復活するかどうか注目していました。

画像１ CentOS 6.0 「システム」→「設定」メニュー

結果的に CentOS 6.1 で復活したようで(※)、CentOS 6.2 でも使用できるようになっています。(画像2)
※：Scientific Linux 6.1 や RHEL 6.1 で利用可能であることはすでに確認していました。

画像２ CentOS 6.2 「システム」→「設定」メニュー

sendmail - グリーティング･メッセージでのバージョン情報の隠蔽

2011-12-22T12:00:00.000+09:00

サイオス小川です。デフォルトの状態で telnet で sendmail にアクセスすると下記のように出力されます。


220 [FQDN] ESMTP Sendmail 8.13.7/8.13.7; Fri, 22 Oct 2010 12:04:15 +0900 (JST)

これに関するデフォルトの /etc/mail/sendmail.cf 設定は下記の通りです。


SmtpGreetingMessage=$j Sendmail $v/$Z; $b

この設定を sendmail.mc を使って変更します。次の行を sendmail.mc に追加します。


define(`confSMTP_LOGIN_MSG', `$j unknown; $b')dnl

sendmail.cf を作成し直して、sendmail を再起動します。この時の sendmail.cf は下記の通りです。


SmtpGreetingMessage=$j unknown; $b

telnet で sendmail にアクセスすると下記のようになります。


220 [FQDN] ESMTP unknown; Fri, 22 Oct 2010 14:26:33 +0900 (JST)

sendmail - mailertable による冗長化

2011-12-21T16:00:00.000+09:00

サイオス小川です。

/etc/mail/mailertable に下記のように記述することにより、経路の冗長化をすることができます。

フォールバック


domain smtp:[IPアドレス1]:[IPアドレス]:[IPアドレス]

ラウンドロビン


domain smtp:[IPアドレス1],[IPアドレス],[IPアドレス]

sendmail で宛先を限定する方法

2011-12-21T12:00:00.000+09:00

サイオス小川です。mailertable を使用して宛先を制限します。

1. /etc/mail/mailertable で下記の様に localhost と送信を許可するドメインの設定をします。また、最後の行で指定のない宛先に対してはエラー"error:5.7.1:553 Relaying denied" を返却するように設定します。

/etc/mail/mailertable


localhost local:
example1.com smtp:example1.com
example2.com smtp:example2.com
example3.com smtp:example3.com
. error:5.7.1:553 Relaying denied

2. make mailertable.db を実行し、mailertable.db を更新する。

この設定により下記の動作をするようになります。

<ユーザー名@localhost> 宛のメールはローカルスプールに受信します。
<ユーザー名@example1.com> 宛等のメールは DNS を参照して転送先が決められます。
それ以外のメールはエラーで転送拒否されます。

DNS による名前解決を行わない設定 -Postfix-

2011-12-20T15:00:00.000+09:00

サイオステクノロジー稲垣です。

Postfix を使用して、受信したメールを DNS による名前解決を使わずに main.cf の relayhost の設定を使って送信する方法をご紹介します。

relayhost の転送先ホスト名または IP アドレスを、角括弧 ("[" "]") で囲みます。このように設定すると、Postfix は該当ホスト名または IP アドレスについて、DNS による名前解決を行わず (DNS クエリーを発行せず) に処理を行います。

設定例

relayhost = [192.168.xx.xx]

この際、/etc/hosts に該当ホスト名が設定されていなければエラーになります。

あるいは、main.cf にて下記行を追加することで、Postfix は全てのホスト名または IP アドレスについて、DNS による名前解決をせずに処理を行います。


disable_dns_lookups = yes

bind 脆弱性 CVE-2011-4313 リンクまとめ

2011-12-16T12:00:00.001+09:00

サイオステクノロジー金田です。

DNS サーバ bind の脆弱性 CVE-2011-4313 についてリンクをまとめてみました。

bind の開発元である ISC の英語ページは 12/5 付で更新されていますが、日本語のページは更新されていません。日本語の情報としては IIJ-SECT の情報がわかりやすいと思います。

ISC Security Advisory

CVE-2011-4313: BIND 9 Resolver crashes after logging an error in query.c
https://www.isc.org/software/bind/advisories/cve-2011-4313
(日本語) https://www.isc.org/advisorycve20114313JP
CVE-2011-4313 FAQ and Supplemental Information
https://deepthought.isc.org/article/AA-00549

IIJ-SECT Security Diary

CVE-2011-4313 BIND9 キャッシュサーバの脆弱性について
https://sect.iij.ad.jp/d/2011/11/160759.html
CVE-2011-4313 BIND9 キャッシュサーバの脆弱性について (続報)
https://sect.iij.ad.jp/d/2011/12/067936.html

他順不同

修正パッチ適用推奨ですが、修正パッチを適用できない場合の対処は、

権威サーバ(Authoritative-only servers、コンテンツサーバとも言う)：影響なし。
キャッシュサーバ(Recursive servers)："minimal-responses yes;" で回避可能。
権威サーバとキャッシュサーバを兼ねている("mixed-mode" servers)：設定での回避は不可。機能を分離すること。

CentOS/Scientific Linux とも修正パッケージが公開されています。

4.x系 bind-9.2.4-38.el4
5.x系 bind-9.3.6-16.P1.el5_7.1
      bind97-9.7.0-6.P2.el5_7.4
6.x系 bind-9.7.3-2.el6_1.P3.3

RHEL errata

4.x 系 https://rhn.redhat.com/errata/RHSA-2011-1496.html
5.x 系 https://rhn.redhat.com/errata/RHSA-2011-1458.html
       https://rhn.redhat.com/errata/RHSA-2011-1459.html
6.x 系 https://rhn.redhat.com/errata/RHSA-2011-1458.html

CentOS 6 系で NIC 交換すると eth0 と認識されない

2011-12-16T12:00:00.000+09:00

サイオステクノロジー金田です。

CentOS6 (RHEL6/Scientific Linux6) では、HW 不良等により NIC を交換すると、交換したNICが eth0 ではなく eth1 と認識されてしまいます。

MAC アドレスが異なる NIC が追加されるたびに /etc/udev/rules.d/70-persistenet-net.rules にエントリが追加されてしまうためにこのような現象になるのですが、交換した NIC を eth0 と認識させる方法について以下に紹介します。

(1) MAC アドレスの確認
/etc/sysconfig/network-scripts/ifcfg-eth1 がない場合、ifconfig eth1 を実行し HWaddr の内容を記録しておきます。

(2) ネットワーク関連サービスの停止

# service NetworkManager stop (＊)
# service network stop

＊：NetworkManager がインストールされている場合

(3) ネットワークモジュールのアンロード

# rmmod <ドライバ名>

※ドライバ名は /etc/udev/rules.d/70-persistent-net.rules ファイル内の NIC 設定行の１行上のコメント行の末尾に () で括られて記載されています。
(下記例は vmnet3)

# PCI device 0x15ad:0x07b0 (vmxnet3)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:0c:29:79:22:65", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"

(4) ifcfg-ethX ファイルのリネームまたは修正
/etc/sysconfig/network-scripts/ifcfg-eth1 がある場合は、ifcfg-eth0 ファイルと ifcfg-eth1 ファイルを次のように変更します。

# mv ifcfg-eth0 ifcfg-eth0.bak
# mv ifcfg-eth1 ifcfg-eth0

/etc/sysconfig/network-scripts/ifcfg-eth1 がない場合は、ifcfg-eth0 の HWADDR= の値を (1) で保存した値に書き換えます。

(5) /etc/udev/rules.d/70-persistent-net.rules のバックアップ

# mv /etc/udev/rules.d/70-persistent-net.rules \
     /etc/udev/rules.d/70-persistent-net.rules.bak

(6) ネットワークモジュールのロード

# modprobe <ドライバ名>

(7) ネットワーク関連サービスの起動

# service network start
# service NetworkManager start (＊)

＊：NetworkManager がインストールされている場合

上記は、eth1 として認識してしまった後の変更方法ですが、/etc/udev/rules.d/70-persistent-net.rules に NIC のエントリを作成されないようにする方法も併せて紹介します。

/lib/udev/rules.d/75-persistent-net-generator.rules にある下記の行をコメントアウトすることで、/etc/udev/rules.d/70-persistenet-net.rules に新しい NIC の情報は追加されなくなります。

(変更前)

DRIVERS=="?*", IMPORT{program}="write_net_rules"

(変更後)

# DRIVERS=="?*", IMPORT{program}="write_net_rules"

Trouble Maker を触ってみました

2011-12-16T11:28:00.000+09:00

サイオス鎌田です。

数日前に、Gigazine のニュースに Trouble Maker というツールが紹介されていました。これは、Linux サーバに細工を施し、システムが起動しなくなる等のトラブルをわざと引き起こすツールで、Linux のトラブル解決の練習になるようなものです。というわけで、一つ検証環境を用意して、さっそく動かしてみました。

Trouble Maker: http://trouble-maker.sourceforge.net/

まずはインストール方法から。難しいことはありません。


# rpm -Uvh http://pkgs.repoforge.org/rpmforge-release/rpmforge-release-0.5.2-2.el5.rf.i386.rpm
# yum install perl-YAML
# wget http://sourceforge.net/projects/trouble-maker/files/trouble-maker/0.11/trouble-maker-0.11.tgz/download
# cd /
# tar xzvf /path/to/trouble-maker-0.11.tgz

起動してみます。


# /usr/local/trouble-maker/bin/trouble-maker.pl --version=RHEL_5

Trouble-maker version 0.10
Copyright (C) 2004 by Josh More
Trouble-maker comes with ABSOLUTELY NO WARRANTY
This is free software, and you are welcome to redistribute it under certain conditions.
For details, see the file 'COPYING' included with this distribution.

This program is intended for training purposes only, and will cause system problems.
To proceed, type 'yes'.
(To bypass this step, change the value of the $bypass variable to '1')
>yes
PROBLEM:
The system will not boot

さらっと、システムが起動しなくなると怖いことを言ってきます。実際にここで再起動すると、次のメッセージが出て OS が起動しなくなります。ぜひ、皆さんも検証用の環境を作って動かしてみてはいかがでしょうか。


Kernel panic - not syncing: Attempted to kill init!

CVE-2011-3192 の新しい攻撃コードが公開されています

2011-12-15T13:52:00.001+09:00

お久しぶりです。サイオス鎌田です。今年も残すところあとわずかとなりました。今回は脆弱性のお話です。

夏の終わりごろ、HTTP サーバとして有名な Apache HTTPD に、CVE-2011-3192 という脆弱性が存在することが発覚し、アナウンスから 48 時間以内に修正を実施することを宣言するなど、少し大きな騒ぎとなりました。

現在は修正版もリリースされていますし、バージョンアップを行わずに設定を変更することで回避している方もいらっしゃるかと思います。設定を変更することで回避する方法として、当初 Apache HTTPD のアナウンスでは、Range ヘッダに 5 つ以上範囲指定されているリクエストを無視したり、HTTP リクエストのヘッダサイズを制限したり、Range ヘッダの指定をそもそも無視するといった方法を紹介していました。

今回、公開された新しい攻撃コードは、この設定変更による回避策のうち、Range ヘッダに 5 つ以上範囲指定されているリクエストを無視する方法と、HTTP リクエストのヘッダサイズを制限する方法を破る攻撃となっています。具体的には、Range ヘッダには 2 つの範囲指定を行い、Accept-Encoding ヘッダに gzip を指定したリクエストを頻繁に行うという、単純、かつ効果的に DoS を実現させる攻撃となっています。

そのため、Range ヘッダを無視することで回避を行っている方には影響がないのですが、どうしても Range ヘッダを有効化する方にとっては非常に厄介な攻撃コードが公開されたことになります。こうなると、対策方法としては Apache HTTPD をバージョンアップするしかありません。

このように、当初は良かった対策でも、新しい攻撃コードが公開されることによって再度脅威にさらされるというケースがありますので、一度稼働を始めたバージョンを使い続けるだけでなく、定期的にバージョンアップを行うことを前提とした運用を検討されることをお勧めいたします。

なお、現在公開されている最新の Apache HTTPD のバージョンは、2.2.21 となっています。

PostgreSQL で、STATISTICS (列の統計精度) を変更した箇所を忘れたら

2011-12-15T09:00:00.000+09:00

お世話になっております、サイオス那賀です。

PostgreSQL では、特定のテーブルの特定のカラムごとに、統計情報を取得する際の精度を指定することで、大きなテーブルでは荒くなりがちな統計情報の精度を調整することができるようになっています。


postgres=# ALTER TABLE users ALTER COLUMN name SET STATISTICS 500;
ALTER TABLE

しかし、いろいろやっていると、データベース全体のどこに指定をしたか忘れてしまいます。そんな時は、以下のようにすれば変更箇所を一覧することができます。


postgres=# SELECT c.relname, a.attname, a.attstattarget
  FROM pg_attribute AS a, pg_class AS c
  WHERE c.oid = a.attrelid and a.attstattarget > 0;
 relname | attname | attstattarget
---------+---------+---------------
 users   | name    |           500
(1 row)

ところでこの値のデフォルトである "default_statistics_target" パラメータは、VACUUM の効率やマシン性能の向上に合わせて、徐々に上がっています。

「18.6 問い合わせ計画 - PostgreSQL 8.3 文書」

default_statistics_target（integer）…デフォルトは10です。

「18.6 問い合わせ計画 - PostgreSQL 8.4 文書」

default_statistics_target（integer）…デフォルトは100です。

以前は、10 では小さすぎるので調整をすると性能が上がりましたが、100 もあれば、よほど大きなテーブルでなければ問題なくなった模様。

では。

ソースの入手と再ビルド～ Amazon Linux AMI (EC2) 編

2011-12-14T15:00:00.000+09:00

お疲れ様です、サイオス那賀です。

Amazon Linux AMI は、AWS (Amazon Web Services) 専用に、Amazon.com によって開発されている Linux ディストリビューションの仮想環境イメージ (AMI: Amazon Machine Image) です。今のところ実態としては、RHEL6 系に近いものになっています。てっきり CentOS あたりをベースにリコンパイルだけをして作っているのかと思っていたのですが、RHEL6 を下敷きにしつつも、自前で全部作っているそうです。AWS の機能に特化されているのみならず、Amazon のサポートに通りが良いところがウリです。

そのようなわけですから、Amazon Linux もまた RPM ベースです。Amazon Linux も YUM は備えているのですが、ソースの入手には yumdownloader ではなく、別途 get_reference_source コマンド経由で、web サービスを利用します。右記参照、「Q: Amazon Linux AMI へのソースコードを見ることができますか？ - Amazon Elastic Compute Cloud (Amazon EC2) FAQ」。


$ get_reference_source --aws-account-id=XXXX-XXXX-XXXX \
 --package=which

Requested package: which

Found package from local RPM database: which-2.19-5.1.9.amzn1
Corresponding source RPM to found package : which-2.19-5.1.9.amzn1.src.rpm

Your AWS account id: XXXX-XXXX-XXXX

Are these parameters correct? Please type 'yes' to continue: yes
Source RPM for 'which-2.19-5.1.9.amzn1' downloaded to: /usr/src/srpm/debug/which-2.19-5.1.9.amzn1.src.rpm
[ knaka@ip-10-146-81-102:~ S ]
$ ls -ld /usr/src/srpm/debug
drwxrwxrwt 2 root root 4096 Dec XX 03:36 /usr/src/srpm/debug/

それ以降は他の distro と大差ないのですが、以前の記事（「SIOS OSS Tech: debuginfo RPM パッケージで、ソースレベル・デバッグをする」）などで触れた Red Hat 系における "redhat-rpm-config" パッケージが、Amazon Linux では "system-rpm-config" パッケージにあたるので、既存パッケージと同等の構成でインストールしたい場合や、特に、debuginfo パッケージが必要な場合には、これもインストールしておいてください。


$ sudo yum install -y system-rpm-config
$ rpmbuild --rebuild --define="optflags -pg -g3 -O0" \
 /usr/src/srpm/debug/which-2.19-5.1.9.amzn1.src.rpm
(中略)
Wrote: /home/knaka/rpm/RPMS/i686/which-2.19-5.1.9.amzn1.i686.rpm
Wrote: /home/knaka/rpm/RPMS/i686/which-debuginfo-2.19-5.1.9.amzn1.i686.rpm
(中略)

では。

PostgreSQL の SQL やプロシージャでランダムデータの入ったテーブルを生成する

2011-12-13T17:00:00.000+09:00

お疲れ様です、サイオス那賀です。

テーブルの抱えるサンプルデータの行数が 2～3 行だと、何をどうしてもインデックスなど使われないのでつまらない時に、自動的に生成した沢山のランダムデータを INSERT する方法です。連番 10000 個につき、ランダムな 20 文字からなる名前をそれぞれに持つ "users" テーブルを作成してみます。

SQL のみで実行

まずは、バージョン 9.0 以降での例です。


DROP TABLE users CASCADE;

CREATE TABLE users (id integer PRIMARY KEY, name text);

INSERT INTO users (id, name) (
  SELECT id,
   string_agg(substr(s, ceil(random() * length(s))::int, 1),'')
    FROM (
      SELECT 'abcdefghijklmnopqrstuvwxyz'
       'ABCDEFGHIJKLMNOPQRSTUVWXYZ'::text s, *
        FROM generate_series(1, 10000) AS id, generate_series(1, 20)
    ) AS tmp
    GROUP BY id
);

CREATE INDEX ON users (name); -- 9.0 から、インデックス名は省略可能

ここでは、新しく導入された string_agg() 集約関数を使用しているため、8.4 以前では動きません。サブクエリをそれぞれ実行してみれば、何をしているかは分かると思います。

ランダムな文字列が生成されていることと、充分にデータが大きいのでインデックスが使われていることを確認します。


postgres=# SELECT * FROM users LIMIT 10;
 id |         name
----+----------------------
  1 | bCphDuvZliwsKjSciOZA
  2 | oYTQPutKQqYRTnYwIuwU
  3 | DSmnbfqkTpKioEZeZsOP
  4 | JNHCbFYJauDDnPRpVizO
  5 | xkXMPWQOoFEXslAtRycS
  6 | TGvhwnxrvWgThdFXawMo
  7 | bqmtCNNulQmfwInTWKkr
  8 | HrlPvRMvnyJpPWJrJwLV
  9 | mYbJGoCCZNUGefvzXiUl
 10 | GEAwBkNlGzgTxiCexfGw
(10 rows)

postgres=# EXPLAIN SELECT * FROM users WHERE name = 'hoge';
                                  QUERY PLAN
------------------------------------------------------------------------------
 Bitmap Heap Scan on users  (cost=4.64..75.57 rows=50 width=36)
   Recheck Cond: (name = 'hoge'::text)
   ->  Bitmap Index Scan on users_name_idx  (cost=0.00..4.63 rows=50 width=0)
         Index Cond: (name = 'hoge'::text)
(4 rows)

postgres=#

バージョン 8.4 でも、配列に対する集約関数である array_agg() 関数が使えるので、以下のようにできます。


DROP TABLE users CASCADE;

CREATE TABLE users (id integer PRIMARY KEY, name text);

INSERT INTO users (id, name) (
  SELECT id, array_to_string(
   array_agg(a[ceil(random() * array_length(a, 1))]),'' )
    FROM (
      SELECT ARRAY[
       'a', 'b', 'c', 'd', 'e', 'f', 'g', 'h', 'i', 'j', 'k', 'l', 'm',
       'n', 'o', 'p', 'q', 'r', 's', 't', 'u', 'v', 'w', 'x', 'y', 'z',
       'A', 'B', 'C', 'D', 'E', 'F', 'G', 'H', 'I', 'J', 'K', 'L', 'M',
       'N', 'O', 'P', 'Q', 'R', 'S', 'T', 'U', 'V', 'W', 'X', 'Y', 'Z'
      ] AS a, *
        FROM generate_series(1, 10000) AS id, generate_series(1, 20)
    ) AS tmp
    GROUP BY id
);

CREATE INDEX users_name_idx ON users (name);

8.3 以前では、array_agg() も無いので、集約関数では無理だと思います。ストアドプロシージャを使います。

ストアドプロシージャで実行

9.0 以降には DO コマンドがあり、無名関数の実行ができますので "DO $$～" のように実行できますが、8.4 以前では、一旦名前をつけて関数を定義する必要があります。

以下は、8.3 でも動きます。


DROP TABLE users CASCADE;

CREATE TABLE users (id integer PRIMARY KEY, name text);

CREATE OR REPLACE FUNCTION tmp() RETURNS void AS
$$
  DECLARE
    i INTEGER;
    id INTEGER;
    name text;
    s text := 'abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ';
  BEGIN
    FOR id IN 1 .. 10000 LOOP
      name := '';
      FOR i IN 1 .. 20 LOOP
        name := name || substr(s, ceil(random() * length(s))::int, 1);
      END LOOP;
      INSERT INTO users VALUES(id, name);
    END LOOP;
  END
$$ LANGUAGE plpgsql;

SELECT tmp();

DROP FUNCTION tmp();

CREATE INDEX users_name_idx ON users (name);

では。

RHEL6.1～系の OpenLDAP (slapd.conf) で SSH 公開鍵配布

2011-12-12T15:00:00.000+09:00

お世話になっております、SIOS 那賀です。

先日掲載した「SIOS OSS Tech: RHEL6 系での OpenLDAP サーバと PAM 認証」で、slapd.conf 型から cn=config 型への移行を頑張ろうと決意したのですが、「Convert schema files for import - OpenLdap: Switch to dynamic config backend (cn=config) - Zarafa wiki」を読んでアホらしくなってしまい、slapd.conf へ戻すことにしました。今回の主題は OpenLDAP を使った SSH キーの配布なのですが、その前段として、前回の手順一通りを、slapd.conf を用いるものに書き換えて再掲しようと思います。cn=config 方式にも有用な場面は（多分）あるかと思われますので、既存の記事も、そのまま残しておきます。

ディレクトリ・サーバの設定

まずはいつものように、SELinux と iptables の無効化です。実運用のサーバでは、運用ポリシーに従って、それぞれ適切に設定してください。


[root@dirserv ~]# setenforce permissive
[root@dirserv ~]# getenforce
Permissive
[root@dirserv ~]# service iptables stop
iptables: ファイアウォールルールを消去中:                  [  OK  ]
iptables: チェインをポリシー ACCEPT へ設定中filter         [  OK  ]
iptables: モジュールを取り外し中:                          [  OK  ]
[root@dirserv ~]#

サーバと、操作用のクライアントをインストールします。


[root@dirserv ~]# yum install -y openldap-clients openldap-servers

もし動いているようであれば、slapd サービスを停止させてから、slapd.d/ ディレクトリを削除します。これで、slapd は slapd.conf から設定を読むようになります。


[root@dirserv ~]# service slapd status
slapd は停止しています
[root@dirserv ~]# rm -fr /etc/openldap/slapd.d/ /var/lib/ldap/*

"Obsolete" のファイルを元に、slapd.conf を作成します。


[root@dirserv ~]# slappasswd -s secret2
{SSHA}Z42Qdb/r/YAw0QRD8vI/SYcLgoxtzF4l
[root@dirserv ~]# cp \
 /usr/share/openldap-servers/slapd.conf.obsolete \
 /etc/openldap/slapd.conf
[root@dirserv ~]# chown ldap.ldap /etc/openldap/slapd.conf
[root@dirserv ~]# chmod 0600 /etc/openldap/slapd.conf
[root@dirserv ~]# vi /etc/openldap/slapd.conf
[root@dirserv ~]# diff -uNr \
 /usr/share/openldap-servers/slapd.conf.obsolete \
 /etc/openldap/slapd.conf
--- /usr/share/openldap-servers/slapd.conf.obsolete
+++ /etc/openldap/slapd.conf
@@ -64,9 +64,9 @@
 # /etc/pki/tls/certs, running "make slapd.pem", and fixing permissions on
 # slapd.pem so that the ldap user or group can read it.  Your client software
 # may balk at self-signed certificates, however.
-# TLSCACertificateFile /etc/pki/tls/certs/ca-bundle.crt
-# TLSCertificateFile /etc/pki/tls/certs/slapd.pem
-# TLSCertificateKeyFile /etc/pki/tls/certs/slapd.pem
+TLSCACertificateFile /etc/pki/tls/certs/ca-bundle.crt
+TLSCertificateFile /etc/pki/tls/certs/slapd.pem
+TLSCertificateKeyFile /etc/pki/tls/certs/slapd.pem

 # Sample security restrictions
 #      Require integrity protection (prevent hijacking)
@@ -95,14 +95,26 @@
 #
 # rootdn can always read and write EVERYTHING!

+access to attrs=userPassword
+  by dn="cn=Manager,dc=example,dc=com" write
+  by self write
+  by anonymous auth
+  by * none
+
+access to *
+  by dn.exact="cn=Manager,dc=example,dc=com" write
+  by self write
+  by * read
+
 #######################################################################
 # ldbm and/or bdb database definitions
 #######################################################################

 database       bdb
-suffix         "dc=my-domain,dc=com"
+suffix         "dc=example,dc=com"
 checkpoint     1024 15
-rootdn         "cn=Manager,dc=my-domain,dc=com"
+rootdn         "cn=Manager,dc=example,dc=com"
+rootpw         {SSHA}Z42Qdb/r/YAw0QRD8vI/SYcLgoxtzF4l
 # Cleartext passwords, especially for the rootdn, should
 # be avoided.  See slappasswd(8) and slapd.conf(5) for details.
 # Use of strong authentication encouraged.

起動します。今回はテストですので、インデックスも BDB の設定も、そのまま放置します。実運用では、パフォーマンスやバックアップにも気をつかってあげてください。


[root@dirserv ~]# service slapd start
slapd を起動中:                                            [  OK  ]

以下は任意ですが、サーバの挙動が分かりやすいように、ログの出力も設定しておきます。slapd は local4 のファシリティで syslog 出力をするのですが、せっかくの RHEL6 系の rsyslog ですので、アプリケーション名 ("slapd") でログを振り分けるようにしてみます。実運用では、ログが溢れないように、ローテートの設定もしておいてください。


[root@dirserv ~]# cp /etc/rsyslog.conf /etc/rsyslog.conf.orig
[root@dirserv ~]# vi /etc/rsyslog.conf
[root@dirserv ~]# diff -uNr /etc/rsyslog.conf.orig /etc/rsyslog.conf
--- /etc/rsyslog.conf.orig
+++ /etc/rsyslog.conf
@@ -76,3 +76,6 @@
 # remote host is: name/ip:port, e.g. 192.168.0.1:514, port optional
 #*.* @@remote-host:514
 # ### end of the forwarding rule ###
+
+!slapd
+*.* /var/log/slapd.log
[root@dirserv ~]# service rsyslog reload
Reloading system logger...                                 [  OK  ]

アクセスできるかどうか、試してみます。


[root@dirserv ~]# ldapsearch -x -D "cn=Manager,dc=example,dc=com" \
 -b "dc=example,dc=com" -w secret2
# extended LDIF
#
# LDAPv3
# base  with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

# search result
search: 2
result: 32 No such object

# numResponses: 1

良いようであれば、認証用のデータを入れて行きます。根元から作って行きます。


[root@dirserv ~]# ldapadd -x -D "cn=Manager,dc=example,dc=com" \
 -w secret2 <<EOF
dn: dc=example,dc=com
dc: example
objectClass: dcObject
objectClass: organization
o: Example Corp.

dn: cn=Manager,dc=example,dc=com
cn: Manager
objectClass: organizationalRole

dn: o=Users,dc=example,dc=com
o: Linux Users
objectClass: organization

dn: ou=People,o=Users,dc=example,dc=com
ou: People
objectClass: organizationalUnit

dn: ou=Group,o=Users,dc=example,dc=com
ou: Group
objectClass: organizationalUnit
EOF
adding new entry "dc=example,dc=com"

adding new entry "cn=Manager,dc=example,dc=com"

adding new entry "o=Users,dc=example,dc=com"

adding new entry "ou=People,o=Users,dc=example,dc=com"

adding new entry "ou=Group,o=Users,dc=example,dc=com"

ちょっと間違うと、途中まで作ったところでエラーになり、そこまでの分が半端に残ります。failure atomic ではありません…、トランザクションがあればいいのにね。今回はテストですので、そんな時は、以下のように根元からガバッと再帰で消してしまってください。


[root@dirserv ~]# ldapdelete -v -x -D "cn=Manager,dc=example,dc=com" \
 -w secret2 -r "dc=example,dc=com"

ユーザ (foo と bar) を追加します。OpenLDAP のクライアント側 (SSSD, pam_ldap, nss-pam-ldapd 等) は、文書にはあまりキチンと書かれていないのですが (せいぜい /usr/share/doc/nss-pam-ldapd-0.7.5/README くらいか)、デフォルトで、クラス "posixAccount" や "posixShadow" を持つノードを、ユーザ情報として取りにきます。ですので、実はツリー構造は割と恣意的に決めてしまっても問題ありません。


[root@dirserv ~]# pass=$(slappasswd -s secret3)
[root@dirserv ~]# ldapadd -x -D "cn=Manager,dc=example,dc=com" \
 -w secret2 <<EOF
dn: uid=foo,ou=People,o=Users,dc=example,dc=com
objectClass: top
objectClass: posixAccount
objectClass: account
gecos: ldap system users
cn: foo
uid: foo
uidNumber: 1000
gidNumber: 1000
homeDirectory: /home/foo
loginShell: /bin/bash
userPassword: $pass
EOF
adding new entry "uid=foo,ou=People,o=Users,dc=example,dc=com"

[root@dirserv ~]# pass=$(slappasswd -s secret4)
[root@dirserv ~]# ldapadd -x -D "cn=Manager,dc=example,dc=com" \
 -w secret2 <<EOF
dn: uid=bar,ou=People,o=Users,dc=example,dc=com
objectClass: top
objectClass: posixAccount
objectClass: account
gecos: ldap system users
cn: bar
uid: bar
uidNumber: 1001
gidNumber: 1001
homeDirectory: /home/bar
loginShell: /bin/bash
userPassword: $pass
EOF
adding new entry "uid=bar,ou=People,o=Users,dc=example,dc=com"

グループ (foo と bar) を追加します。こちらも同様に、クライアントはデフォルトで、クラス "posixGroup" を持つノードを探索に来ます。今回は、昨今の Linux ディストリビューションの構成と同様に、UPG (User Private Group) 式で、ユーザごとに個別に同名のグループを割り当てますが、LDAP 的には、共通のグループを割り当てる方が一般的かも知れません。


[root@dirserv ~]# ldapadd -x -D "cn=Manager,dc=example,dc=com" \
 -w secret2 <<EOF
dn: cn=foo,ou=Group,o=Users,dc=example,dc=com
cn: foo
objectClass: posixGroup
gidNumber: 1000
userPassword: {CRYPT}x
EOF
adding new entry "cn=foo,ou=Group,o=Users,dc=example,dc=com"

[root@dirserv ~]# ldapadd -x -D "cn=Manager,dc=example,dc=com" \
 -w secret2 <<EOF
dn: cn=bar,ou=Group,o=Users,dc=example,dc=com
cn: bar
objectClass: posixGroup
gidNumber: 1001
userPassword: {CRYPT}x
EOF
adding new entry "cn=bar,ou=Group,o=Users,dc=example,dc=com"

一般ユーザから、他人のパスワードが見えないことを確認しておきます。


[root@dirserv ~]# ldapsearch -x \
 -D "uid=foo,ou=People,o=Users,dc=example,dc=com" \
 -b "dc=example,dc=com" -w secret3 "(objectClass=posixAccount)"
[root@dirserv ~]# ldapsearch -x \
 -D "uid=bar,ou=People,o=Users,dc=example,dc=com" \
 -b "dc=example,dc=com" -w secret4 "(objectClass=posixAccount)"

認証依頼元の Linux ホストの設定

こちらも同様に、SELinux と iptables の無効化です。実運用のサー (以下テンプレ略)。


[root@linhost ~]# setenforce permissive
[root@linhost ~]# getenforce
Permissive
[root@linhost ~]# service iptables stop
iptables: ファイアウォールルールを消去中:                  [  OK  ]
iptables: チェインをポリシー ACCEPT へ設定中filter         [  OK  ]
iptables: モジュールを取り外し中:                          [  OK  ]
[root@linhost ~]#

RHEL5 系の nss_ldap から、RHEL6 系では PAM は pam_ldap に、NSS は nss_ldap からフォークした nss-pam-ldapd へと分離しており、また、それらを束ねる SSSD 抽象化レイヤ (詳細) が入っていたりと、設定ファイルが多岐に渡り、もはや手作業では手に負えなくなっているので、authconfig コマンドを使用します。

同時に、TLS (389 番ポートでの "STARTTLS" による接続) も設定します。authconfig では、認証局ナシでの TLS 設定ができないので、設定をした後で、ちょっとだけ手を入れる必要があります。

SSSD を用いる手順:


[root@linhost ~]# authconfig --disableforcelegacy --enablemkhomedir \
 --enableldap --enableldapauth --enableldaptls \
 --ldapserver=dirserv.vnat --ldapbasedn="dc=example,dc=com" \
 --update
sssd を起動中:                                             [  OK  ]
oddjobd を起動中:                                          [  OK  ]
[root@linhost ~]# cat <<EOF >> /etc/sssd/sssd.conf
ldap_tls_reqcert = never
EOF
[root@linhost ~]# cat <<EOF >> /etc/nslcd.conf
tls_cacertfile /etc/pki/tls/certs/ca-bundle.crt
tls_checkpeer no
EOF
[root@linhost ~]# service sssd restart
sssd を停止中:                                             [  OK  ]
sssd を起動中:                                             [  OK  ]

旧来の (legacy な) 手順:


[root@linhost ~]# authconfig --enableforcelegacy --enablemkhomedir \
 --enableldap --enableldapauth --enableldaptls \
 --ldapserver=dirserv.vnat --ldapbasedn="dc=example,dc=com" \
 --update
nslcd を起動中:                                            [  OK  ]
oddjobd を起動中:                                          [  OK  ]
[root@linhost ~]# cat <<EOF >> /etc/nslcd.conf
tls_cacertfile /etc/pki/tls/certs/ca-bundle.crt
tls_reqcert no
EOF
[root@linhost ~]# service nslcd restart
nslcd を停止中:                                            [  OK  ]
nslcd を起動中:                                            [  OK  ]
[root@linhost ~]# cat <<EOF >> /etc/pam_ldap.conf
tls_cacertfile /etc/pki/tls/certs/ca-bundle.crt
tls_checkpeer no
EOF

では、動作を確認してみます。


[root@linhost ~]# id foo
uid=1000(foo) gid=1000(foo) 所属グループ=1000(foo)
[root@linhost ~]# su - foo
Creating home directory for foo.
[foo@linhost ~]$ su - bar
パスワード: secret4
Creating home directory for bar.
[bar@linhost ~]$ id
uid=1001(bar) gid=1001(bar) 所属グループ=1001(bar) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
[bar@linhost ~]$

良いようです。

SSH キー配布の設定

ディレクトリサーバに、SSH のキーを保持する LDAP スキーマが必要なので、oepnssh-ldap をインストールします。


[root@dirserv ~]# yum install -y openssh-ldap

slapd の設定を修正し、スキーマを追加します。キーへのアクセス権限の設定も追加しておきます。


[root@dirserv ~]# cp /etc/openldap/slapd.conf \
 /etc/openldap/slapd.conf.orig
[root@dirserv ~]# vi /etc/openldap/slapd.conf
[root@dirserv ~]# diff -uNr /etc/openldap/slapd.conf.orig \
 /etc/openldap/slapd.conf
--- /etc/openldap/slapd.conf.orig
+++ /etc/openldap/slapd.conf
@@ -15,6 +15,7 @@
 include                /etc/openldap/schema/openldap.schema
 include                /etc/openldap/schema/ppolicy.schema
 include                /etc/openldap/schema/collective.schema
+include                /usr/share/doc/openssh-ldap-5.3p1/openssh-lpk-openldap.schema

 # Allow LDAPv2 client connections.  This is NOT the default.
 allow bind_v2
@@ -101,6 +102,11 @@
   by anonymous auth
   by * none

+access to attrs=sshPublicKey
+  by dn="cn=Manager,dc=example,dc=com" write
+  by self write
+  by * none
+
 access to *
   by dn.exact="cn=Manager,dc=example,dc=com" write
   by self write
[root@dirserv ~]# service slapd restart
slapd を停止中:                                            [  OK  ]
slapd を起動中:

ここでキーを作成し、登録します。


[root@dirserv ~]# ssh-keygen -f ~/.ssh/id_rsa -N ""
Generating public/private rsa key pair.
Your identification has been saved in /root/.ssh/id_rsa.
Your public key has been saved in /root/.ssh/id_rsa.pub.
The key fingerprint is:
(中略)
[root@dirserv ~]# key=$(cat ~/.ssh/id_rsa.pub)
[root@dirserv ~]# ldapmodify -x -D "cn=Manager,dc=example,dc=com" \
 -w secret2 <<EOF
dn: uid=foo,ou=People,o=Users,dc=example,dc=com
changetype: modify
add: objectClass
objectClass: ldapPublicKey
-
add: sshPublicKey
sshPublicKey: $key
EOF

以上で、LDAP サーバ側は終了です。

sshd サーバの設定

sshd サーバが LDAP サーバから、対象ユーザの公開鍵を取得できるように設定します。まずは、sshd の外部プログラムを追加でインストールします。


[root@linhost ~]# yum install -y openssh-ldap

sshd が、外部プログラムからキーを取得するように設定します。上記パッケージに含まれる HOWTO.ldap-keys では "AuthorizedKeysCommand" のパラメータをダブルクォートでくくっていますが、そのように記述すると、パーサはこれを処理しないため、動きません。クォートせずに、"/" で始まる絶対パスを指定してください。なお、stat(2) でファイルの有無を確認しているので、行末にスペース等が入っていると、これまた動きません。総じて不親切です。あまり使われていないのか。


[root@linhost ~]# cp /etc/ssh/sshd_config /etc/ssh/sshd_config.orig
[root@linhost ~]# vi /etc/ssh/sshd_config
[root@linhost ~]# diff -uNr \
 /etc/ssh/sshd_config.orig \
 /etc/ssh/sshd_config
--- /etc/ssh/sshd_config.orig
+++ /etc/ssh/sshd_config
@@ -45,10 +45,10 @@
 #MaxSessions 10

 #RSAAuthentication yes
-#PubkeyAuthentication yes
+PubkeyAuthentication yes
 #AuthorizedKeysFile    .ssh/authorized_keys
-#AuthorizedKeysCommand none
-#AuthorizedKeysCommandRunAs nobody
+AuthorizedKeysCommand /usr/libexec/openssh/ssh-ldap-wrapper
+AuthorizedKeysCommandRunAs root

 # For this to work you will also need host keys in /etc/ssh/ssh_known_hosts
 #RhostsRSAAuthentication no

上記の外部プログラムが利用する設定を記述します。パスワードを含むので、パーミッションに注意してください。設定後、"/usr/libexec/openssh/ssh-ldap-wrapper foo" のように実行してキーが返って来ないようであれば、設定をしくじっています。(※注意: openssh-ldap-5.3p1-52 の ssh-ldap-wrapper には、設定ファイルのパーサにバグがあり、"tls_checkpeer" の設定が効きません。直すか、ちゃんとした証明書を用意するか、TLS をオフにするしかないようです。下記では、オフにしています)

# TLS が使えなくとも、公開鍵ならば平文で飛んでも問題ありませんから、なまじ rootdn のパスワードを指定するよりも、anonymous でキーを取得できるようにした方が良いかも知れません


[root@linhost ~]# cat > /etc/ssh/ldap.conf <<EOF
uri ldap://dirserv.vnat/
base dc=example,dc=com
binddn cn=Manager,dc=example,dc=com
bindpw secret2
host dirserv.vnat

ssl no
#ssl start_tls
tls_cacertdir /etc/openldap/cacerts
tls_cacertfile /etc/pki/tls/certs/ca-bundle.crt
tls_checkpeer no
EOF
[root@linhost ~]# chmod 600 /etc/ssh/ldap.conf

sshd を再起動します。


[root@linhost ~]# service sshd restart
sshd を停止中:                                             [  OK  ]
sshd を起動中:                                             [  OK  ]

以上です。試しに、~/.ssh/id_rsa.pub を持っているホストからログインしてみます。


[root@dirserv etc]# ssh -o RSAAuthentication=yes \
 -o PasswordAuthentication=no -l foo linhost.vnat
Last login: Thu Dec XX 15:54:49 2011 from dirserv.vnat
[foo@linhost ~]$

良いようですね。では。

prelink されたバイナリの "rpm -V" での検証は無問題

2011-12-09T12:00:00.000+09:00

寒くなってまいりましたが、いかがお過ごしでしょうか。お疲れ様です、サイオス那賀です。

今どきの Red Hat 系のシステムでは、デフォルトで prelink が有効になっているんですね。下記のように、cron から起動されています。


$ ls /etc/cron.daily/prelink
/etc/cron.daily/prelink*
$ grep PRELINKING /etc/sysconfig/prelink
PRELINKING=yes

定期的に prelink をしなおしているので、バイナリが書き換わっています。"libxml2" の持つ "/usr/lib64/libxml2.so.2.6.26" を見てみます。下記は、RPM のシステムが保持している MD5 値です。


$ pkg=libxml2
$ file=/usr/lib64/libxml2.so.2.6.26
$ rpm -q --dump $pkg | grep ^$file | cut -d' ' -f1,4
/usr/lib64/libxml2.so.2.6.26 0cb304449951396925c1ad4e84930a22

ファイルから直接に MD5 値を取得すると、当然 prelink が書きかえた分だけ違います。


$ md5sum $file
1dd15c495edb654f0a55c366bf39bdf7  /usr/lib64/libxml2.so.2.6.26

ところが、"rpm -V" で verify しても、何も言われないんですよね。


$ rpm -V libxml2

なぜだろうかと思ったのですが、ミソは、以下のファイルでした。


$ rpm -qf /etc/rpm/macros.prelink
prelink-0.4.0-2.el5
$ cat /etc/rpm/macros.prelink
# rpm-4.1 verifies prelinked libraries using a prelink undo helper.
#       Note: The 2nd token is used as argv[0] and "library" is a
#       placeholder that will be deleted and replaced with the appropriate
#       library file path.
%__prelink_undo_cmd     /usr/sbin/prelink prelink -y library

"rpm -V" の verify をする際に RPM は、上記マクロのコマンドを内部で呼んで、prelink による改変前のバイナリのダイジェスト値で比較して、それ以外の改変の有無を判断しています。手実行して、RPM が内部で保持している MD5 値と一致することを確認してみます。


$ prelink --verify --md5 $file
0cb304449951396925c1ad4e84930a22  /usr/lib64/libxml2.so.2.6.26

OK でした。なお、prelink の処理は可逆です。元に戻すための情報は、ELF のバイナリファイルに追加されるセクション ".gnu.prelink_undo" 内に保持されています。


$ readelf --section-headers $file | grep --after-context=1 prelink
  [27] .gnu.prelink_undo PROGBITS         0000000000000000  0013baf0
       0000000000000798  0000000000000001           0     0     8

元に戻してみます。


$ sudo prelink --undo $file
$ md5sum $file
0cb304449951396925c1ad4e84930a22  /usr/lib64/libxml2.so.2.6.26

今度は、直接 MD5 値を取っても、RPM の内部値と一致しています。

処理まで追おうとして力つきましたので、今日はこのへんで。では。

追記 (Mon Dec 12 2011)

RHEL6 系からは、ダイジェスト値が SHA1 の 256 ビットに変更されています。


$ pkg=libxml2
$ file=/usr/lib64/libxml2.so.2.6.26
$ rpm -q --dump $pkg | grep ^$file | cut -d' ' -f1,4
/usr/lib64/libxml2.so.2.7.6 2b7ae1cbfd796e3ce32a0a836d801bfcc0feefad284705c572d9bb5528f387af
$ sha256sum $file
292596e8550d3167df658b03578654337c26c99d37fc10beb0771385b33d426e  /usr/lib64/libxml2.so.2.7.6
$ prelink --verify $file | sha256sum
2b7ae1cbfd796e3ce32a0a836d801bfcc0feefad284705c572d9bb5528f387af  -

ダイジェスト値はパッケージを作成した時点で埋めこまれます。rpm-*/build/files.c:genCpioListAndHeader() あたりを見ると分かりますが、%_binary_filedigest_algorithm マクロが得られなければ、デフォルトで MD5 になるようになっていますので、明示的に SHA256 が指定されているはずです。これは、redhat-rpm-config パッケージに含まれる /usr/lib/rpm/redhat/macros で指定されています。


...
# Use SHA-256 for FILEDIGESTS instead of default MD5
%_source_filedigest_algorithm 8
%_binary_filedigest_algorithm 8
...

ソースの入手と再ビルド & デバッグ～ Mac OS X Homebrew 編

2011-12-08T12:28:00.000+09:00

お疲れ様です、サイオス那賀です。

はじめて UNIX OS を買いました、Mac OS X です。そこで、「ソースの入手と再ビルド～ CentOS / Scientific Linux 編」、「ソースの入手と再ビルド～ Ubuntu 編」に続いて、Mac OS X 上での UNIX (POSIX？) 系パッケージの管理について簡単にお話ししようと思います。

Mac OS X 上での後入れの UNIX 系パッケージの管理には、今回 Homebrew を利用することにしました。Homebrew は、BSD 系のシステムで多く用いられているパッケージ管理システムである ports 系の一派であり、FreeBSD Ports, Gentoo Portage, MacPorts (旧 DarwinPorts) などの仲間です。

RPM (Red Hat) 系や deb (Debian) 系のパッケージ管理では一般的に、ディストリビューション開発者の側でビルドされたバイナリパッケージを入手してインストールする方式を採るのに対して、ports 系のパッケージは、ネットワークからソースコードを取得してきて、自分のホスト上で自前でビルドをするという特徴を持ちます (バイナリ配布もできるようにはなっていますけどね)。ターゲット・ホスト上には、インストール可能なパッケージのソースの所在をあらわす URL とビルド手順が書かれたファイルが格納されており、それらに従って、ホスト上で都度コンパイルをしながら、インストールを行います。もちろん、パッケージ管理ツールとしては当然のこととして、パッケージ単位でのインストール、アンインストール、ファイルのリスト管理、依存関係の解決などの機能を備えています。

ports 系のメリットとしては、OS や CPU フィーチャごとに最高の最適化がかけられる、やっていることが分かりやすい、などが挙げられる反面、環境ごとにバイナリが異なるのでサポートがしづらい、ネットワーク環境が必須、ビルドにマシンパワーと長い時間を要する、依存される度合いの大きいライブラリの API が更新されると大変、使っているだけで変態扱いされる、等のデメリットもあります。「貴重な一台をマルチユースで大事に使う」という旧来型のコンピューティング・シーンにおいては快適ですが、昨今の、安価なサーバを次から次に使い捨て、クラウドでガンガンとスケールするような使い方とは、相性が悪いのではないかなぁと思います。

さて、私の Mac の使い方は、当然前者の「貴重な一台をマルチユースで大事に使う」スタイルですので、ジャンジャン Homebrew を活用しましょう。従来 Mac OS X 環境で広く用いられてきた MacPorts が、すでに OS X の標準アプリケーションとして /bin/, /sbin/, /usr/bin/ 等にインストールされているソフトウェアも、重複して MacPorts の管理下でインストールしなければならず、無用に CPU パワーと初期導入時間を要し、別バージョンの多重管理に起因する問題を起こしたりしていたのに対して、Homebrew では、重複しないものだけを、/usr/local/ の下で完結して管理するところに、非常に好感が持てます。

では、ソースの入手とビルド手順を解説して行きましょう…かと思ったのですが、正直なところ「Formula Cookbook - GitHub」を読んで /usr/local/Library/Formula/ 以下の formula ファイルを眺めれば、Homebrew がやっていることについては誰にでも分かると思いますので、そちらに譲ります。

では。

…と、それだけでは何なので、フルにデバッグ情報を積んで、ソースレベル・デバッグが可能な状態でのインストール方法でも紹介しようと思います。

/usr/local/Library/Homebrew/formula.rb:Formula#mktemp() におけるビルドディレクトリの処理を見ると、インストール終了後は "ensure" で、何が何でもビルドツリーを消しに行きますので、ソースファイルとオブジェクトファイルを消さずに残すことができません。private だし。


private
  def mktemp
    tmp_prefix = ENV['HOMEBREW_TEMP'] || '/tmp'
    tmp=Pathname.new `/usr/bin/mktemp -d #{tmp_prefix}/homebrew-#{name}-#{version}-XXXX`.strip
    raise "Couldn't create build sandbox" if not tmp.directory? or $? != 0
    begin
      wd=Dir.pwd
      Dir.chdir tmp
      yield
    ensure
      Dir.chdir wd
      tmp.rmtree
    end
  end

仕方が無いので、Cellar ディレクトリ内で直接ビルドをするよう、Formula ファイルを以下のように修正します。(RPM の debuginfo が、ビルドした場所と違うディレクトリにソースを格納できるのは、debugedit コマンドで、ELF 内の DWARF 情報を直接書き換えという大技を使えるからです。Mac OS X の Mach-O バイナリでは、そもそも DWARF 情報を *.o が持っていて、実行ファイルは、それらへのリンクしか持っていないんですね。それらがすべてフルパスで格納されているので、どうやってソースを移動して良いやらさっぱり分からないので、やめておきます)


$ brew edit wget
$ (cd /usr/local/; git diff Library/Formula/wget.rb)
diff --git a/Library/Formula/wget.rb b/Library/Formula/wget.rb
index 66240e7..26c3328 100644
--- a/Library/Formula/wget.rb
+++ b/Library/Formula/wget.rb
@@ -13,6 +13,8 @@ class Wget < Formula
     [["--enable-iri", "Enable iri support."]]
   end

+  skip_clean :all if ARGV.debug? # strip を抑制します
+
   def install
     args = ["--disable-debug",
             "--prefix=#{prefix}",
@@ -20,6 +22,14 @@ class Wget < Formula

     args << "--disable-iri" unless ARGV.include? "--enable-iri"

+    if ARGV.debug?
+      ENV.Og # 最適化を切ります → "-O0"
+      d = Dir.getwd
+      Dir.chdir ".."
+      mv d, prefix + 'src' # ソースをインストール対象とします
+      Dir.chdir prefix + 'src' # その中でビルドします
+    end
+
     system "./configure", *args
     system "make install"
   end

上記の修正の後、"--debug" オプションをつけてインストールすれば、最適化が無効になり、ソースレベルのデバッグが有効になります。


$ brew install --debug --force wget
$ gdb wget
GNU gdb 6.3.50-20050815 (Apple version gdb-1708) (Thu Nov XX 21:59:02 UTC 2011)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "x86_64-apple-darwin"...
Executing: ~/etc/gdbinit.
Done: ~/etc/gdbinit.
Reading symbols for shared libraries ..... done

(gdb) b main
Breakpoint 1 at 0x10002bef2: file main.c, line 915.
(gdb) run
Starting program: /usr/local/bin/wget
Reading symbols for shared libraries ++++......................... done

Breakpoint 1, main (argc=1, argv=0x7fff5fbff998) at main.c:915
915       bool append_to_log = false;
(gdb) l
910     main (int argc, char **argv)
911     {
912       char **url, **t;
913       int i, ret, longindex;
914       int nurl;
915       bool append_to_log = false;
916
917       total_downloaded_bytes = 0;
918
919       program_name = argv[0];
(gdb)

Formula ファイルは Git で管理されていますので、修正を加えても、コンフリクトしない限りは問題なくアップデートができます。


$ brew update

ところで、Homebrew の用いる用語のアナロジー―homebrew (自家醸造), formula (醸造法), cellar (酒蔵), keg (樽)―等は、とても秀逸だと思います。ではまた。

RHEL6 系での OpenLDAP サーバと PAM 認証

2011-12-07T14:00:00.000+09:00

お世話になっております、SIOS 那賀です。

Scientific Linux 6.1 で OpenLDAP のサーバを立てようとして、はたと止まってしまいました。RHEL5 系まででお馴染みの /etc/openldap/slapd.conf がありません。どうやら RHEL6 からは、以前は slapd.conf に記述していたメタデータも、論理的には DN "cn=config" のノードの下に、物理的には /etc/openldap/slapd.d/ 以下に、LDIF を用いた「dynamic runtime configuration engine」なるデータ構造で格納されるように変更されたようです。それに伴い他のノードと同様、汎用の DIT 操作コマンドを用いて、しかも動的に設定できるようになっています。詳しくは RHEL6 の「移行管理ガイド」の「7.3.1 slapd 設定を変換する」や、本家ドキュメントの「OpenLDAP Software 2.4 Administrator's Guide: Configuring slapd」等を参照してください。

追記 (Mon Dec 12 2011): こちらの記事では slapd.d/ で頑張っていましたが、面倒になってしまい slapd.conf に戻ってしまった記事はこちら→「SIOS OSS Tech: RHEL6.1～系の OpenLDAP (slapd.conf) で SSH 公開鍵配布」。

RHEL6 系の初期 slapd.d/ は何のため？

さて、ここで一旦、少々脇道にそれます。上記のサイトを参照すると、既存の slapd.conf があるならば、slaptest コマンドで変換して slapd.d/ を作れば良いように読めますが、では、新規インストールをした場合にはどうすれば良いのでしょう？アップデートではなく新規で openldap-servers パッケージを入れても、以下のように、ちゃんとデータが構築されているように見えます。


[root@dirserv ~]# find /etc/openldap/slapd.d/
/etc/openldap/slapd.d/
/etc/openldap/slapd.d/cn=config.ldif
/etc/openldap/slapd.d/cn=config
/etc/openldap/slapd.d/cn=config/olcDatabase={-1}frontend.ldif
/etc/openldap/slapd.d/cn=config/olcDatabase={2}monitor.ldif
/etc/openldap/slapd.d/cn=config/olcDatabase={0}config.ldif
/etc/openldap/slapd.d/cn=config/cn=schema
/etc/openldap/slapd.d/cn=config/cn=schema/cn={11}collective.ldif
/etc/openldap/slapd.d/cn=config/cn=schema/cn={10}ppolicy.ldif
/etc/openldap/slapd.d/cn=config/cn=schema/cn={3}duaconf.ldif
/etc/openldap/slapd.d/cn=config/cn=schema/cn={9}openldap.ldif
/etc/openldap/slapd.d/cn=config/cn=schema/cn={0}corba.ldif
/etc/openldap/slapd.d/cn=config/cn=schema/cn={7}misc.ldif
/etc/openldap/slapd.d/cn=config/cn=schema/cn={2}cosine.ldif
/etc/openldap/slapd.d/cn=config/cn=schema/cn={6}java.ldif
/etc/openldap/slapd.d/cn=config/cn=schema/cn={4}dyngroup.ldif
/etc/openldap/slapd.d/cn=config/cn=schema/cn={5}inetorgperson.ldif
/etc/openldap/slapd.d/cn=config/cn=schema/cn={8}nis.ldif
/etc/openldap/slapd.d/cn=config/cn=schema/cn={1}core.ldif
/etc/openldap/slapd.d/cn=config/cn=schema.ldif
/etc/openldap/slapd.d/cn=config/olcDatabase={1}bdb.ldif

しかしこのデータ、アクセスしようにも、rootdn のパスワードが分かりません。RHEL の文書を見ても書かれていないようです。以下のように、ファイルも誰の持ち物でもありません。


[root@dirserv ~]# rpm -qf /etc/openldap/slapd.d/*
file /etc/openldap/slapd.d/cn=config is not owned by any package
file /etc/openldap/slapd.d/cn=config.ldif is not owned by any package

ということは、インストールの際に動的に作成しているのでしょう。%postinstall のスクリプトを見てみます。


[root@dirserv ~]# rpm -q --scripts openldap-servers
(中略。↓ インストール後のスクリプトにおいて、)
postinstall scriptlet (using /bin/sh):
(中略。↓ slapd.d/ ディレクトリが存在しなければ、)
# generate configuration in slapd.d
if ! ls -d /etc/openldap/slapd.d/* &>/dev/null; then
    (中略。↓ slapd.conf.obsolete なるファイルをコピーしてきて、)
    [ $fresh_install -eq 0 ] && \
        cp /usr/share/openldap-servers/slapd.conf.obsolete \
         /etc/openldap/slapd.conf
    (中略。↓ config 用のエントリを加えて、)
    cat >> /etc/openldap/slapd.conf << EOF
database config
rootdn   "cn=admin,cn=config"
#rootpw   secret
EOF
    (中略。slaptest コマンドで slapd.d/ 形式に変換します。)
    slaptest -f /etc/openldap/slapd.conf \
     -F /etc/openldap/slapd.d > /dev/null 2> /dev/null

上記のとおり、「#rootpw secret」となっています。パスワードは未設定です。これではアクセスできませんね。

さらに余談として、Ubuntu でも rootdn のパスワードは設定されていないのですが、かわりに、root ユーザで SASL EXTERNAL 認証でアクセスすると、何でもできるように考慮されています。Ubuntu 10.04 サーバガイドの「OpenLDAP Server」の項などを見ると、SASL EXTERNAL の接続でサクサクと rootpw を設定しているのに、なぜ RHEL で同じことができないのかと思えば、そういうことでした。

debian/slapd.init.ldif:


# Frontend settings
dn: olcDatabase={-1}frontend,cn=config
objectClass: olcDatabaseConfig
objectClass: olcFrontendConfig
olcDatabase: {-1}frontend
(中略)
olcAccess: {0}to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth manage by * break

debian/slapd.install:


debian/slapd.init.ldif usr/share/slapd:

debian/slapd.postinst:


create_new_configuration() {
  (中略)
  init_ldif="/usr/share/slapd/slapd.init.ldif"
  (中略)
  capture_diagnostics slapadd -F "${SLAPD_CONF}" \
   -b "cn=config" -l ${init_ldif} || failed=1

もっとも Ubuntu でも、従来 (2.4.21-0ubuntu5 以前) はこの点が考慮されていなかったらしく、アップデートの際には既存のデータに対して、下記のように sed で内部表現をゴリゴリと書き換えているんですけれどね。

debian/slapd.postinst:


postinst_upgrade_configuration() {
  (中略)
  # Grant manage access to connections made by the root user via
  # SASL EXTERNAL
  if previous_version_older 2.4.21-0ubuntu5 ; then
    if [ -d "$SLAPD_CONF" ]; then
      # Stick the new olcAccess at the begining of the
      # olcAccess list (using an index of 0 *and*
      # adding it as early as possible in the ldif file)
      # to make sure that local root has access to the
      # database no matter what other acls say.
      sed -i 's/^\(olcDatabase: {-1}frontend\)/\0\nolcAccess: {0}to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth manage by * break/' "${SLAPD_CONF}/cn=config/olcDatabase={-1}frontend.ldif"
      sed -i 's/^\(olcDatabase: {0}config\)/\0\nolcAccess: {0}to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth manage by * break/' "${SLAPD_CONF}/cn=config/olcDatabase={0}config.ldif"
    fi
  fi

これ同様に sed で書き換えるなり、以下のように slapd.d/cn=config/olcDatabase={0}config.ldif に "olcRootPW" のエントリをねじ込むなりしてサービスを上げ直せば、パスワードを設定することは可能です。これは、いよいよの「rootdn のパスワード忘れちゃった！」の際にも役に立つでしょう。


[root@dirserv ~]# service slapd stop
Stopping slapd:                                            [  OK  ]
[root@dirserv ~]# slappasswd -s secret1
{SSHA}QVHYz50xBxpbbEa5qO+5cn7jDktBVXr4
[root@dirserv ~]# echo 'olcRootPW:{SSHA}QVHYz50xBxpbbEa5qO+5cn7jDktBVXr4' >> /etc/openldap/slapd.d/cn\=config/olcDatabase\=\{0\}config.ldif
[root@dirserv ~]# service slapd startx
Starting slapd:                                            [  OK  ]
[root@dirserv ~]# ldapsearch -x -D "cn=admin,cn=config" -b "cn=config" -w secret1 "(olcRootDN=*)"
# extended LDIF
#
# LDAPv3
# base <cn=config> with scope subtree
# filter: (olcRootPW=*)
# requesting: ALL
#

# {0}config, config
dn: olcDatabase={0}config,cn=config
objectClass: olcDatabaseConfig
olcDatabase: {0}config
olcAccess: {0}to *  by * none
olcAddContentAcl: TRUE
olcLastMod: TRUE
olcMaxDerefDepth: 15
olcReadOnly: FALSE
olcRootDN: cn=admin,cn=config
olcRootPW: {SSHA}QVHYz50xBxpbbEa5qO+5cn7jDktBVXr4
olcSyncUseSubentry: FALSE
olcMonitoring: FALSE

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1

ではなぜ RHEL6 では、アクセス手段のない slapd.d/ をわざわざ作っているのでしょうか？実は最新の OpenLDAP の slapd でも、slapd.d/ が無いところへユーザが slapd.conf を置けば、従来と同様に slapd は slapd.conf から設定を読み込んでしまうのです (詳しくは openldap-*/servers/slapd/bconfig.c の read_config() 関数を読んでください)。よって、新規の際の slapd.d/ は、従来の slapd.conf 流の設定をあっさりとは使わせないようにするために、教育的見地からダミーとして置かれているものと見て良いでしょう。

さて、以上のようにデフォルトの slapd.d/ が単なるダミーであることが分かりましたし、本家の文書もRed Hat の文書も共に、slapd.d/ 以下を手で編集するのはイカン、お行儀が悪いと言っておりますので、何ら躊躇することなく slapd.d/ 以下を削除して、自前の slapd.conf から slaptest コマンドで slapd.d/ を新規生成することにしましょう。

閑話休題、やっと本題に入ります。

サーバの設定

まずはいつものように、SELinux と iptables の無効化です。実運用のサーバでは、運用ポリシーに従って、それぞれ適切に設定してください。


[root@dirserv ~]# setenforce permissive
[root@dirserv ~]# getenforce
Permissive
[root@dirserv ~]# service iptables stop
iptables: ファイアウォールルールを消去中:                  [  OK  ]
iptables: チェインをポリシー ACCEPT へ設定中filter         [  OK  ]
iptables: モジュールを取り外し中:                          [  OK  ]
[root@dirserv ~]#

サーバと、操作用のクライアントをインストールします。


[root@dirserv ~]# yum install -y openldap-clients openldap-servers

"Obsolete" のファイルを元に、slapd.conf を作成します。


[root@dirserv ~]# slappasswd -s secret2
{SSHA}Z42Qdb/r/YAw0QRD8vI/SYcLgoxtzF4l
[root@dirserv ~]# cp /usr/share/openldap-servers/slapd.conf.obsolete slapd.conf
[root@dirserv ~]# vi slapd.conf
[root@dirserv ~]# diff -uNr /usr/share/openldap-servers/slapd.conf.obsolete slapd.conf
--- /usr/share/openldap-servers/slapd.conf.obsolete
+++ slapd.conf
@@ -64,9 +64,9 @@
 # /etc/pki/tls/certs, running "make slapd.pem", and fixing permissions on
 # slapd.pem so that the ldap user or group can read it.  Your client software
 # may balk at self-signed certificates, however.
-# TLSCACertificateFile /etc/pki/tls/certs/ca-bundle.crt
-# TLSCertificateFile /etc/pki/tls/certs/slapd.pem
-# TLSCertificateKeyFile /etc/pki/tls/certs/slapd.pem
+TLSCACertificateFile /etc/pki/tls/certs/ca-bundle.crt
+TLSCertificateFile /etc/pki/tls/certs/slapd.pem
+TLSCertificateKeyFile /etc/pki/tls/certs/slapd.pem

 # Sample security restrictions
 #      Require integrity protection (prevent hijacking)
@@ -95,14 +95,30 @@
 #
 # rootdn can always read and write EVERYTHING!

+access to attrs=userPassword
+  by dn="cn=Manager,dc=example,dc=com" write
+  by self write
+  by anonymous auth
+  by * none
+
+access to *
+  by dn.exact="cn=Manager,dc=example,dc=com" write
+  by self write
+  by * read
+
 #######################################################################
 # ldbm and/or bdb database definitions
 #######################################################################

+database       config
+rootdn         "cn=admin,cn=config"
+rootpw         {SSHA}QVHYz50xBxpbbEa5qO+5cn7jDktBVXr4
+
 database       bdb
-suffix         "dc=my-domain,dc=com"
+suffix         "dc=example,dc=com"
 checkpoint     1024 15
-rootdn         "cn=Manager,dc=my-domain,dc=com"
+rootdn         "cn=Manager,dc=example,dc=com"
+rootpw         {SSHA}Z42Qdb/r/YAw0QRD8vI/SYcLgoxtzF4l
 # Cleartext passwords, especially for the rootdn, should
 # be avoided.  See slappasswd(8) and slapd.conf(5) for details.
 # Use of strong authentication encouraged.

(動いているようであれば) サービスを停止し、現在のデータを削除してから、新しいデータを作り、再度起動します。今回はテストなので、インデックスも BDB の設定も、そのまま放置します。実運用では、パフォーマンスやバックアップにも気をつかってあげてください。


[root@dirserv ~]# service slapd stop
slapd を停止中:                                            [失敗]
[root@dirserv ~]# rm -fr /etc/openldap/slapd.d/* /var/lib/ldap/*
[root@dirserv ~]# slaptest -f slapd.conf -F /etc/openldap/slapd.d/
bdb_db_open: warning - no DB_CONFIG file found in directory /var/lib/ldap: (2).
Expect poor performance for suffix "dc=example,dc=com".
bdb_db_open: database "dc=example,dc=com": db_open(/var/lib/ldap/id2entry.bdb) failed: No such file or directory (2).
backend_startup_one (type=bdb, suffix="dc=example,dc=com"): bi_db_open failed! (2)
slap_startup failed (test would succeed using the -u switch)
[root@dirserv ~]# chown -R ldap.ldap /etc/openldap/slapd.d/* /var/lib/ldap/*
[root@dirserv ~]# service slapd start
slapd を起動中:                                            [  OK  ]


[root@dirserv ~]# cp /etc/rsyslog.conf /etc/rsyslog.conf.orig
[root@dirserv ~]# vi /etc/rsyslog.conf
[root@dirserv ~]# diff -uNr /etc/rsyslog.conf.orig /etc/rsyslog.conf
--- /etc/rsyslog.conf.orig
+++ /etc/rsyslog.conf
@@ -76,3 +76,6 @@
 # remote host is: name/ip:port, e.g. 192.168.0.1:514, port optional
 #*.* @@remote-host:514
 # ### end of the forwarding rule ###
+
+!slapd
+*.* /var/log/slapd.log
[root@dirserv ~]# service rsyslog reload
Reloading system logger...                                 [  OK  ]

アクセスできるかどうか、試してみます。


[root@dirserv ~]# ldapsearch -x -D "cn=admin,cn=config" -b "cn=config" -w secret1 "(olcRootDN=*)"
[root@dirserv ~]# ldapsearch -x -D "cn=Manager,dc=example,dc=com" -b "dc=example,dc=com" -w secret2

良いようであれば、認証用のデータを入れて行きます。根元から作って行きます。


[root@dirserv ~]# ldapadd -x -D "cn=Manager,dc=example,dc=com" -w secret2 <<EOF
dn: dc=example,dc=com
dc: example
objectClass: dcObject
objectClass: organization
o: Example Corp.

dn: cn=Manager,dc=example,dc=com
cn: Manager
objectClass: organizationalRole

dn: o=Users,dc=example,dc=com
o: Linux Users
objectClass: organization

dn: ou=People,o=Users,dc=example,dc=com
ou: People
objectClass: organizationalUnit

dn: ou=Group,o=Users,dc=example,dc=com
ou: Group
objectClass: organizationalUnit
EOF
adding new entry "dc=example,dc=com"

adding new entry "cn=Manager,dc=example,dc=com"

adding new entry "o=Users,dc=example,dc=com"

adding new entry "ou=People,o=Users,dc=example,dc=com"

adding new entry "ou=Group,o=Users,dc=example,dc=com"


[root@dirserv ~]# ldapdelete -v -x -D "cn=Manager,dc=example,dc=com" -w secret2 -r "dc=example,dc=com"


[root@dirserv ~]# slappasswd -s secret3
{SSHA}LAs1y8ozcRtUNMVZh3Sj+t8Vn/48HJV3
[root@dirserv ~]# ldapadd -x -D "cn=Manager,dc=example,dc=com" -w secret2 <<EOF
dn: uid=foo,ou=People,o=Users,dc=example,dc=com
objectClass: top
objectClass: posixAccount
objectClass: account
gecos: ldap system users
cn: foo
uid: foo
uidNumber: 1000
gidNumber: 1000
homeDirectory: /home/foo
loginShell: /bin/bash
userPassword: {SSHA}LAs1y8ozcRtUNMVZh3Sj+t8Vn/48HJV3
EOF
adding new entry "uid=foo,ou=People,o=Users,dc=example,dc=com"

[root@dirserv ~]# slappasswd -s secret4
{SSHA}8XOqcgEYQjI9vFreV8j6dc6B6Fjovfts
[root@dirserv ~]# ldapadd -x -D "cn=Manager,dc=example,dc=com" -w secret2 <<EOF
dn: uid=bar,ou=People,o=Users,dc=example,dc=com
objectClass: top
objectClass: posixAccount
objectClass: account
gecos: ldap system users
cn: bar
uid: bar
uidNumber: 1001
gidNumber: 1001
homeDirectory: /home/bar
loginShell: /bin/bash
userPassword: {SSHA}8XOqcgEYQjI9vFreV8j6dc6B6Fjovfts
EOF
adding new entry "uid=bar,ou=People,o=Users,dc=example,dc=com"


[root@dirserv ~]# ldapadd -x -D "cn=Manager,dc=example,dc=com" -w secret2 <<EOF
dn: cn=foo,ou=Group,o=Users,dc=example,dc=com
cn: foo
objectClass: posixGroup
gidNumber: 1000
userPassword: {CRYPT}x
EOF
adding new entry "cn=foo,ou=Group,o=Users,dc=example,dc=com"

[root@dirserv ~]# ldapadd -x -D "cn=Manager,dc=example,dc=com" -w secret2 <<EOF
dn: cn=bar,ou=Group,o=Users,dc=example,dc=com
cn: bar
objectClass: posixGroup
gidNumber: 1001
userPassword: {CRYPT}x
EOF
adding new entry "cn=bar,ou=Group,o=Users,dc=example,dc=com"

一般ユーザから、他人のパスワードが見えないことを確認しておきます。


[root@dirserv ~]# ldapsearch -x -D "uid=foo,ou=People,o=Users,dc=example,dc=com" -b "dc=example,dc=com" -w secret3 "(objectClass=posixAccount)"
[root@dirserv ~]# ldapsearch -x -D "uid=bar,ou=People,o=Users,dc=example,dc=com" -b "dc=example,dc=com" -w secret4 "(objectClass=posixAccount)"

認証依頼元の Linux ホストの設定

こちらも同様に、SELinux と iptables の無効化です。実運用のサー (以下テンプレ略)。


[root@linhost ~]# setenforce permissive
[root@linhost ~]# getenforce
Permissive
[root@linhost ~]# service iptables stop
iptables: ファイアウォールルールを消去中:                  [  OK  ]
iptables: チェインをポリシー ACCEPT へ設定中filter         [  OK  ]
iptables: モジュールを取り外し中:                          [  OK  ]
[root@linhost ~]#

SSSD を用いる手順:


[root@linhost ~]# authconfig --disableforcelegacy --enablemkhomedir --enableldap --enableldapauth --enableldaptls --ldapserver=dirserv.vnat --ldapbasedn="dc=example,dc=com" --update
sssd を起動中:                                             [  OK  ]
oddjobd を起動中:                                          [  OK  ]
[root@linhost ~]# cat <<EOF >> /etc/sssd/sssd.conf
ldap_tls_reqcert = never
EOF
[root@linhost ~]# cat <<EOF >> /etc/nslcd.conf
tls_cacertfile /etc/pki/tls/certs/ca-bundle.crt
tls_checkpeer no
EOF
[root@linhost ~]# service sssd restart
sssd を停止中:                                             [  OK  ]
sssd を起動中:                                             [  OK  ]

旧来の (legacy な) 手順:


[root@linhost ~]# authconfig --enableforcelegacy --enablemkhomedir --enableldap --enableldapauth --enableldaptls --ldapserver=dirserv.vnat --ldapbasedn="dc=example,dc=com" --update
nslcd を起動中:                                            [  OK  ]
oddjobd を起動中:                                          [  OK  ]
[root@linhost ~]# cat <<EOF >> /etc/nslcd.conf
tls_cacertfile /etc/pki/tls/certs/ca-bundle.crt
tls_reqcert no
EOF
[root@linhost ~]# service nslcd restart
nslcd を停止中:                                            [  OK  ]
nslcd を起動中:                                            [  OK  ]
[root@linhost ~]# cat <<EOF >> /etc/pam_ldap.conf
tls_cacertfile /etc/pki/tls/certs/ca-bundle.crt
tls_checkpeer no
EOF

では、動作を確認してみます。


[root@linhost ~]# id foo
uid=1000(foo) gid=1000(foo) 所属グループ=1000(foo)
[root@linhost ~]# su - foo
Creating home directory for foo.
[foo@linhost ~]$ su - bar
パスワード: secret4
Creating home directory for bar.
[bar@linhost ~]$ id
uid=1001(bar) gid=1001(bar) 所属グループ=1001(bar) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
[bar@linhost ~]$

良いようですね。では。

debuginfo RPM パッケージで、ソースレベル・デバッグをする

2011-12-06T11:47:00.000+09:00

お元気ですか？あいにく風邪気味の、サイオス那賀です。

最近の RPM ベースの Linux ディストリビューションであれば、バイナリ RPM と共に、debuginfo パッケージが提供されているのが普通だと思います。この debuginfo パッケージをインストールすることで、従来であればバイナリパッケージ作成の際に strip で落とされてしまっていたデバッグ情報やソース情報を別パッケージとして利用することができるようになるため、本体パッケージを肥大化させることなく、本体パッケージのバイナリそのものを用いて、ソースレベルでのデバッグを行うことができます (GDB の分離デバッグ情報についての詳細は「Separate Debug Files - Debugging with GDB」あたりを、RPM のビルド中の処理については /usr/lib/rpm/find-debuginfo.sh の debugedit のあたりを参照してください)。

しかし現在の提供形態だと、いくつか問題があります。

バイナリは "-g -O2" でコンパイルされているので、最適化がかかっており、デバッグがしづらい
自前でパラメータを変えてビルドしたら、既存の debuginfo は使用できない
最新のバイナリのアップデートは公開されているのに、対応する debuginfo が出ていないことがある (特に CentOS)
debuginfo パッケージは大きいので、SRPM ファイルともども、ミラーから削除されがちで入手できなかったりする (特に CentOS)

そこで、自前でパッケージをビルドして、debuginfo を活用する方法をご紹介します。以下は、おそらく RHEL4～の系列では動きますが、それ以外はよく知りません。合わせて以前の記事も参考にしてください → 「SIOS OSS Tech: ソースの入手と再ビルド～ CentOS / Scientific Linux 編」。

まずは、redhat-rpm-config パッケージをインストールします。debuginfo パッケージ生成関連のマクロはこのパッケージに含まれているため、これをインストールしておかないと、RPM パッケージのビルドはできますが、debuginfo パッケージが生成されません。


[root@centos4 ~]# yum install redhat-rpm-config

次にビルドです。"rpmbuild --rebuild <SRPM ファイル>" なり "rpmbuild -ba <SPEC ファイル>" なり (渋いところでは、"rpmbuild -ta <tar.gz ファイル>" なり) でビルドをするところですが、ここで、デバッグ用のオプションを指定することができます。デフォルトは "-g -O2" になっていると思いますが、特にこの "-O2" のおかげでかなり最適化がされてしまい、ソースレベルでのデバッグがしづらくなります。これを "-O0" にして最適化を切ると同時に、"-pg", "-g3" で、付加的なデバッグ情報も付けておきます。

注意: 最適化オプションやコンパイル環境の変更によって、調査するはずだった不具合が解消してしまうことも、よくあります。困ります

以下は、CentOS 4 での例です。ソースの入手からビルド～ソースレベル・デバッグまでを見てみます。


[root@centos4 ~]# wget http://ftp.redhat.com/pub/redhat/linux/enterprise/4/en/os/i386/SRPMS/bash-3.0-19.2.src.rpm
(中略)
[root@centos4 ~]# rpmbuild --rebuild \
 --define="optflags -pg -g3 -O0" bash-3.0-19.2.src.rpm
(中略)
Wrote: /usr/src/redhat/RPMS/i386/bash-3.0-19.2.i386.rpm
Wrote: /usr/src/redhat/RPMS/i386/bash-debuginfo-3.0-19.2.i386.rpm
(中略)
[root@centos4 ~]# rpm -Uvh --force \
 /usr/src/redhat/RPMS/i386/bash-3.0-19.2.i386.rpm \
 /usr/src/redhat/RPMS/i386/bash-debuginfo-3.0-19.2.i386.rpm
(中略)
[root@centos4 ~]# bash -c "while true; do sleep 1; done" &
[1] 32108
[root@centos4 ~]# gdb -p 32108
(中略)
Attaching to process 32108
Reading symbols from /bin/bash...Reading symbols from
 /usr/lib/debug/bin/bash.debug...done.
Using host libthread_db library "/lib/tls/libthread_db.so.1".
done.
Reading symbols from /lib/libtermcap.so.2...done.
Loaded symbols for /lib/libtermcap.so.2
Reading symbols from /lib/libdl.so.2...done.
Loaded symbols for /lib/libdl.so.2
Reading symbols from /lib/tls/libc.so.6...done.
Loaded symbols for /lib/tls/libc.so.6
Reading symbols from /lib/ld-linux.so.2...done.
Loaded symbols for /lib/ld-linux.so.2
0x0027f7a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
(gdb) bt
#0  0x0027f7a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
#1  0x00324533 in __waitpid_nocancel () from /lib/tls/libc.so.6
#2  0x0807d03f in waitchld (wpid=32134, block=1) at jobs.c:2497
#3  0x0807be1d in wait_for (pid=32134) at jobs.c:1904
#4  0x0806b901 in execute_command_internal (command=0x9c73280, asynchronous=0, pipe_in=-1, pipe_out=-1, fds_to_close=0x9c73378) at execute_cmd.c:704
#5  0x0806b279 in execute_command (command=0x9c73280) at execute_cmd.c:351
#6  0x0806e2db in execute_while_or_until (while_command=0x9c732d0, type=0) at execute_cmd.c:2327
#7  0x0806e1ef in execute_while_command (while_command=0x9c732d0) at execute_cmd.c:2273
#8  0x0806ba79 in execute_command_internal (command=0x9c732e0, asynchronous=0, pipe_in=-1, pipe_out=-1, fds_to_close=0x9c732f8) at execute_cmd.c:764
#9  0x080a7187 in parse_and_execute (string=0x9c72d00 "while true; do sleep 1; done", from_file=0x80d9392 "-c", flags=4) at evalstring.c:267
#10 0x0805cb6f in run_one_command (command=0xbff9bc18 "while true; do sleep 1; done") at shell.c:1269
#11 0x0805bd7a in main (argc=3, argv=0xbff378e4, env=0xbff378f4) at shell.c:653
(gdb) frame 11
#11 0x0805bd7a in main (argc=3, argv=0xbff378e4, env=0xbff378f4) at shell.c:653
653           run_one_command (command_execution_string);
(gdb) l
648           if (debugging_mode)
649             start_debugger ();
650
651     #if defined (ONESHOT)
652           executing = 1;
653           run_one_command (command_execution_string);
654           exit_shell (last_command_exit_value);
655     #else /* ONESHOT */
656           with_input_from_string (command_execution_string, "-c");
657           goto read_and_execute;
(gdb) p command_execution_string
$1 = 0xbff9bc18 "while true; do sleep 1; done"

ソースもシンボルも見えています。良いようですね。

では。

話は逸れますが、上記で、上書きでインストールをする際に "rpm" コマンドに "-U" と "--force" を組み合わせています。"--force" は依存を壊しませんので、それほど問題ではありません。一方、"--nodeps" はいけません。RPM の本質は依存関係の解決だと思いますので、それを破壊する "--nodeps" は悪です。"--nodeps" を付けなければならない状況に陥ったら、開発者 or 管理者として負けだと思ってください。

RPM ベースで Puppet を動かしてみる

2011-12-05T16:37:00.000+09:00

どうも、サイオス那賀です。

Puppet は、構内ホストをクロスプラットフォームに集中管理するためのソフトウェアです。ユーザやパッケージの存否、設定等々を、複数のノードに一括して適用することができるようになります。

Scientific Linux 6.1 において、ごく簡単な動作を確認するまでの手順を紹介します。ここでは puppet master 側のホストの FQDN を "master.vnat", puppet 側を "node1.vnat" とします。

まず、固有のパッケージをインストールするところまでは、master, node1 とも共通です。

SELinux は permissive, もしくは disabled にします。現行のパッケージ (puppet-2.6.12-1.el6) では、enforcing だとエラーになります (Bug 726061 – puppetmaster fails on startup due to missing SSL/CA directory)。


[root@master ~]# setenforce permissive
[root@master ~]# getenforce
Permissive

デフォルトのポート番号が分からないので、iptables も、ひとまず切っておきます (8139 かな？何その Realtek の NIC チップみたいな番号は)。


[root@master ~]# service iptables stop

パッケージは EPEL から入れますので、レポジトリ設定を入れておきます。ちなみに EPEL (Extra Packages for Enterprise Linux) とは、Fedora を元にして RHEL が作られる際に取り込まれなかったパッケージ群を、RHEL やその互換ディストリビューションのために有志が提供してくださっているプロジェクトです。


[root@master ~]# rpm -Uvh http://download.fedora.redhat.com/pub/epel/6/x86_64/epel-release-6-5.noarch.rpm

ここから、puppet master と puppet とで、インストールするパッケージが異なってきます。まず、puppet master です。"puppet-server" パッケージをインストールし、puppet master サービスを起動します。


[root@master ~]# yum install -y puppet-server
[root@master ~]# service puppetmaster start

次に puppet の側です。"puppet" パッケージを入れます。


[root@node1 ~]# yum install -y puppet

puppet が puppet master を指すように設定します。この設定ファイルは init のスクリプトに渡すものですので、/etc/sysconfig/ 以下に入っています。


[root@node1 ~]# cp /etc/sysconfig/puppet /etc/sysconfig/puppet.orig
[root@node1 ~]# vi /etc/sysconfig/puppet
[root@node1 ~]# diff -uNr \
 /etc/sysconfig/puppet.orig /etc/sysconfig/puppet
--- /etc/sysconfig/puppet.orig
+++ /etc/sysconfig/puppet
@@ -1,5 +1,5 @@
 # The puppetmaster server
-#PUPPET_SERVER=puppet
+PUPPET_SERVER=master.vnat

 # If you wish to specify the port to connect to do so here
 #PUPPET_PORT=8140

puppet から puppet master への設定変更の確認インターバルが、デフォルトでは 30 分と長いです (実運用としてはむしろ短いのですが)。テスト用に、puppet master への変更が即座に反映されるよう、5 秒を指定します。こちらの設定ファイルは、puppet のプログラム自身が読む方ですので、/etc/puppet/ 以下に入ります。設定ファイルの "main" セクション内に、"runinterval" パラメータを追加します。


[root@node1 ~]# cp \
 /etc/puppet/puppet.conf /etc/puppet/puppet.conf.orig
[root@node1 ~]# vi /etc/puppet/puppet.conf
[root@node1 ~]# diff -uNr \
 /etc/puppet/puppet.conf.orig /etc/puppet/puppet.conf
--- /etc/puppet/puppet.conf.orig
+++ /etc/puppet/puppet.conf
@@ -11,6 +11,8 @@
     # The default value is '$confdir/ssl'.
     ssldir = $vardir/ssl

+    runinterval=5
+
 [agent]
     # The file in which puppetd stores a list of the classes
     # associated with the retrieved configuratiion.  Can be loaded in

puppet サービスを起動します。


[root@node1 ~]# service puppet start

puppet master 側で、puppet からの接続を受け入れてあげます。


[root@master ~]# puppetca --list
  node1.vnat (13:C6:9C:8A:4A:5B:59:2B:EA:61:E0:87:E6:43:96:85)
[root@master ~]# puppetca --sign node1.vnat
notice: Signed certificate request for node1.vnat
notice: Removing file Puppet::SSL::CertificateRequest node1.vnat
 at '/var/lib/puppet/ssl/ca/requests/node1.vnat.pem'

動作を試してみます。デフォルトの puppet manifest ファイルに、ユーザの存在を保証させるリソースを記述します。


[root@master ~]# cat <<EOF > /etc/puppet/manifests/site.pp
user { "hoge":
  ensure     => present,
  uid        => '567',
  gid        => 'wheel',
  shell      => '/bin/sh',
  home       => '/var/hoge/',
  managehome => true,
}
EOF
[root@master ~]# service puppetmaster reload

ユーザ、追加されたかな？


[root@node1 ~]# id hoge
uid=567(hoge) gid=10(wheel) 所属グループ=10(wheel)
[root@node1 ~]# grep hoge /etc/passwd
hoge:x:567:10::/var/hoge/:/bin/sh
[root@node1 ~]# ls -ld /var/hoge/
drwx------. 4 hoge wheel 4096 11月 XX 16:23 2011 /var/hoge/

良いようですね。ではまた。

参考リンク:

# Puppet のヘンテコ設定言語を思うと、Ruby DSL を用いる Chef の方が筋が良さそうだなぁ…

Ruby の「条件式としての範囲式」の正体を探る

2011-12-02T10:28:00.000+09:00

ご苦労様です、サイオス那賀です。

Ruby 言語における「条件式としての範囲式」というやつが、どうも腑に落ちません（「Ruby 1.9.2 リファレンスマニュアル演算子式条件式としての範囲式」）。


> ["foo", "bar", "BEGIN", "hoge", "fuga", "END", "buzz"].select { |w|
    (w === "BEGIN" .. w === "END")? true: false
  }
=> ["BEGIN", "hoge", "fuga", "END"]
>

これはオブジェクトのリテラルではなく、言語仕様としての、何かしらの特殊な「何か」ですよね？その証拠に上記でも、3 項演算子を削って、Ruby が括弧内を条件式と判別できないようにすると、オブジェクトにはなり得ません。


> ["foo", "bar", "BEGIN", "hoge", "fuga", "END", "buzz"].select { |w|
    (w === "BEGIN" .. w === "END")
  }
ArgumentError: bad value for range
>

ということは、ここでループ中にその状態を抱えているのは Ruby のスタック上の「何か」ですよね？なまじ何でもオブジェクトな Ruby なだけに、これも一見 Range のオブジェクトに見えるんですが…。せめて、実装上の正体だけでも見ておこうと思います。

# Ruby でも、遅延評価とか名前渡しとかできるとカッコ良かったんですけどね

Yacc の入力ファイルがあると思います。


$ find . -name "*.y"
./ruby-1.8.7-p299/parse.y

ありました。該当するトークンを探します。


static int
yylex()
{
  ...
  retry:
    switch (c = nextc()) {
      ...
      case '.':
        lex_state = EXPR_BEG;
        if ((c = nextc()) == '.') {
            if ((c = nextc()) == '.') {
                return tDOT3;
            }
            pushback(c);
            return tDOT2;
        }
        ...

static struct {
    ID token;
    const char *name;
} op_tbl[] = {
    {tDOT2,     ".."},
    {tDOT3,     "..."},
    {'+',       "+"},
    ...

"tDOT2" と "tDOT3" が "..", "..." のトークンのようです。どうパースしていますかね？


arg : lhs '=' arg
    ...
    | arg tDOT2 arg
        {
            value_expr($1);
            value_expr($3);
            $$ = NEW_DOT2($1, $3);
            if (nd_type($1) == NODE_LIT && FIXNUM_P($1->nd_lit) &&
                nd_type($3) == NODE_LIT && FIXNUM_P($3->nd_lit)) {
                deferred_nodes = list_append(deferred_nodes, $$);
            }
        }
    ...

NEW_DOT2(), NEW_DOT3() とやらで、パースツリーのノードを作っています。node.h:


#define NEW_DOT2(b,e) NEW_NODE(NODE_DOT2,b,e,0)
#define NEW_DOT3(b,e) NEW_NODE(NODE_DOT3,b,e,0)

ノードの型としては "NODE_DOT2" や "NODE_DOT3" で上がって行くようです。これは Range でも条件範囲式でも同じようですので、上で何らかの置換処理をしているんでしょう。if 式での処理を見てみます。


primary : literal
        | kIF expr_value then
          compstmt
          if_tail
          kEND
            {
                $$ = NEW_IF(cond($2), $4, $5);
                fixpos($$, $2);
                if (cond_negative(&$$->nd_cond)) {
                    NODE *tmp = $$->nd_body;
                    $$->nd_body = $$->nd_else;
                    $$->nd_else = tmp;
                }
            }

式が条件式だった時には、cond() 関数 → cond0() 関数で何かの変換をしているようです。


static NODE*
cond0(node)
    NODE *node;
{
  ...
  switch (nd_type(node)) {
    ...
    case NODE_DOT2:
    case NODE_DOT3:
      node->nd_beg = range_op(node->nd_beg);
      node->nd_end = range_op(node->nd_end);
      if (nd_type(node) == NODE_DOT2) nd_set_type(node,NODE_FLIP2);
      else if (nd_type(node) == NODE_DOT3) nd_set_type(node, NODE_FLIP3);
      node->nd_cnt = local_append(internal_id());
      if (!e_option_supplied()) {
        int b = literal_node(node->nd_beg);
        int e = literal_node(node->nd_end);
        if ((b == 1 && e == 1) || (b + e >= 2 && RTEST(ruby_verbose))) {
          parser_warn(node, "range literal in condition");
        }
      }
      break;
      ...

ありました、条件式に指定された場合には、パースツリーのノード型を変えています。どうやら Ruby の「条件式としての範囲式」は、内部的には、ドットの数によってそれぞれ「flip2」「flip3」と呼ばれているようです。

となれば、処理がされる箇所を探すのは簡単です。eval.c:


static VALUE
rb_eval(self, n)
    VALUE self;
    NODE *n;
{
  ...
  switch (nd_type(node)) {
    ...
    case NODE_FLIP2:          /* like AWK */
      {
        VALUE *flip = rb_svar(node->nd_cnt);
        if (!flip) rb_bug("unexpected local variable");
        if (!RTEST(*flip)) {
          if (RTEST(rb_eval(self, node->nd_beg))) {
            *flip = RTEST(rb_eval(self, node->nd_end))?Qfalse:Qtrue;
            result = Qtrue;
          }
          else {
            result = Qfalse;
          }
        }
        else {
          if (RTEST(rb_eval(self, node->nd_end))) {
            *flip = Qfalse;
          }
          result = Qtrue;
        }
      }
      break;

なるほど、フリップフロップですか。ここでの鍵は rb_svar() でしょうか。


VALUE *
rb_svar(cnt)
    int cnt;
{
    struct RVarmap *vars = ruby_dyna_vars;
    ID id;

    if (!ruby_scope->local_tbl) return NULL;
    if (cnt >= ruby_scope->local_tbl[0]) return NULL;
    id = ruby_scope->local_tbl[cnt+1];
    while (vars) {
        if (vars->id == id) return &vars->val;
        vars = vars->next;
    }
    if (ruby_scope->local_vars == 0) return NULL;
    return &ruby_scope->local_vars[cnt];
}

Ruby のスコープのローカルで、対応する変数の入れモノを返してくれるようです。PUSH_SCOPE() を見ると、ruby_scope はスタックを push するたびに作られているようですので、スレッドごとに独立するんでしょう。


#define PUSH_SCOPE() do {               \
    volatile int _vmode = scope_vmode;  \
    struct SCOPE * volatile _old;       \
    NEWOBJ(_scope, struct SCOPE);       \
    OBJSETUP(_scope, 0, T_SCOPE);       \
    _scope->local_tbl = 0;              \
    _scope->local_vars = 0;             \
    _scope->flags = 0;                  \
    _old = ruby_scope;                  \
    ruby_scope = _scope;                \
    scope_vmode = SCOPE_PUBLIC

というわけで、「条件式としての範囲式」は、内部的には Range 型オブジェクトなどではなく、「flip2」「flip3」と呼ばれる言語仕様であり、状態はローカルのスコープごとに持っているようです。

注意: このアプローチには時に、言語設計者がせっかく隠蔽してくれているものを、実装レベルで見て分かったような気になってしまう罠が隠れています。例えば、Scala の吐いた class ファイルの逆コンパイルをしたところで、実装の理解には役立っても、言語の理解には全く役立たないどころか、むしろ有害だったりします。

では。

PostgreSQL の無限再帰 WITH 句で思うこと

2011-12-01T15:40:00.000+09:00

お世話になっております、サイオス那賀です。

PostgreSQL の再帰 WITH 句で、無限長のフィボナッチ数列を作ってみます。


template1=# WITH RECURSIVE
              f(a, b) AS (VALUES(0, 1) UNION SELECT b, a + b FROM f)
            SELECT a FROM f OFFSET 0 LIMIT 20;
  a
------
    0
    1
    1
    2
    3
    5
    8
   13
   21
   34
   55
   89
  144
  233
  377
  610
  987
 1597
 2584
 4181
(20 rows)

template1=#

この "LIMIT" の用法は、下記の通り可搬性が低いので推奨はできないようですが、ちょっと面白いので。

これが動作するのは、PostgreSQLの実装が、実際に親問い合わせで取り出されるのと同じ数のWITH問い合わせの行のみを評価するからです。この秘訣を実稼動環境で使用することは勧められません。他のシステムでは異なった動作をする可能性があるからです。（「WITH問い合わせ（共通テーブル式）」 - PostgreSQL 文書）

「必要な部分しか持ってこないので、データ元が無限でも OK」というところが、ちょっと Haskell 等の遅延評価型言語における無限長リストを思い起こさせます。

無限長のフィボナッチ数列。


module Fib where
  f = 0:1:zipWith (+) f (tail f)

その頭 20 個を取得。


*Fib> take 20 f
[0,1,1,2,3,5,8,13,21,34,55,89,144,233,377,610,987,1597,2584,4181]
*Fib>

RDBMS で、複雑な結合の実行計画を賢く最適化して、実際に必要なデータだけをストレージからフェッチしてくれる機能というのは、どこか遅延評価の考え方に似ているように思われます。


CREATE TABLE foo (k integer PRIMARY KEY, v text);
TRUNCATE TABLE foo;
INSERT INTO foo VALUES(1, '1st foo');
INSERT INTO foo VALUES(2, '2nd foo');
INSERT INTO foo VALUES(3, '3rd foo');
INSERT INTO foo VALUES(5, '5th foo');
INSERT INTO foo VALUES(7, '7th foo');

CREATE TABLE bar (k integer PRIMARY KEY, v text);
TRUNCATE TABLE bar;
INSERT INTO bar VALUES(1, '1st bar');
INSERT INTO bar VALUES(2, '2nd bar');
INSERT INTO bar VALUES(4, '4th bar');
INSERT INTO bar VALUES(6, '6th bar');
INSERT INTO bar VALUES(8, '8th bar');

当たり前ですが、直積をとってから絞り込むような、手続き型処理的なアホなことはしていませんね。


template1=# EXPLAIN SELECT * FROM foo CROSS JOIN bar;
                             QUERY PLAN
--------------------------------------------------------------------
 Nested Loop  (cost=23.53..30303.83 rows=1512900 width=72)
   ->  Seq Scan on foo  (cost=0.00..22.30 rows=1230 width=36)
   ->  Materialize  (cost=23.53..35.83 rows=1230 width=36)
         ->  Seq Scan on bar  (cost=0.00..22.30 rows=1230 width=36)
(4 rows)

template1=# EXPLAIN SELECT * FROM foo CROSS JOIN bar WHERE foo.k = bar.k;
                             QUERY PLAN
--------------------------------------------------------------------
 Merge Join  (cost=170.85..290.46 rows=7564 width=72)
   Merge Cond: (foo.k = bar.k)
   ->  Sort  (cost=85.43..88.50 rows=1230 width=36)
         Sort Key: foo.k
         ->  Seq Scan on foo  (cost=0.00..22.30 rows=1230 width=36)
   ->  Sort  (cost=85.43..88.50 rows=1230 width=36)
         Sort Key: bar.k
         ->  Seq Scan on bar  (cost=0.00..22.30 rows=1230 width=36)
(8 rows)

template1=#

PostgreSQL、賢いですねぇ。実行計画の最適化こそがデータベースの真髄ですな。

ではまた。

RHEL6 系で qemu-kvm バイナリを CPU エミュレーション・モードで使う

2011-11-30T09:57:00.000+09:00

お疲れ様です、サイオス那賀です。突然ですが、今どきの仮想マシンにの実現方法としては、おおざっぱに以下の 3 種類があります。

CPU エミュレーション (インタプリタや、全部バイナリ変換 (Binary Translation)): QEMU, Bochs など。超重いが、他 CPU の命令実行もできて柔軟。実装が大変
トラップ実行 (Trap and Execute。TAE とでも？) + 部分バイナリ変換: (Workstation など、昔ながらの) VMware (実は ESXi でもできるんですが), (昔ながらの) VirtualBox, KQEMU (きわめて残念なことに開発終了) など。ハードウェア支援が不要。CPU 命令をネイティブで走らせるので、そこそこ速い。実装が大変
ハードウェア支援仮想化 (Hardware-Assisted Virtualization, HAV): QEMU virtualizer (QEMU-KVM), Xen-HVM, HAV モードの VMware (ESXi とか), HAV モードの VirtualBox など。intel VT-x や AMD-V が必要。速い、と言われている。実装が（比較的に）簡単

# 何かと面倒な準仮想化 (Para-virtualization, PV) や、OS 仮想化のコンテナ方式については脇に置きます

一般に、前者ほど遅くて後者ほど速いです（初期の VT-x は root, non-root 移行のコストが高くて、むしろ TAE の方が速かったりもしたらしいですが）。最近の実用環境では HAV が主流なのですが、HAV 方式の欠点として、VM 環境上では VM が動かせないことがあります。

# AMD-V だと、VM のスタックができるというウワサを聞きましたが、よく知りません →「Running OpenStack under VirtualBox « System Administration and Architecture Blog」

何がしたいかと言うと、Eucalyptus や OpenStack のような IaaS プラットフォームをお手軽にテストしたいのですが、実マシンをそうそうゴロゴロと用意できない時に、VM 上でテストをできるようにしたいのです。しかし、それらのプロットフォームは、最近の流行からして、開発のプライマリに据えているハイパーバイザが KVM なのです。

これらは、実装的には libvirt 配下で VM ハイパーバイザを動かすようになっているので、理屈上は Xen や VirtualBox でも動きそうなものですが、KVM が開発のプライマリなので、何かと動きません。そもそも、RHEL6 だと Xen の Dom0 も動きませんし、RHEL5 だと Python その他が古すぎて IaaS プラットフォームが動かなかったりもします。

そこで、KVM も動作には QEMU-KVM を使っているので、かわりに QEMU を使うと結構動きます。しかし残念なことに、以前はあった KQEMU による TAE 方式は開発が止まってしまったので、泣く泣く QEMU の CPU エミュレーションモードを使います。

RHEL6 に入っている "qemu-kvm" というコマンドは、実態としては "qemu-system-x86_64" であり、ビルド時に名前を変えているだけです。このバイナリは、KVM のオプションをつければ KVM を利用した HAV 方式で動きますが、KVM を切っておけば、CPU エミュレーションでも動きます。KVM virtualizer 推しのために、emulator をわざと使えなくしているようです。

libvirt-0.8.7/src/qemu/qemu_capabilities.c:


static int
qemuCapsInitGuest(virCapsPtr caps,
                  virCapsPtr old_caps,
                  const char *hostmachine,
                  const struct qemu_arch_info *info,
                  int hvm)
{
  ...
  if (STREQ(info->arch, hostmachine) ||
   (STREQ(hostmachine, "x86_64") && STREQ(info->arch, "i686"))) {
    if (access("/dev/kvm", F_OK) == 0) {
      ...
      const char *const kvmbins[] =
       { "/usr/libexec/qemu-kvm", /* RHEL */
         "qemu-kvm", /* Fedora */
         "kvm" }; /* Upstream .spec */
      ...
    }
    if (access("/dev/kqemu", F_OK) == 0)
      haskqemu = 1;
  }

上記のように、libvirt は、コマンドのパスとモジュールのロード状況に基づいて、その環境上で利用可能なハイパーバイザーを判断しています。よって、RHEL6 でもリンクを張るだけで、libvirt 経由で QEMU のエミュレーションモードが使えるようになります。


# ln -sf /usr/libexec/qemu-kvm /usr/bin/qemu-system-x86_64

これで、VM 上で QEMU の完全仮想化エミュレーションが動くようになります。Virt-Manager 上での表示としては、以下のようになります。

＼	「Hypervisor」	「Architecture」
KVM 有効の virtualizer	「KVM」	「x86_64」
QEMU emulator	「qemu」	「x86_64」

以下は、Windows 版の VMware Workstation 上の Scientific Linux 6 (x64) 上の Virt-Manager 上で Scientific Linux (IA32) を動かした例です。

もちろん、とっても遅いです。しかし、動かないよりはマシですので、テスト用に使っています。

では。

なぜオンライン EXT3 の LVM2 スナップショット & バックアップは問題なく動くのか？

2011-11-29T12:28:00.000+09:00

お疲れ様です、サイオス那賀です。新書本風のタイトルにしてみました。

最初に、私の自宅サーバの、えらく大雑把なバックアップを紹介しようと思います。日に一回、ルート直下のスナップショットを、まるごと別のハードディスクに rsync で増分バックアップしています。システムは以下のようにマウントされています。/ 直下が LVM であり、EXT4 でマウントされています。


$ mount | grep /dev/mapper
/dev/mapper/vg_main-lv_main on / type ext4 (rw,errors=remount-ro)
/dev/mapper/vg_sub-lv_sub on /sub type ext4 (rw)

以下は、1 日 1 回実行されるバックアップスクリプトです。LVM スナップショットをリードオンリーでマウントし、rsync でコピーするだけの簡単なものです。


$ cat /etc/cron.daily/backup-snapshot
#!/bin/sh

mntpnt=/mnt/tmp

# /vm/ は大きいので、日曜日にだけバックアップ
foptvm=
# From Sunday, 0-indexed
test $(date +%w) != 0 && foptvm="$foptvm --exclude /vm/"

mkdir -p /sub/_
lvcreate --size 30G --snapshot --name lv_snap /dev/vg_main/lv_main
mount -o ro /dev/vg_main/lv_snap $mntpnt
if test -d $mntpnt/proc
then
  rsync -avr --delete $foptvm $mntpnt/ /sub/_
fi
umount $mntpnt
lvremove -f /dev/vg_main/lv_snap

当初は、DB ごとに個人データごとにと、個別にバックアップをとっていたのですが、サーバの用途が増えてきたためだんだん面倒くさくなってきてしまい、このような丸ごとバックアップに落ち着きました。問題なく動いていたので、これで正しいのだろうと思っていたのですが、ふとログを見ると、以下のようなメッセージが出ていました。


$ grep EXT4 /var/log/messages
Nov XX 06:25:03 queen kernel: [10216804.075357] EXT4-fs (dm-3): orphan cleanup on readonly fs
Nov XX 06:25:03 queen kernel: [10216804.151685] EXT4-fs (dm-3): 43 orphan inodes deleted
Nov XX 06:25:03 queen kernel: [10216804.151689] EXT4-fs (dm-3): recovery complete
Nov XX 06:25:04 queen kernel: [10216804.249053] EXT4-fs (dm-3): mounted filesystem with ordered data mode. Opts: (null)
Nov YY 06:25:03 queen kernel: [10303060.217676] EXT4-fs (dm-3): orphan cleanup on readonly fs
Nov YY 06:25:03 queen kernel: [10303060.542436] EXT4-fs (dm-3): 45 orphan inodes deleted
Nov YY 06:25:03 queen kernel: [10303060.542441] EXT4-fs (dm-3): recovery complete
Nov YY 06:25:03 queen kernel: [10303060.648882] EXT4-fs (dm-3): mounted filesystem with ordered data mode. Opts: (null)
Nov ZZ 06:25:02 queen kernel: [10389317.017146] EXT4-fs (dm-3): orphan cleanup on readonly fs
Nov ZZ 06:25:02 queen kernel: [10389317.117018] EXT4-fs (dm-3): 45 orphan inodes deleted
Nov ZZ 06:25:02 queen kernel: [10389317.117023] EXT4-fs (dm-3): recovery complete
Nov ZZ 06:25:03 queen kernel: [10389317.215482] EXT4-fs (dm-3): mounted filesystem with ordered data mode. Opts: (null)

特に気になるのが「～ orphan inodes deleted」です。リードオンリーでマウントしているはずなのに、EXT4 のクリーンアップが動いて、ファイルシステムに変更を加えているように見えます。この分だと、ジャーナルのリプレイもしているのではないでしょうか？むしろジャーナルのリプレイができないとなると、マウントしたままの EXT4 のブロックデバイスイメージから取っているスナップショットですので、ファイルシステムには不整合が生じているのでは？そもそも、LVM のスナップショットって書きこめるの？

と、疑問が出てきてしまったので、検証してみました。まずは、「LVM のスナップショットに書き込めるのか？」から。


root@queen:~# lvcreate --size 30G --snapshot --name lv_snap \
 /dev/vg_main/lv_main
  Logical volume "lv_snap" created
root@queen:~# mount -o rw /dev/vg_main/lv_main /mnt/tmp
root@queen:~# ls -l /mnt/tmp/hoge
ls: cannot access /mnt/tmp/hoge: No such file or directory
root@queen:~# echo hoge > /mnt/tmp/hoge
root@queen:~# cat /mnt/tmp/hoge
hoge
root@queen:~# umount /mnt/tmp/
root@queen:~# lvremove -f /dev/vg_main/lv_snap
  Logical volume "lv_snap" successfully removed

余裕で書き込めますね。知らなかった…。「LVM HOWTO」の「Snapshots」の項に、以下のようにあります。

In LVM2, snapshots are read/write by default. Read/write snapshots work like read-only snapshots, with the additional feature that if data is written to the snapshot, that block is marked in the exception table as used, and never gets copied from the original volume.

LVM2 になってからは、スナップショットの差分領域は、スナップショット元からの差分を保持すると同時に、スナップショットへの書き込み差分も保持するようになっているそうです。静的なスナップショットというよりも、動的に書き込める、揮発的なブランチのようなものですね。

さて、LVM スナップショットに書き込めることは分かったので、次は、リードオンリー・マウントでも EXT4 がマウント時にファイルシステムの修復を行うかどうか、です。

余談なのですが、最近の Linux は I/O フリーズの機能を持っています。ファイルシステムを一貫性のある状態に移行させてから一時「凍結」し、バックアップやコピーをとるための機能です。これを使えば、以下のようにきれいなスナップショットがとれます。

ioctl(2) に FIFREEZE で、I/O を止め、一時的にファイルシステムを一貫性のある状態に保つ
LVM でブロックデバイスのスナップショットをとる
FITHAW で、フリーズを解除
スナップショットをマウントし、ゆっくりと rsync ででもコピーをとる
アンマウントして、スナップショットを開放

しかし残念ながら、今の LVM などでは、この機能を使っていません…か？ FIFREEZE 等の呼び出しがないことから、てっきり使っていないと思っていたのですが、RHEL6 などで FIFREEZE/FITHAW の ioctl() を発行するためのコマンド fsfreeze(8) の man を参照すると、以下のように書かれています。

fsfreeze is unnecessary for device-mapper devices. The device-mapper(and LVM) automatically freezes filesystem on the device when a snap-shot creation is requested. For more details see the dmsetup(8) manpage.

LVM2 のコードを見てみると（かなり読みづらいコードなのですが）、lvcreate(8) でスナップショットを作成すると、device mapper の「ブロックデバイスに対して」、DM_DEV_SUSPEND_CMD で ioctl() を呼んでいます (これは、drivers/md/dm-ioctl.c まわりのコードです。対して、ファイルシステムへのコードは linux/fs/ioctl.c:ioctl_fsfreeze() にあり、FIFREEZE での ioctl() が、「ファイルシステム上のノードに対して」発行されます)。とはいえ、結果的には、両者とも同一のスーパーブロックに対して freeze_bdev() を実行することになります。ブロックデバイスのくせして、自分の上に載っているファイルシステムにまで干渉するとは、何だか妙な感じがしますが、理にかなってはいます。

よって、LVM2 でスナップショットを取る前には、一瞬 I/O を停止して、ファイルシステムを整合性を保った状態まで持って行ってからスナップショットを作成しています。

以上でスナップショットについては解決したのですが、では、異常終了時の EXT3 はどうなんでしょう。結論から言うと、「[RFC, PATCH 0/6] ext3: do not modify data on-disk when mounting read-o」や「'Add a norecovery option to ext3/4?' - MARC」を見ると分かるように、実は「-o ro」オプションをつけてマウントしても、EXT3/EXT4 は、可能であれば（デバイスが書き込み可能であれば）ジャーナルのリプレイと orphan inode の切り落としをしてしまいます。ソース中では "really_read_only" のフラグで分岐しています。

linux-2.6.32/fs/ext4/super.c:


static int ext4_load_journal(struct super_block *sb,
                             struct ext4_super_block *es,
                             unsigned long journal_devnum)
{
    ...
    int really_read_only;
    ...
    really_read_only = bdev_read_only(sb->s_bdev);
    ...
    if (EXT4_HAS_INCOMPAT_FEATURE(sb, EXT4_FEATURE_INCOMPAT_RECOVER)) {
        if (sb->s_flags & MS_RDONLY) {
            ext4_msg(sb, KERN_INFO, "INFO: recovery "
                "required on readonly filesystem");
            if (really_read_only) {
                ext4_msg(sb, KERN_ERR, "write access "
                    "unavailable, cannot proceed");
                return -EROFS;
            }
            ext4_msg(sb, KERN_INFO, "write access will "
               "be enabled during recovery");
        }
    }
    ...
}

以上をまとめますと、

LVM2 では、元 LV のダーティバッファはスナップショットにも反映される
LVM2 のスナップショットには、書き込みができる
スナップショットはブロックデバイスでありながら、その上層のファイルシステムと示し合わせて、一貫性のある状態でのスナップショットを取ってくれる
EXT3/EXT4 の "-o ro" マウントは、(journal リプレイと) orphan inode 切り落としをする

以上から、EXT3/EXT4 の、ある瞬間のスナップショットを LVM2 でとって、それをリードオンリーマウントしてコピーをとっても、一貫性の点では問題はないということですね。

やれやれ、ZFS や btrfs のような、シャドウコピーで手軽にファイルシステムレベルでスナップショットを利用できるようになれば、LVM を事前に用意する必要もないので、はるかに話は簡単になるんですが。早くデフォルトにならないかなぁ。

ではまた。

CentOS 6.0 でインストール直後にネットワークを有効にする方法

2011-11-29T12:00:00.000+09:00

サイオステクノロジー金田です。

CentOS 6.0 の GUI インストールで、CentOS 5 系と同じように設定変更せず先に進めると、インストール後のネットワークが有効にならずに困ったことがあります。

インストールしてしまったら、/etc/sysconfig/network-scripts/ifcfg-eth0 を編集するか、GUI のメニュー「システム」→「設定」→「ネットワーク接続」から有効化すればいいのですが、できればインストール時に有効化したいですよね？今回はその方法を紹介します。

CentOS 6.0 のインストール中にホスト名を設定する画面(画像1)が表示されたら「ネットワークの設定」ボタンをクリックします。

画像1 CentOS 6.0 インストール時ホスト名設定画面

実は、CentOS 5 系ではこのタイミングでネットワークが有効になっている(画像2)だけなんですね。

画像2 CentOS 5系のインストール時ホスト名設定画面

話を CentOS 6.0 に戻します。
次に「ネットワーク接続」のウィンドウ(画像3)の「有線」タブで「System eth0」を選択して「編集...」ボタンをクリックします。

画像3 「ネットワーク接続」ウィンドウ

「System eth0 の編集」ウィンドウ(画像4)で「自動接続する」のチェックボックスをチェックすれば、インストール後にネットワークが有効になります。

画像4 「System eth0」ウィンドウ

RHEL6 や Scientific Linux 6 でも同じ方法で変更できます。

PostgreSQL 死活監視のタイムアウト

2011-11-28T14:30:00.000+09:00

お疲れぎみです、サイオス那賀です。

スクリプト等から PostgreSQL のプロセスが正しく動作しているかどうかを監視するための方法としては、pg_ctl コマンドを使ってのチェックと、実際にポートにアクセスしてのチェックがあると思います。

まずはプロセスの確認です。pg_ctl コマンドの "status" サブコマンドで、ローカルで動作している PostgreSQL のプロセスの状態を取ることができます。


$ /usr/local/pgsql/bin/pg_ctl -D ~/pgdata-main/ status
pg_ctl: postmaster is running (PID: 10532)
Command line was:
/usr/lib/postgresql/8.4/bin/postgres "-D" "/home/knaka/pgdata-main"

"-D" オプションで指定したデータディレクトリ下には "postmaster.pid" ファイルがあり、内容は、外部からのコネクションを受け付けている Postmaster プロセスのプロセス番号 (PID) です。この PID に対応するプロセスが動作しているどうかの結果を返します。

このコマンドがブロックしてしまうことはないのでしょうか？少しソースも見てみましょう。Postmaster の死活を見ているのは、下記の部分です。src/bin/pg_ctl/pg_ctl.c です。


static bool
postmaster_is_alive(pid_t pid)
{
  ...
  if (kill(pid, 0) == 0)
    return true;
  ...
}

kill(2) にシグナル番号 0 を投げるというのはどういう意味でしたっけ？ man には以下のようにあります。

If sig is 0, then no signal is sent, but error checking is still per-formed; this can be used to check for the existence of a process ID orprocess group ID.

単にプロセスが存在しているかどうかしか見ていませんが、これがブロックすることはなさそうなので、DB の状態に拠らず安心して呼べますね。しかしこれでは、プロセスはあるけれど実際にはサービスが行われていなかった場合を検出できません。

そこで、ネットワークのポート (TCP/IP なりドメインソケットなりの) に接続して死活監視を行います (パスワードを訊かれないよう、パスワードファイルなりサービスファイルなりは事前に設定しておいてください)。


$ psql -h localhost -p 5433 -U admin template1 -l
                          List of databases
   Name    | Owner | Encoding | Collation | Ctype | Access privileges
-----------+-------+----------+-----------+-------+-------------------
 eucdb     | admin | EUC_JP   | C         | C     |
 main      | admin | UTF8     | C         | C     |
 postgres  | knaka | UTF8     | C         | C     |
 template0 | knaka | UTF8     | C         | C     | =c/knaka
(中略)
$ echo $?
0

# なおここで、"postgres" データベースに接続してチェックするのはやめましょう。世の中には "postgres" データベースを持たない PostgreSQL データベースがあります。"template1" が無いことはありません。

しかしながら、もしポートを開いたまま死んでいる PostgreSQL へ不用意に接続して状態を確認してしまうと、いつまでも待ってしまいます。netcat コマンドで listen ポートを開いて試してみましょう。


$ nc -l 15432
(待ち...)

別のコンソールから。


$ psql -h localhost -p 15432 -U postgres postgres
(待ち...)

はい、返ってきません。もし一定時間ごとに死活監視のコマンドを発行するようにしていたら大変です。プロセスは増え続け、いずれリソースを食い尽くします。

そんな時、たとえば SSH でリモートのコマンドを叩くような状態監視であれば、タイムアウトのパラメータを渡すことで対処します。


$ nc -l 10022

$ ssh -p 10022 localhost

これだと戻りませんが。


$ ssh -o "ConnectTimeout=5" -p 10022 localhost
(5 秒経過…)
Connection timed out during banner exchange
$ echo $?
255
$

"ConnectionTimeout" パラメータを渡すことで、ちゃんとエラーを返すようになりました。

一方、psql コマンドのドキュメントにはそういうオプションが見当たりません。しかし psql コマンドは、実際のデータベースへの接続には libpq ライブラリを用いており、タイムアウトの設定はそちらにあります。libpq が理解する環境変数を見てみますと、"PGCONNECT_TIMEOUT=～" というのがありますね。試してみましょう。


$ PGCONNECT_TIMEOUT=5 psql -h localhost -p 15432 -U postgres postgres
(5 秒経過…)
psql: timeout expired
$ echo $?
2

めでたくタイムアウトし、エラーのリターンコードを返すようになりました。

では

ソースの入手と再ビルド～ Ubuntu 編

2011-11-25T14:00:00.000+09:00

お疲れ様です、サイオス那賀です。

先日のエントリで、RPM 系ディストリビューションにおけるソースの入手とビルド方法には触れましたので、今度は簡単に、Debian 系ということで Ubuntu 上でのビルドをしてみます。なお、私も RPM を主戦場としておりまして、Debian 系の習熟度は普通のシスアド程度なのですが、やはりイザという時にソースの入手やビルド程度できねばなるまいと思いまして、あえてメモ書き程度に記しておきます。

まずは、パッケージビルドをするためのツールを含む "dpkg-dev" をインストールします。そして、後で Bash のビルドを試しますので、依存パッケージをインストールしておきます。


root@queen:~# aptitude install dpkg-dev
root@queen:~# aptitude build-dep bash

以降は一般ユーザで行います。apt-get で source を入手できます。


nonpriv@queen:~$ mkdir -p ~/deb/
nonpriv@queen:~$ cd ~/deb/
nonpriv@queen:~/deb$ apt-get source bash
(中略)
nonpriv@queen:~/deb$ ls -l
total 4016
drwxr-xr-x 3 nonpriv nonpriv    4096 2011-XX-XX 14:36 bash-4.1
-rw-r--r-- 1 nonpriv nonpriv   87125 2010-08-11 05:05 bash_4.1-2ubuntu4.diff.gz
-rw-r--r-- 1 nonpriv nonpriv    1296 2010-08-11 05:05 bash_4.1-2ubuntu4.dsc
-rw-r--r-- 1 nonpriv nonpriv 4013077 2010-01-05 04:10 bash_4.1.orig.tar.gz

RPM のビルドが手続き的なのに対して、ダウンロードしてきた "bash-4.1/" ディレクトリの中を見て分かるとおり、Debian のビルドは、元のビルドシステムを生かしつつ、そこへラッパーを被せているようなノリがあります。うまく言えないけれど、そんな感じです。

ここで deb パッケージを作成するだけであれば、下記で充分です。


nonpriv@queen:~/deb/bash-4.1$ dpkg-buildpackage

右記をひととおり読めば、誰でも deb ソースパッケージの操作、作成はできるようになると思います → 「Debian 新メンテナーガイド」。SPEC ファイル書き方講座の決定版とも言える「Maximum RPM」が 10 年以上もそのままなのに比べると、Debian プロジェクトはきちんとしているなぁと思わざるを得ません。

肥大化した個人利用の Git ワークを縮小する

2011-11-24T11:34:00.000+09:00

お世話になります、サイオス那賀です。

CVS や Subversion 等の集中型バージョン管理と違い、Git のような分散型のバージョン管理では、明確な「ワーク」というものはありません（ワークではないレポジトリはありますが）。そのため、clone された各ワークは、それまでの変更履歴を全て抱えています。多人数での開発であれば、過去の、どの履歴をいつ参照する必要が生じるとも分からないので、ヒストリを勝手に消したら叱られるでしょうが、個人利用では、どう考えても今後必要にならないヒストリは、ディスクの肥やしでしかありません。途中の変更履歴を削除し、ワークのサイズを小さくする方法を把握しておくことは有益かと思います。

# 私的な事情としては、ワークを Dropbox 上に置いて Linux と Windows で共用しているため、無駄に大きくなられると、ネットストレージの容量を圧迫して困るのです

まずは、もしまだ git を使ったことのない環境であれば、コミット時のユーザ名とメールアドレスを設定しておきます。


[nonpriv@sl6kdev ~]$ git config --global user.name "Foo Bar"
[nonpriv@sl6kdev ~]$ git config --global user.email "foobar@example.com"

空のレポジトリを作成します。初期サイズは、100KB ほどのようです。


[nonpriv@sl6kdev ~]$ mkdir ~/repos/
[nonpriv@sl6kdev ~]$ git init --bare ~/repos/
Initialized empty Git repository in /home/nonpriv/repos/.git/
[nonpriv@sl6kdev ~]$ du -hs ~/repos/
100K    /home/nonpriv/repos/

clone でワークを作成します。サイズは 104KB ほどです。


[nonpriv@sl6kdev ~]$ git clone file:///home/nonpriv/repos/ ~/work/
Initialized empty Git repository in /home/nonpriv/work/.git/
warning: You appear to have cloned an empty repository.
[nonpriv@sl6kdev ~]$ cd work/
[nonpriv@sl6kdev work]$ du -hs .
104K    .

ワークにおいて、特に何の変哲もない最初のコミットと、レポジトリへの push を行います。


[nonpriv@sl6kdev work]$ echo first > hoge.txt
[nonpriv@sl6kdev work]$ git add hoge.txt
[nonpriv@sl6kdev work]$ git commit -m "First commit"
[master (root-commit) f3241b3] First commit
 1 files changed, 1 insertions(+), 0 deletions(-)
 create mode 100644 hoge.txt
[nonpriv@sl6kdev work]$ git push origin master
Counting objects: 3, done.
Writing objects: 100% (3/3), 213 bytes, done.
Total 3 (delta 0), reused 0 (delta 0)
Unpacking objects: 100% (3/3), done.
To file:///home/nonpriv/repos/
 * [new branch]      master -> master

次に、うっかり巨大な内容 (10MB ほど) をコミット、push してしまいました。


[nonpriv@sl6kdev work]$ dd if=/dev/urandom of=hoge.txt bs=10M count=1
[nonpriv@sl6kdev work]$ git add hoge.txt
[nonpriv@sl6kdev work]$ git commit -m "Second commit contains big data"
[master cbd23c4] Second commit contains big data
 1 files changed, 0 insertions(+), 0 deletions(-)
[nonpriv@sl6kdev work]$ git push
Counting objects: 5, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 10.00 MiB, done.
Total 3 (delta 0), reused 0 (delta 0)
Unpacking objects: 100% (3/3), done.
To file:///home/nonpriv/repos/
   f3241b3..cbd23c4  master -> master

仕方が無いので、巨大なコミットを消しにかかります。


[nonpriv@sl6kdev work]$ echo third > hoge.txt
[nonpriv@sl6kdev work]$ git add hoge.txt
[nonpriv@sl6kdev work]$ git commit -m "Third commit removes it"
[master 56770a2] Third commit removes it
 1 files changed, 1 insertions(+), 40970 deletions(-)
 rewrite hoge.txt (100%)
[nonpriv@sl6kdev work]$ git push
Counting objects: 5, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (1/1), done.
Writing objects: 100% (3/3), 253 bytes, done.
Total 3 (delta 0), reused 0 (delta 0)
Unpacking objects: 100% (3/3), done.
To file:///home/nonpriv/repos/
   cbd23c4..56770a2  master -> master

ここで CVS や Subversion であれば、ワークのサイズは小さくもなりましょうが、Git ではワークもレポジトリなので、レポジトリ内に過去の履歴が残っており、実サイズは小さくなりません。


[nonpriv@sl6kdev work]$ cd ~
[nonpriv@sl6kdev ~]$ git clone file:///home/nonpriv/repos/ ~/work2/
Initialized empty Git repository in /home/nonpriv/work2/.git/
remote: Counting objects: 9, done.
remote: Compressing objects: 100% (4/4), done.
remote: Total 9 (delta 0), reused 0 (delta 0)
Receiving objects: 100% (9/9), 10.00 MiB, done.
[nonpriv@sl6kdev ~]$ du -hs ~/work2
11M     /home/nonpriv/work2

そこで、rebase コマンドの squash で、ヒストリ上から、大きなコミットを無かったことにします。


[nonpriv@sl6kdev ~]$ cd ~/work/
[nonpriv@sl6kdev work]$ git log
commit 56770a2af0d3a9d636f38993eb12d517bdf9949f
Author: Foo Bar <foobar@example.com>
Date:   XXX Nov XX 11:04:06 2011 +0900

    Third commit removes it

commit cbd23c48a7d24cba52bd1e6ff795ea06f4d7d710
Author: Foo Bar <foobar@example.com>
Date:   XXX Nov XX 11:03:19 2011 +0900

    Second commit contains big data

commit f3241b3584cbd2e9ede54bcb6bd7f8363e7615c3
Author: Foo Bar <foobar@example.com>
Date:   XXX Nov XX 11:02:10 2011 +0900

    First commit
[nonpriv@sl6kdev work]$ git rebase --interactive f3241b3584cbd2e9ede54bcb6bd7f8363e7615c3

巨大な内容を削除するためのコミット (ここでは "Third commit") を squash し、その前の "Second commit" と合わせて 1 つにしてしまいます。これで、論理的には、巨大な内容のコミットは無かった事になります。


pick cbd23c4 Second commit contains big data
squash 56770a2 Third commit removes it

ヒストリを破壊するこの変更は、当然リモートリポジトリに対して全く fast-forward ではないので、"--force" で push します。


[nonpriv@sl6kdev work]$ git log
commit f6ed91fc820e974f1221fe621e34b17fbd6e317d
Author: Foo Bar <foobar@example.com>
Date:   XXX Nov XX 11:03:19 2011 +0900

    Second commit contains big data

    Third commit removes it

commit f3241b3584cbd2e9ede54bcb6bd7f8363e7615c3
Author: Foo Bar <foobar@example.com>
Date:   XXX Nov XX 11:02:10 2011 +0900

    First commit
[nonpriv@sl6kdev work]$ git push --force
Counting objects: 5, done.
Writing objects: 100% (3/3), 278 bytes, done.
Total 3 (delta 0), reused 0 (delta 0)
Unpacking objects: 100% (3/3), done.
To file:///home/nonpriv/repos/
 + 56770a2...f6ed91f master -> master (forced update)

さて、小さくなったでしょうか。


[nonpriv@sl6kdev work]$ cd ~
[nonpriv@sl6kdev ~]$ git clone file:///home/nonpriv/repos/ ~/work3/
Initialized empty Git repository in /home/nonpriv/work3/.git/
remote: Counting objects: 6, done.
remote: Compressing objects: 100% (2/2), done.
remote: Total 6 (delta 0), reused 0 (delta 0)
Receiving objects: 100% (6/6), 459 bytes, done.
[nonpriv@sl6kdev ~]$ du -hs ~/work3/
160K    /home/nonpriv/work3

だいぶ小さくなりました。良いようです。

non-fast-forward を "--force" で push してしまったので、それ以前に clone されていた別のワークは危険です。消しておきましょう。


[nonpriv@sl6kdev ~]$ rm -fr ~/work2/

以上です。

注意: squash した結果を push したレポジトリ (上記の例では ~/repos/) には、実はまだ squash で潰されたはずの内容が残っています。あまり追求していないので、実体として何が残っているのかはよく知りません。


[nonpriv@sl6kdev ~]$ du -hs ~/repos/
11M     /home/nonpriv/repos/

そしてここから clone する際、ローカルパスの URL 形式 ("file://～") ではなくローカルのパスを指定して clone してしまうと、Git はローカルのコピーやハードリンクを用いてワークを作成してしまうため、小さくなりません。


[nonpriv@sl6kdev ~]$ git clone ~/repos/ ~/work4/
Initialized empty Git repository in /home/nonpriv/work4/.git/
[nonpriv@sl6kdev ~]$ du -hs ~/work4/
11M     /home/nonpriv/work4/

レポジトリを clone しなおして、~/repos/ を入れかえておくのも手かと思います。


[nonpriv@sl6kdev ~]$ git clone --mirror file:///home/nonpriv/repos/ ~/repos-new/
Initialized empty Git repository in /home/nonpriv/repos-new/
remote: Counting objects: 6, done.
remote: Compressing objects: 100% (2/2), done.
remote: Total 6 (delta 0), reused 0 (delta 0)
Receiving objects: 100% (6/6), done.
[nonpriv@sl6kdev ~]$ rm -fr ~/repos/
[nonpriv@sl6kdev ~]$ mv ~/repos-new/ ~/repos/

git-clone(1) のヘルプには「ローカルパス指定と file://～とでは、大差ないよ」とか書けれていますが、実のところは違います。特に事情がなければ、常に "file://～" なりネットワーク接続指定なりを用いる方が安全だと思います。ソースで言うと、builtin/clone.c の cmd_clone() における、"clone_local(path, git_dir)" と "transport_get_remote_refs(transport)" との is_local フラグによる分岐を参照してください。

もっとも、ストレージリソースが潤沢にあるならば、どっちでもいいんですけどね。

注意 2: ブランチを切っているようであれば、ワーク側でひととおり checkout しておいてやる必要もあります。参考 → 「Why is my git repository so big? - Stack Overflow」。

では。

RPM 版 Tomcat のマルチインスタンス化

2011-11-22T19:14:00.001+09:00

初めての投稿になります。サイオスの鎌田です。

RHEL6 からは、提供される Tomcat のバージョンが 6.x 系となり、OpenJDK との組み合わせで今後利用が増えてくるのではないでしょうか。社内向けのツールなど、簡単な Web アプリケーションであれば RHEL6 上で動作させ、運用していくことも十分に考えられるかと思います。

しかし、RPM 版 Tomcat を用いる上で、こういった問題を抱えてはいないでしょうか。Web アプリケーション同士の相性により、1つの Tomcat インスタンス上で同時に動作させると問題が生じるため、仕方なくコミュニティ版の Tomcat で環境を構築するといった問題です。代表的な例として、Atlassian 社製のエンタープライズ Wiki アプリケーションである Confluence と、同社の ITS である JIRA は、それぞれを 1つの Tomcat インスタンス上で動作させることはサポート対象外としています。

実は、RPM 版 Tomcat でマルチインスタンス化させることは可能なのです。元々の Tomcat の機能を使うだけなのですが、RPM 版 Tomcat では init スクリプトでマルチインスタンスを管理できるように考慮されて作られています。以下、その手順を述べます。

まず、新しくインスタンスを作るための準備を行います。適当なディレクトリを決め、その下に Tomcat のディレクトリ構造を作るのです。ここでは、CATALINA_BASE と呼びますが、例として /usr/share/sample といったディレクトリを作成することを想定します。


# mkdir -m 775 /usr/share/sample \
    /usr/share/sample/bin \
    /usr/share/sample/conf \
    /usr/share/sample/temp \
    /usr/share/sample/webapps \
    /usr/share/sample/work \
    /var/log/sample

次に、作成したディレクトリの所有者と所有グループを適切に変更します。


# chown root:tomcat /usr/share/sample/bin \
    /usr/share/sample/conf \
    /usr/share/sample/temp \
    /usr/share/sample/webapps \
    /usr/share/sample/work \
    /var/log/sample

次に、Tomcat をマルチインスタンス化させるにあたって、必要なファイルのコピーや、シンボリックリンクを張ります。


# ln -s /usr/share/tomcat6/bin/tomcat-juli.jar /usr/share/sample/bin/tomcat-juli.jar
# cp -p /etc/tomcat6/server.xml /usr/share/sample/conf/
# ln -s /etc/tomcat6/catalina.properties /usr/share/sample/conf/catalina.properties
# ln -s /var/log/sample /usr/share/sample/logs

これで、CATALINA_BASE の準備は終わりました。

次は、新しく作成したインスタンスの設定を適切に変更します。$CATALINA_BASE/conf/server.xml が主に変更する設定となります。マルチインスタンス化するにあたって、デフォルトのシャットダウンポート 8005 番や、AJP ポート 8009 番を他のインスタンスと衝突しないように変更する必要があります。

これで Tomcat の動作に必要な情報は一通り揃っていますが、今度は service コマンドを用いてインスタンスの起動や終了を可能にするため、init スクリプトを用意します。まずは、/etc/sysconfig/tomcat6 を /etc/sysconfig/<service_name> にコピーします。


# cp -p /etc/sysconfig/tomcat6 /etc/sysconfig/sample

コピーした /etc/sysconfig/<service_name> の内容を編集します。編集する箇所は CATALINA_BASE / CATALINA_TMPDIR / CATALINA_PID が該当するかと思います。それぞれ適切なディレクトリと PID ファイルパスを指定してください。

最後に、/etc/init.d/tomcat6 へのシンボリックリンク /etc/init.d/<service_name> を作成し、chkconfig コマンドでサービスを追加します。


# ln -s /etc/init.d/tomcat6 /etc/init.d/sample
# chkconfig --add sample

以上で、すべての準備は整いました。あとは $CATALINA_BASE/webapps/ ディレクトリ配下に WAR ファイル等を配置してサービスを起動したり、終了したりして動作を確認してください。


# service sample start
# service sample stop

PostgreSQL を SNMP で監視する

2011-11-17T10:47:00.000+09:00

お世話になっております、サイオス那賀です。

pgsnmpd は、RFC1697 (RDBMS-MIB) に準拠した、PostgreSQL 用の SNMP エージェントです。CentOS 5 にインストールして試してみます。

まずは、ビルドに必要なパッケージをインストールします。


[root@co5v ~]# yum install -y gcc net-snmp-devel zlib-devel openssl-devel libxslt-devel pam-devel libtermcap-devel

ビルドします。Postgres Plus は、以前の記事で入れた通りです。pg_env.sh で pg_config にパスを通しておかないとビルドができませんので注意してください。


[root@co5v ~]# . /opt/PostgresPlus/9.0SS/pg_env.sh
[root@co5v ~]# tar zxvf pgsnmpd-1.0.tgz
(中略)
[root@co5v ~]# cd pgsnmpd-1.0/
[root@co5v pgsnmpd-1.0]# make
(中略)
[root@co5v pgsnmpd-1.0]#

適当な設定を書いてみます。


[root@co5v pgsnmpd-1.0]# cat test.conf
com2sec readwrite default public
group MyRWGroup v2c readwrite
view all included .1 80
access MyRWGroup "" any noauth exact all all none
agentaddress localhost:10161
[root@co5v pgsnmpd-1.0]#

実行してみます。


[root@co5v pgsnmpd-1.0]# ./pgsnmpd -c test.conf -C "dbname=postgres host=localhost user=postgres password=edb"
Could not set search path because of some problem with the set query
[init_smux] bind failed: Permission denied
PGSQL-SNMP-Ver1.0 is up and running.

net-snmp-utils を入れて、試しに叩いてみます。


[root@co5v ~]# yum install -y net-snmp-utils
(中略)
[root@co5v ~]# snmpwalk -v 2c -c public localhost:10161 mib-2.39
SNMPv2-SMI::mib-2.39.1.1.1.2.1 = OID: SNMPv2-SMI::enterprises.27645.1
SNMPv2-SMI::mib-2.39.1.1.1.2.11866 = OID: SNMPv2-SMI::enterprises.27645.11866
SNMPv2-SMI::mib-2.39.1.1.1.2.11874 = OID: SNMPv2-SMI::enterprises.27645.11874
(中略)
SNMPv2-SMI::mib-2.39.1.9.1.2.11874.1 = Hex-STRING: 07 DB 0A 1F 0F 1E 27 A8 2B 09 00
SNMPv2-SMI::mib-2.39.1.9.1.2.16393.1 = Hex-STRING: 07 DB 0A 1F 0F 1E 27 A8 2B 09 00
SNMPv2-SMI::mib-2.39.1.9.1.2.16393.1 = No more variables left in this MIB View (It is past the end of the MIB tree)
[root@co5v ~]# snmpwalk -v 2c -c public localhost:10161 mib-2.39.1.2.1.2.1
SNMPv2-SMI::mib-2.39.1.2.1.2.1 = STRING: "PostgreSQL 9.0.2 on x86_64-unknown-linux-gnu, compiled by GCC gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-46), 64-bit"
[root@co5v ~]#

正直申し上げると、RDBMS-MIB による監視に馴染みがないので実用的かどうかは分からないのですが、パスワード認証なしでも状態が取れる点にメリットはあるかと思います。

ソースの入手と再ビルド～ CentOS / Scientific Linux 編

2011-11-10T14:26:00.000+09:00

お疲れ様です、サイオス那賀です。

今どき組み込み系でもない限り、ほとんどの Linux ディストリビューションは高度なパッケージ管理機能（メタ・パッケージ管理機能）を備えており、ネットワーク上からパッケージを入手して、依存関係を解決しつつインストールやアップデートをできるようになっています。代表的なツールとしては、Red Hat 系の RPM パッケージ用の up2date, Yum や、Debian 系の deb パッケージに対する apt, Aptitude などであり、みなさんも日常的にご利用だと思います。

しかし残念なことに、せっかくのそれらの機能を、コンパイル済みのバイナリを入手するためにしか使っていない方が多いようです。せっかくのオープンソース OS 環境なのですから、ソースの入手・展開をしての解析、設定を変更しての再構築も容易になっていることを、もっと知ってもらいたいと思います。

まずはパッケージの入手です。yum-utils パッケージに含まれる yum-downloader コマンドを使うと、現在有効になっているレポジトリの "base" 等の名前に後ろに "-source" をつけたレポジトリを一時的に有効にし、ソース・パッケージを入手してきてくれます。


[root@co5v ~]# yum install -y yum-utils
(中略)
[root@co5v ~]#

下記の設定の追加は、CentOS 5 で必要です。Scientific Linux では最初から有効になっています。


[root@co5v ~] cat <<'EOF' > /etc/yum.repos.d/CentOS-Source.repo
[base-source]
name=CentOS-$releasever - Base Source Packages
baseurl=http://mirror.centos.org/centos/$releasever/os/SRPMS/
gpgcheck=1
enabled=0
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-$releasever

[updates-source]
name=CentOS-$releasever - Updates Source Packages
baseurl=http://mirror.centos.org/centos/$releasever/updates/SRPMS/
gpgcheck=1
enabled=0
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-$releasever
EOF
[root@co5v ~]#

以上で行け…るはずだったんですが、あれ？ CentOS 5 で、書き置きの readme 一つを残して、ミラーレポジトリから SRPM が軒並み片付けられてしまっていますね。弱っちゃうな。では指示の通りに、かわりに以下を指定しましょう。バージョン (5.7) を直指定していますので、環境に合わせて変更してください。


[root@co5v ~] cat <<'EOF' > /etc/yum.repos.d/CentOS-Source.repo
[base-source]
name=CentOS-$releasever - Base Source Packages
baseurl=http://vault.centos.org/5.7/os/SRPMS/
gpgcheck=1
enabled=0
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-$releasever
[root@co5kdev ~]#

試しに "which" パッケージのビルドをするために、ビルド時に依存するものを入れておきます。yum-builddep コマンドを使います。


[root@co5kdev ~]# yum-builddep -y which
(中略)
[root@co5kdev ~]#

ようやく、ダウンロード & ビルドです。


[nonpriv@co5kdev ~]$ yumdownloader --source which
(中略)
[nonpriv@co5kdev ~]$ mkdir -p ~/rpm/{SOURCES,BUILD,SRPMS,RPMS}
[nonpriv@co5kdev ~]$ echo "%_topdir $HOME/rpm" > ~/.rpmmacros
[nonpriv@co5kdev ~]$ rpm -i which-2.16-7.src.rpm
[nonpriv@co5kdev ~]$ cd rpm/SPECS/
[nonpriv@co5kdev SPECS]$ rpmbuild -ba which.spec
(中略)
伸張ファイルの検査中: /usr/lib/rpm/check-files /var/tmp/which-2.16-7-root
書き込み完了: /home/nonpriv/rpm/SRPMS/which-2.16-7.src.rpm
書き込み完了: /home/nonpriv/rpm/RPMS/x86_64/which-2.16-7.x86_64.rpm
実行中(%clean): /bin/sh -e /var/tmp/rpm-tmp.38918
+ umask 022
+ cd /home/nonpriv/rpm/BUILD
+ cd which-2.16
+ rm -rf /var/tmp/which-2.16-7-root
+ exit 0
[nonpriv@co5kdev SPECS]

じゃんじゃんソースを入手して、SPEC をいじったりソースを読んだりしましょう。

PostgreSQL をバックエンドにして Zabbix を動かす

2011-11-03T11:35:00.000+09:00

お疲れ様です、サイオス那賀です。

Zabbix は、広く利用されている、オープンソースの統合監視ツールです。単純な監視ツールである Nagios や Munin などと比べて、より詳細な監視が可能なエージェント型の構成をとり、プロキシやノードによる分散も考慮するなど、これ一つでとりあえず必要充分と言えるのではないでしょうか。

CentOS 6.0 での GUI ログイン画面の変更方法

2011-11-01T10:53:00.000+09:00

サイオステクノロジー金田です。

CentOS 6.0 から GUI ログイン画面にユーザー一覧が表示されるようになりました。(画像1)

画像1 CentOS 6.0 デフォルトのログイン画面

システムのユーザー数が少なければあまり気にならないのですが、多人数が登録されているシステムでは自分のユーザー名を探すのはちょっと面倒です。

そこで、ユーザー一覧を表示せず CentOS 5 系(画像2)のような、ユーザー名入力のログイン画面になるようにする設定を紹介します。

画像2 CentOS 5系のログイン画面

エディタで /etc/gconf/gconf.xml.defaults/%gconf-tree.xml を開いて、下記の行を検索します。

[編集前]

<entry name="disable_user_list" mtime="1312141029" type="schema" stype="bool" owner="gdm-simple-greeter" gettext_domain="gdm">
        <local_schema locale="C" short_desc="既知のユーザをログイン・ウィンドウに表示しない">
                <default type="bool" value="false"/>
                <longdesc>TRUE にすると、既知のユーザがログイン・ウィンドウへ表示されなくなります。</longdesc>
        </local_schema>
</entry>

<entry name="disable_user_list" のエントリ中の <default type="bool" value="false"/> の value の値を ture に変更します。

[編集後]

<entry name="disable_user_list" mtime="1312141029" type="schema" stype="bool" owner="gdm-simple-greeter" gettext_domain="gdm">
        <local_schema locale="C" short_desc="既知のユーザをログイン・ウィンドウに表示しない">
                <default type="bool" value="true"/>
                <longdesc>TRUE にすると、既知のユーザがログイン・ウィンドウへ表示されなくなります。</longdesc>
        </local_schema>
</entry>

ファイルを保存しログアウトすると、ユーザー名入力のログイン画面(画像3)が表示されます。
RHEL6 や Scientific Linux 6 でも同じ方法で変更できます。

画像3 変更後の CentOS 6.0 のログイン画面

Apache を SSL で使用する

2011-10-20T01:08:00.001+09:00

おがわです。

今回は、Apache を SSL の環境で使用できるようにしてみようと思います。Apache2.2.21 と OpenSSL1.0.0 を使用します。

■openssl1.0.0 をインストール
-----------------------------------------------------------


# wget http://www.openssl.org/source/openssl-1.0.0e.tar.gz
# tar zxvf openssl-1.0.0e.tar.gz

--prefix オプションをつけてインストール先を指定します。今回はとりあえず、/opt の上にインストールします。


# ./config --prefix=/opt/openssl
# make
# make install

-----------------------------------------------------------

■apache2.2.21 をインストール
-----------------------------------------------------------


# cd /usr/local/src
# wget http://www.apache.org/dist//httpd/httpd-2.2.21.tar.gz
# tar zxvf httpd-2.2.21.tar.gz
# ./configure --prefix=/opt/apache2 --enable-modules=ssl --with-ssl=/opt/openssl
# make
# make install

< apacheユーザー,グループ作成 >


# groupadd apache

クライアントからの要求があったときに、生成される apache の子プロセスに root 権限を持たないようにします。また、生成された子プロセスがアクセスできるファイルシステムを /var/empty/apache に制限します。apache ユーザーはログインできないようにする為、/sbin/nologin を実行します。


# useradd -g apache -d /var/empty/apache -s /sbin/nologin apache
# cd /opt/apache2/conf

証明書置き場を作ります。ここではわかりすいように certs というディレクトリを作成します。


# mkdir certs
# cd certs

自己証明書を発行します。トリプルDES(Data Encription Standard の略)の暗号方式を使用します。どうやら DES という共通鍵暗号方式で 3 回暗号化しているために des3 らしい。鍵の長さは 2048 ビットを使用します。1024ビットはセキュリティの観点から使用しない方がいいみたい。


# openssl genrsa -des3 -out ca.key 2048

# openssl req -new -x509 -days 365 -key ca.key -out ca.crt

※ サーバー証明書と CA 証明書の組織名は異なる必要があるらしいので、適当につけてみます。


Organization Name (eg, company) [Default Company Ltd]:CA
Organizational Unit Name (eg, section) []:CA

サーバー用秘密鍵を作ります。


# openssl genrsa -des3 -out server.key 2048

作成した秘密鍵を利用して、サーバー証明書のCSRを作成します。CSR は Certificate Signing Request の略です。このサーバーにアクセスするときに申請する公開鍵証明書のリクエストのことをいいます。


# openssl req -new -key server.key -out server.csr

シリアルナンバーのファイルを作成します。


# echo 01 > ca.srl

1 年期限のサーバー証明書をつくります。


# openssl x509 -req -days 365 -CA ca.crt -CAkey ca.key -in server.csr -out server.crt

< httpd-ssl.conf >


# vim /opt/apache2/conf/extra/httpd-ssl.conf

■編集項目
-------------------------------------------------------
# 78 行目と 79 行目を変更する。


ServerName www.example.com:443
ServerAdmin y-ogawa@example.com

# 99 行目と 107 行目 (証明書の置き場を指定する。)


SSLCertificateFile "/opt/apache2/conf/certs/server.crt"
SSLCertificateFile "/opt/apache2/conf/certs/server.crt"

-------------------------------------------------------

SSLCertificateFile ディレクティブに証明書が置いてある場所を指定する。

< httpd.conf >


# vim /opt/apache2/conf/httpd.conf

■編集項目
-------------------------------------------------------


# 65 行目と 66 行目
User apache
Group apache

# 406 行目 ( コメントアウトを外して、httpd-ssl.conf ファイルを読み込ませる。)
Include conf/extra/httpd-ssl.conf

-------------------------------------------------------


# /opt/apache2/bin/apachectl start

ここでエラー。


httpd: Could not open configuration file /usr/local/apache2/conf/httpd.conf: No such file or directory

httpd.conf がないって言われる。読みに行ってるディレクトリも httpd.conf の場所と違う...

とりあえず、apachectl コマンドに -f オプションで httpd.conf ファイルの場所を指定すると実行できました！


# /opt/apache2/bin/apachectl -f /opt/apache2/conf/httpd.conf -k start

それか...ディレクトリを作って


# mkdir -p /usr/local/apache2/conf/

シンボリックリンクをはってやる。この方法でも大丈夫でした。


# ln -s /opt/apache2/conf/httpd.conf /usr/local/apache2/conf/httpd.conf

パスワードは証明書を作成したときのものを入力します。


# /opt/apache2/bin/apachectl start
Apache/2.2.21 mod_ssl/2.2.21 (Pass Phrase Dialog)
Some of your private key files are encrypted for security reasons.
In order to read them you have to provide the pass phrases.

Server www.example.com:443 (RSA)
Enter pass phrase:

OK: Pass Phrase Dialog successful.

ちゃんと動いてるか確認、


# ps aux | grep httpd | grep -v grep
root     32446  0.0  0.2   8416  2812 ?        Ss   22:25   0:00 /opt/apache2/bin/httpd -k start
apache   32447  0.0  0.1   8416  1512 ?        S    22:25   0:00 /opt/apache2/bin/httpd -k start
apache   32448  0.0  0.1   8416  1512 ?        S    22:25   0:00 /opt/apache2/bin/httpd -k start
apache   32449  0.0  0.1   8416  1512 ?        S    22:25   0:00 /opt/apache2/bin/httpd -k start
apache   32450  0.0  0.1   8416  1524 ?        S    22:25   0:00 /opt/apache2/bin/httpd -k start
apache   32451  0.0  0.1   8416  1512 ?        S    22:25   0:00 /opt/apache2/bin/httpd -k start

443 番ポートを使用してるプロセスを確認。


# lsof -i:443
COMMAND  PID   USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
httpd   1380   root    4u  IPv4   9420      0t0  TCP 192.168.11.22:https (LISTEN)
httpd   1381 apache    4u  IPv4   9420      0t0  TCP 192.168.11.22:https (LISTEN)
httpd   1382 apache    4u  IPv4   9420      0t0  TCP 192.168.11.22:https (LISTEN)
httpd   1383 apache    4u  IPv4   9420      0t0  TCP 192.168.11.22:https (LISTEN)
httpd   1384 apache    4u  IPv4   9420      0t0  TCP 192.168.11.22:https (LISTEN)
httpd   1385 apache    4u  IPv4   9420      0t0  TCP 192.168.11.22:https (LISTEN)
httpd   1386 apache    4u  IPv4   9420      0t0  TCP 192.168.11.22:https (LISTEN)

HTTPS でアクセスできました！

Type:	PostgreSQL
Host:	localhost
Port:	0 ("0" でデフォルトの 5432 を利用)
Name:	zabbix
User:	zabbix
Password:	zabbix

SIOS "OSSよろず" ブログ出張所

Trouble-Maker モジュールを作成しました

Trouble-Maker のインストール方法 (おさらい)

モジュールのインストール方法

Mac 風 Linux をインストールしてみました

サブドメインの管理を委任する

連載「libvirt を利用して日々の作業を効率化」第２回

連載「Linux コマンド動作徹底解析」"ls -l" 編 第2回

Google Appsを導入しよう (BIND9設定編)

パッケージ更新した後、古いパッケージをロードしたままになっているプロセスを見つける。

連載「ZFS on Linux」第1回～ZFS on Linux のインストール～

環境

インストール手順

OpenShift で MTOS セットアップ

Red Hat Enterprise Linux スタンダードサポート提供時間変更のお知らせ

RHEL5,6 のサポート期間変更のお知らせ

閏年 ~RHEL への影響は？~

連載「libvirt を利用して日々の作業を効率化」第１回

連載「Linux コマンド動作徹底解析」"ls -l" 編 第1回

SUSE 系にしか存在しないサービス起動コマンド

RHEL4 系のサポート期間について

SLES10でノベルカスタマセンターに接続できない問題

rootユーザに変更できるユーザの制限方法

cscope と vim の連携

ソースコード解析ツール -cscope-

worker MPM じゃないと ttl が動かない

Spam対策 -Postfix-

sendmail - ヘルプでのバージョン情報の隠蔽

sendmail - メールヘッダのバージョン情報の隠蔽

CentOS 6.2 リリースされました

sendmail - グリーティング･メッセージでのバージョン情報の隠蔽

sendmail - mailertable による冗長化

sendmail で宛先を限定する方法

DNS による名前解決を行わない設定 -Postfix-

bind 脆弱性 CVE-2011-4313 リンクまとめ

CentOS 6 系で NIC 交換すると eth0 と認識されない

Trouble Maker を触ってみました

CVE-2011-3192 の新しい攻撃コードが公開されています

PostgreSQL で、STATISTICS (列の統計精度) を変更した箇所を忘れたら

ソースの入手と再ビルド ～ Amazon Linux AMI (EC2) 編

PostgreSQL の SQL やプロシージャでランダムデータの入ったテーブルを生成する

SQL のみで実行

ストアドプロシージャで実行

RHEL6.1～系の OpenLDAP (slapd.conf) で SSH 公開鍵配布

ディレクトリ・サーバの設定

認証依頼元の Linux ホストの設定

SSH キー配布の設定

sshd サーバの設定

prelink されたバイナリの "rpm -V" での検証は無問題

追記 (Mon Dec 12 2011)

ソースの入手と再ビルド & デバッグ ～ Mac OS X Homebrew 編

RHEL6 系での OpenLDAP サーバと PAM 認証

RHEL6 系の初期 slapd.d/ は何のため？

サーバの設定

認証依頼元の Linux ホストの設定

debuginfo RPM パッケージで、ソースレベル・デバッグをする

RPM ベースで Puppet を動かしてみる

Ruby の「条件式としての範囲式」の正体を探る

PostgreSQL の無限再帰 WITH 句で思うこと

RHEL6 系で qemu-kvm バイナリを CPU エミュレーション・モードで使う

なぜオンライン EXT3 の LVM2 スナップショット & バックアップは問題なく動くのか？

CentOS 6.0 でインストール直後にネットワークを有効にする方法

PostgreSQL 死活監視のタイムアウト

ソースの入手と再ビルド ～ Ubuntu 編

肥大化した個人利用の Git ワークを縮小する

RPM 版 Tomcat のマルチインスタンス化

PostgreSQL を SNMP で監視する

ソースの入手と再ビルド ～ CentOS / Scientific Linux 編

PostgreSQL をバックエンドにして Zabbix を動かす

CentOS 6.0 での GUI ログイン画面の変更方法

Apache を SSL で使用する

連載「Linux コマンド動作徹底解析」"ls -l" 編第2回

連載「Linux コマンド動作徹底解析」"ls -l" 編第1回

ソースの入手と再ビルド～ Amazon Linux AMI (EC2) 編

ソースの入手と再ビルド & デバッグ～ Mac OS X Homebrew 編

ソースの入手と再ビルド～ Ubuntu 編

ソースの入手と再ビルド～ CentOS / Scientific Linux 編