レベル: 初級 Teodor Zlatanov (tzz@iglou.com)Gold Software Systems
2004年 7月 10日 平均的な開発者はコンフィギュレーション・ファイルを理解したりデバッグしたり、動くようにしたりするために思った以上に時間を費やしているものです。ところがそのために費やす時間を（さらに労力やイライラまで）、日々使っているツール、つまりCVSツリーで節約することができるのです。面倒なLinux™（とUNIX®）のconfigファイルを移植性の高いものにするため、またバックアップや配布のためにこのヒントを利用してください。
Linuxやコンピューター一般を使う上で、コンフィギュレーション・ファイルをいじるのは混乱しやすい部分です。いくつか提案はされていますが、標準というものが存在していません。例えばSambaとrsyncではINI型のコンフィギュレーションを使っています。passwdは何十年も前から使われているコロン区切りの形式で、どのフィールドでもコロンを使うことができません。sudoはvisudoプログラムと一緒になっていて、sudoersファイルに間違った情報が入れられないようにしています。Emacsはコンフィギュレーション・ファイルにLispを使います。このリストはさらに続き・・・
さて、私はコンフィギュレーション・ファイルが色々あることに文句を言っているのではありません。私はバベルの塔コンフィギュレーション版の歴史的、現実的理由を理解しているつもりです。例えばSambaのコンフィギュレーション・フォーマットを変えてしまうと、何千人もの管理者を煩わせることになります。別の例を挙げると、Emacsの内部言語は強力な高位言語であるLispですから、他の言語をEmacsのコンフィギュレーションに使うのは馬鹿げています。
私が気にしているのは、こうしたコンフィギュレーションがLinuxユーザーに及ぼす影響なのです。Linuxユーザーがコンピューターを使う時間の大きな部分が、コンフィギュレーション・ファイルを分析したり、書いたり、デバッグしたりするために費やされています。ですから次のようなシステムがあれば便利なのです。つまりコンフィギュレーション・ファイルが（1）自動的にバックアップされ、（2）自動的に配布され、（3）色々な種類のUNIXやLinuxディストリビューションで動作する、というシステムです。この記事では初めの２つを実現するための方法と、３番目を実現するためには何を始めれば良いかを説明します。
計画
コンフィギュレーション・ファイルを保持するにはCVSを使います。他のバージョン管理システムを使っても一向に構いません。Subversionは急速に人気が高まっています。FSFにはGNU tla (GNU arch）があり、これも便利なバージョン管理システムです。Rational® ClearCase®のように無料ではないものも含めて、これらにはどれも、基本的に必要な機能は備わっています。
私のコンフィギュレーション方式では、各コンフィギュレーション・ファイルは単一ディレクトリ内、または単一ディレクトリの一つのサブディレクトリ内にあります。コンフィギュレーション・ファイルには独自の名前が付けられ、ディレクトリは場所ではなく、マシンまたはプラットフォームを表します。ですから、ファイル名はファイルシステム上の唯一の場所に対応します。例えば/etc/passwdに対しては常にpasswdが使われ、ユーザーtzzの/home/tzz/.cshrcに対してはcshrcが使われます。
私のコンフィギュレーション・システムを使って複数のプラットフォームをどのように扱うか、またコンフィギュレーション・ファイル自体を変更するにはどうするかを、私が毎日使っているプログラムを例に挙げて説明します。
お見せする全ての例では、環境変数の設定にCシェルを使います。GNU bashや何か他のものを使うように変更するのもそれほど難しくないはずです。
CVSを設定する
読者のマシンには既にCVSがインストールされていると思います。まだでしたら手に入れて（参考文献）インストールしてください。他のバージョン管理システムを使っている場合には、以下に示すものと似たものを設定してください。
まず、CVSリポジトリを作る必要があります。ここではCVSサーバーとして使えるマシンに、OpenSSHまたはPserver CVSアクセスを使ってアクセスができるものと想定しています（PserverはCVS用の通信プロトコルです。詳しくは参考文献を見てください）。次にconfigと呼ばれるモジュールを作る必要があります。このモジュールを使ってサンプルのコンフィギュレーション・ファイルを保持するのです。最後にOpenSSHまたはPserverで、あるいはその他何でも適切な方法で、CVSリポジトリを遠隔から非インタラクティブに使うための方法を設定する必要があります。この最後の点に関しては読者のシステム管理技能や偏執狂の程度、環境等々に大きく依存するので、参考文献に一部情報を挙げるのに止めておきます。これから先では、読者がOpenSSHで非インタラクティブな（sshエージェントの）ログイン設定をしてある、という前提で説明します。
リスト1. マシンにCVSリポジトリを設定する
# assume that /cvsroot is your repository's home
> setenv CVSROOT /cvsroot
# this will use $CVSROOT if no -d option is specified
> cvs init
# check that it worked
> ls /cvsroot
# you should see one directory called CVSROOT
CVSROOT
|
リポジトリが設定できたので、これを遠隔で使い続けることができます（リスト1と同じようにCVSROOTを残しておくことで、下のステップをCVSサーバーで行うこともできます。）
リスト2. 遠隔からCVSにconfigモジュールを追加する
# user tzz, machine home.com, directory /cvsroot is the CVSROOT
> setenv CVSROOT tzz@home.com:/cvsroot
# use SSH as the transport
> setenv CVS_RSH ssh
# use a temporary directory for the module creation
> cd /tmp
> mkdir config
> cd config
# tzz is the "vendor name" and initial is the "release tag", they can
# be anything; the -m flag tells CVS not to ask us for a message
# if this fails due to SSH problems, see the Resources
> cvs import -m '' config tzz initial
No conflicts created by this import
# now let's do a test checkout
> cd ~
> rm -rf /tmp/config
> cvs co config
cvs checkout: Updating config
# check everything is correct
> ls config
CVS
|
configCVSモジュールのコピーをホームディレクトリにチェックアウトしたので、これを開始点として使います。この記事では私のユーザー名tzzを、ホームディレクトリに/home/tzzを使いますが、他の適当な名前やディレクトリを使うことももちろんできます。
一つのファイルを作ってみましょう。CVSをさらにもっと使うので、CVSのオプションファイル、cvsrcが適当なようです。
リスト3. cvsrcファイルを生成して追加する
> cd ~/config
> echo "cvs -z3" > cvsrc
> echo "update -P -d" >> cvsrc
> cvs add cvsrc
# you really don't need log messages here
> cvs commit -m ''
> ln -s ~/config/cvsrc ~/.cvsrc
|
これから先では全てのCVSオプションは~/config/cvsrcに置かれ、そのファイルを~/.cvsrcの代わりに更新します。追加した特定なオプションはCVSに対して、ディレクトリが存在しない時にはディレクトリを回復するように伝え、また空のディレクトリは取り除くように伝えます。これが通常ユーザーが望むことです。この方法で設定したい、残りのマシンに関してはconfigモジュールを再度チェックアウトし、再度リンクをつけます。
リスト4. configモジュールをチェックアウトしcvsrcリンクをつける
> cd ~
# set the following two for remote access
> setenv CVSROOT ...
> setenv CVS_RSH ...
# now check out "config" -- this will get all the files
> cvs checkout config
> cd ~/config
> ln -s ~/config/cvsrc ~/.cvsrc
|
Linuxでは、今作ったシンボリック・リンクだけでなくハードリンクもできることは読者も知っているでしょう。ハードリンクはその制約から、ここでの目的には適当ではありません。例えば~/config/cvsrcに対してハードリンク~/.cvsrcをつけ、後から~/config/cvsrcを削除したとします（様々な要因で起こり得ます）。~/.cvsrcファイルは、それまで~/config/cvsrcであったものの、古い内容を保持しています。ここで~/config/cvsrcを再度チェックアウトします。ところが~/.cvsrcファイルは更新されません。この問題があるので、この場合にはシンボリック・リンクの方が良いのです。
cvsrcを変更してもう一つオプションを追加するとしましょう。
リスト5. cvsrcを修正してコミットする
> cd ~/config
> echo "checkout -P" > cvsrc
> cvs commit -m ''
|
使っている他のマシンのどれでも~/.cvsrcを更新するには、単に次のようにします。
リスト6. cvsrcを修正してコミットする
> cd ~/config
> cvs update
|
これは非常に簡単です。さらに良いことに、上で示したCVS更新は~/configのどのファイルも更新するので、このCVS方式の下で保持している全てのファイルが一つのコマンドで同時に最新のものになるのです。このコンフィギュレーション方式の本質的な所はここなのです。これから後の説明は飾りにすぎません。
注意して欲しいのですが、モジュールをチェックアウトとすると、その中には「CVS」と呼ばれるディレクトリがあります。このディレクトリにはCVSモジュールに関する十分な情報があり、CVSROOT変数を規定することなく、更新したりコミットしたり、あるいは他のCVS操作をすることができます。
自動的な更新とコミット
自動的な更新とコミットのために、非常に単純なPerlプログラムmaintain.plを書いてみました。このプログラムで一番長い部分はヘルプテキストですから、複雑なコードで一杯ではないことは想像いただけるでしょう。一応これを説明しますが、必要な場合にはシェル・スクリプトで同じ事ができることは頭に置いておいて下さい。
maintain.plは、（他には色々しますが）シンボリック・リンクを作ることだけはしません。シンボリック・リンクを作るのは一度だけでよく、一部のシステムではともかくリンクを嫌うので、手動でも簡単にできることを考えると自動化するまでもないと言えます。私はシンボリック・リンクのコードを書いてから、後で削除したことがあるので知っているのです。
私が書いて維持管理する必要があったのは、多くのファイル名をマップするようなコンフィギュレーション・ファイルでした。例外もたくさんありました。例えば私が使っている2台のLinuxとSolarisシステムでは設定が大幅に違っています。気にすべき事があまりにもたくさんあり、結局手動でリンクをインストールした方がずっと簡単だと分かったのです。もちろんその人の経験によっても事情は異なります。自分の環境に最も適切な方式を見つけるべく努力するようにお勧めします。
maintain.plスクリプトはいつものように、コンフィギュレーション・オプションの定義、コマンドライン引数のロード、それにヘルプ・テキストから始まります。
リスト7. maintain.plスクリプトでの前書き
#!/usr/local/bin/perl -w
# {{{ modules and constants
use strict;
use AppConfig qw/:expand :argcount/;
# }}}
$| = 1; # autoflush the output
my $config = AppConfig->new();
$config->define(
'HELP' =>
{ ARGCOUNT => ARGCOUNT_NONE, DEFAULT => 0, ALIAS => 'H'},
# update level, higher checks out more
'LEVEL' =>
{ ARGCOUNT => ARGCOUNT_ONE, DEFAULT => 5 },
'CONFFILE' =>
{ ARGCOUNT => ARGCOUNT_ONE, ALIAS => 'F',
DEFAULT => glob("~/config/maintain.conf") },
'CVS' =>
{ ARGCOUNT => ARGCOUNT_ONE, DEFAULT => 'cvs' },
'CVS_RSH' =>
{ ARGCOUNT => ARGCOUNT_ONE, DEFAULT => 'ssh' },
'UPDATE' =>
{ ARGCOUNT => ARGCOUNT_HASH },
'DRYRUN' =>
{ ARGCOUNT => ARGCOUNT_NONE, DEFAULT => 0, ALIAS => 'N' },
'COMMIT' =>
{ ARGCOUNT => ARGCOUNT_NONE, DEFAULT => 0, ALIAS => 'C' },
);
$config->args();
if (-r $config->CONFFILE() && -f $config->CONFFILE())
{
$config->file($config->CONFFILE());
}
else
{
print "The file " . $config->CONFFILE() .
" was not readable, skipping\n";
}
if ($config->HELP())
{
print <<EOHIPPUS;
$0
Run $0 without any arguments to load
@{[$config->CONFFILE()]}
and update everything in it at level
@{[$config->LEVEL()]} or less.
Switches:
-level (default @{[$config->LEVEL()]}) :
check out everything at this level or less
-help (-h) : print this help
-conffile (-f, default @{[$config->CONFFILE()]}) :
load this configuration
-cvs (default @{[$config->CVS()]}) :
where to find the cvs program
-cvs_rsh (default @{[$config->CVS_RSH()]}) :
sets the CVS_RSH environment variable
-update : populate the UPDATE hash in the configuration
file or like this:
-update /home/tzz/ see below for explanation
-commit (-c) : don't just update, also do a commit of
anything changed
-dryrun (-n) : don't run anything, just test directories
and levels
Configuration file:
Very simple AppConfig format; everything in the switches can be
specified in the configuration file as well, e.g.
COMMIT = 1
UPDATE /home/tzz/config = 0
The example above says that /home/tzz/config will be updated at level
0 or higher, and that you always want to commit when you run this
program.
EOHIPPUS
exit 0;
}
$ENV{CVS_RSH} = $config->CVS_RSH();
|
AppConfigモジュールに馴染みがないようでしたら、コンフィギュレーションの管理に関して有益な情報を参考文献に挙げておきますので、よく調べてください。
ユーザーのホーム・ディレクトリはどこにあるか分からないので、デフォルトのCONFFILEを決めるためにglob()コールを使っています。CONFFILEが無効なデータを含んでいる場合には、AppConfigは自動的にプログラム全体を停止してしまいます（これは単なる警告に変更することができます）。このスクリプトはコンフィギュレーション・ファイル無しでも実行します。
ヘルプ・テキストを出力した後、CVS_RSH環境変数を適当な値に設定します（デフォルトをsshにします）。こうするのはユーザーが環境変数を他の方法で設定しなくてもすむようにするためで、これはmaintain.plをcrontabに置くユーザーには特に便利です。
こうした前置き部分の後、このスクリプトの核心部分を見てみましょう。
リスト8. maintain.plのメイン・ループ
foreach my $spot (keys %{$config->UPDATE()})
{
my $level = 0 + $config->UPDATE()->{$spot};
next if $level > $config->LEVEL();
print "Spot $spot, Level $level\n";
chdir $spot;
if ($config->DRYRUN())
{
print "Not updating due to DRYRUN\n";
}
else
{
system($config->CVS() . " -q update");
}
if ($config->COMMIT())
{
if ($config->DRYRUN())
{
print "Not committing due to DRYRUN\n";
}
else
{
system($config->CVS() . " commit -m ''")
}
}
}
|
これは簡単なループです。すべてのspot（実はディレクトリです）を見て回り、そのspotのレベルがLEVELコンフィギュレーション変数よりも小さいか同じ場合にはcvs updateを行い、デフォルトを5とします。さらにCOMMITフラグが立っている場合にはcvs commit -m ''を行いますが、これは全ての変更を空のログ・メッセージでコミットします。実際もしDRYRUNフラグがなかったら、このループは数行にすぎなかったでしょう。
私は複数引数形式ではなくストリング形式でsystem()を使っています。これを別な方法で行うこともできます。このファンクション・コールの使い方の詳細については、perldoc -f systemを見てください。
またsystem() callの結果はチェックしていませんが、これはその必要がないからです。CVSの更新またはコミットに関しては、これらが致命的なコンフィギュレーション・ファイルなので、やみくもに更新したくはありません。ですからmaintain.plがする事（あるいはすべき事）もありません。
コンフィギュレーション・ファイル自体は単純に次のようなものです。
リスト9. maintain.conf
# the number is the update level
UPDATE /home/tzz/emacs = 0
UPDATE /home/tzz/config = 0
UPDATE /home/tzz/articles = 1
UPDATE /home/tzz/gnus/gnus = 1
|
思い出して欲しいのですが、ここでは任意のAppConfig変数を設定できるので、例えばデフォルトのLEVELまたはCVS_RSHを置き換えることもできます。私はEmacs、config、articles、それにgnus等のディレクトリをmaintain.plで更新していますが、どの程度頻繁に更新するかはそれぞれ異なるので、それぞれの更新レベルも異なります（私はレベル0を1日2回、レベル1を1日1回行います）。
新しいコンフィギュレーションを整備する
このセクションでは、私の個人的な経験を基にして、ここまでに設定したコンフィギュレーション・システムの使い方について説明します。私の考え方を自由に利用して下さい。ただし、私の個人的な設定が誰にでも適切とは限らないことは頭に置いておいて下さい。
私はマシンとオペレーティング・システムをできる限り具体的に反映した形でディレクトリを作るようにしています。例えばLinux特有のコンフィギュレーションは「linux」の下に置くようにしていますが、私のホームマシン「heechee」は特別なキーボードを使っているので、heecheeディレクトリとheechee専用のコンフィギュレーションも持っています。
ただしこうしたルールによらず、もしコンフィギュレーションを（複数プラットフォーム用に複数用意しなくても）一つのファイルで表現できるのであれば、ぜひそうすべきです。そうしないと、同じファイルの別バージョンをいくつも維持管理するために大きな時間を費やす羽目になり、面倒なことになります。
私のcshrcファイルの例から始めましょう。これは全てのマシンに対して一つのバージョンしかありません。条件分岐にはCシェル言語に組み込まれている判断論理を利用しています。
リスト10. 各種プラットフォーム用にprecmdを定義する
switch ($OSTYPE)
case "solaris":
case "SunOS":
alias precmd '/bin/echo "\033]0;${HOST}:$cwd\007\c"'
breaksw
case "linux":
alias precmd 'echo -n "\033]0;${HOST}:$cwd\007"'
breaksw
endsw
|
上に挙げたコマンドは、同じことに対していくつか異なる規定をしています。Linuxのechoは新しい行を出力しないようにするために-nスイッチが必要ですが、Solarisではストリングの最後に\cが必要です。こうすることによって、プロンプトが出力された時にはいつもxtermウィンドウのタイトルをHOST:/DIRECTORYに設定します。
当然のことですが、コンフィギュレーション・ファイル自体の中で何かを判断できる場合には、通常は同じファイルの別バージョンを全く別のディレクトリで複数作る必要はありません。例えば私のEmacsコンフィギュレーションは、私が定常的に使っている全部で6台かそこらの別々のマシンに対して、一つのバージョンしかありません。しかもそのそのマシンの一部では何年も前のEmacs 20を使っているのです！
場合によると少し分割が必要になってきます。例えばxmodmaprcファイルは（他にも多くのことをしますが）キーコードとキー名の対応を設定します。私はホームマシン用のバージョンを~/config/heechee/xmodmaprcに、全てのSunマシン用は~/config/sun/xmodmaprcに置いています。xmodmaprcフォーマットには特別な論理はないので、分割するのが唯一の手段です。ただし全部のSunマシンが同じモデルのキーボードを使っているので、Sunマシン用には一つのxmodmaprcを作っただけです。
crontabファイル（私は~/.crontabに置き、定期的にcrontabに再ロードしています）は、マシン専用である必要のあるコンフィギュレーション・ファイルの極端な例です。私のホームマシンのcrontabは他のどのマシンに対しても不適当であり、標準のcrontabフォーマットには、時間以外の要素に基づいてcronが行うべき作業を選択するための論理がありません。
要は、複数のコンフィギュレーション・ファイルが必要かどうかをよく考え、その後で複数ファイルを構成する最善の方法を考えるべきだということです。目標は一貫性のある環境であって、コンフィギュレーション・ファイルを書いたり維持管理したりするのに長時間費やすことが目標なのではありません。この記事で説明した方式が、皆さんのコンフィギュレーション涅槃の境地探求の一助となれば幸いです。
まとめ
この記事は皆さんの興味を引き、役に立つものになったでしょうか。役に立つ部分があったら使ってみてください。私は自分の設定を完全なものにするために何年も費やしてきましたので、皆さんの役に立つ所があると思います。
この方式に変換する作業をする場合には夢中にならず、一度に少しずつ行うようにしてください。コンフィギュレーションの書き直しをしていると、すぐに何日も費やしてしまいます。徐々に行っていけば、そのプロセスも楽しめるはずです。
この方式の一番の利点は自動更新機能でしょう。どのマシンでもファイルをコミットでき、しかもそのファイルは次にmaintain.plが実行した時に、他のどこにでも現れてくるのです。ディレクトリ構造には反対されるかもしれませんが、自動アップデートの力と便利さを考えてみてください。
２番目の利点はコンフィギュレーションのアーカイブです。どのバージョンのコンフィギュレーションもバージョン管理システムの管理下に入るのです。間違えたら、その前のバージョンに戻ることができます。全マシンを失ったような場合、例えばディスクが壊れた場合、長時間かけて書いたコンフィギュレーション・ファイルを数分で回復できるのです。
ただし、全てをこの方式に変換しようとは思わないでください。保存したいもの、再利用したいものだけを変換してください。バイナリ・ファイルはCVSではうまく行きません。少なくともテキストファイルに使えるdiff機能は、バイナリに対してはありません。また、CVSはディレクトリのリネームで問題があります（もちろんリポジトリにあるディレクトリもリネームすれば確かにできますが）。
最後に、CVSROOTリポジトリのきちんとしたバックアップをとっておくようにしてください。もちろんそのバックアップを使う必要はないように祈っていますが。
参考文献
- developerWroksの実用的なPerlコラムにある、TedのPerl関係の記事を読んでください。
-
CVS homeにはCVS関連のリンクが数多くあります。無料のバージョン管理システムにはSubversionや
GNU arch（GNUtlaとしても知られています）があります。商用版ではRational ClearCaseがあります。
- Jennifer VespermanによるEssential CVS (2003年O'Reilly & Associates刊）はCVSの概説として好適です。Gregor PurdyによるCVS Pocket Reference, 2nd edition (2003年O'Reilly & Associates刊）はCVSの早見表として素晴らしいものです。強くお勧めしたいと思います。
- Karl FogelとMoshe BarによるOpen Source Development with CVS, 3rd Edition (2003年Paraglyph Press刊）は無料で入手できるオンラインの本です。書店でそのコピーを購入することもできます。
-
Version Control with Subversion(2004年O'Reilly & Associates刊）は面白い読み物です。
-
dotfiles.comはCシェルやbash、Emacsその他数多くの、LinuxやUnixプログラムの設定について学ぶためには素晴らしい資料です。強くお勧めしますが、このサイト見るだけで週末をまるまる過ごしてしまったと言って私を責めないでください。
-
OpenSSHはSSHプロトコルの実装としての標準であり、無料でかつ非常に良い実装となっています。CVS Pserverは匿名CVSアクセスには好適ですが、セキュアではありません。
- sshエージェントによるOpenSSHの非インタラクティブ・ログインについて、Daniel Robbins が3回のシリーズOpenSSHキー(鍵)の管理（developerWorks, 2001年7月）で説明しています。
-
AppConfigはコマンドライン・オプションやコンフィギュレーション・ファイルを構文解析するためのCPANモジュールです。洗練されたPerl: Perlでのアプリケーション構成（developerWorks, 2000年10月）ではTedが、
AppConfigモジュールがPerlプログラムのローカル構成記憶域をどう処理するか、またそうした構成がどのようにデータベースに保存されてネットワーク上のマシンからアクセスできるようになるかを説明しています。
-
Understanding Linux configuration files（developerWorks, 2001年12月）を読むのも良いでしょう。ここではユーザー許可やシステム・アプリケーション、デーモン、サービスその他の管理作業を制御する、Linuxでのコンフィギュレーション・ファイルについて説明しています。
- 一方、configureをデバッグする（developerWorks, 2003年12月）では正常なconfigファイルがおかしくなり、自動コンフィギュレーション・スクリプトが働かない時にはどうすべきかを説明しています。ここにあるヒントで、ユーザーも開発者もトラブルを最小限に止めることができるでしょう。
- developerWorksのLinuxゾーンには他にもLinux開発者のための資料が豊富に用意されています。
- Developer BookstoreのLinuxセクションではLinux関係の書籍が値引きされて購入できます。
- あなたのLinuxアプリケーションの開発やテストにdeveloperWorks Subscriptionで入手できるIBMの最新のツールやミドルウェアを利用してください。WebSphere®やDB2®、Lotus®、Rational®それにTivoli®といったIBMのソフトウェアと12ヶ月間使用可能なライセンスを、想像されるよりもはるかに安価で入手できます。
- Linux上で実行する、より抜きのdeveloperWorks Subscription製品の無料の試用版をダウンロードしてください。developerWorksのSpeed-start your Linux appセクションからWebSphere Studio Site DeveloperやWebSphere SDK for Web services、WebSphere Application Server、DB2 Universal Database Personal Developers Edition、Tivoli Access ManagerそれにLotus Domino Serverが入手できます。もっと手早くしたければ、ハウ・ツー記事や技術サポートが製品毎に集められていますので、ご自由に入手してください。
著者について  | | | Teodor Zlatanovは1999年にボストン大学を卒業し、コンピューター・エンジニアリングで学位を取得しています。1992年以来プログラマーとして働いており、Perl、Java、C、C++などの言語を使用してきています。関心を持っている領域としてはオープン・ソース作業、Perl、テキスト構文解析、3層のクライアント/サーバー・データベース・アーキテクチャー、Unixのシステム管理などです。助言や間違いの指摘を歓迎しています。連絡先はtzz@bu.eduです。 |
記事の評価
| 
