hetarena.com

モデルアート社により新たな鉄道模型専門誌が創刊されました。モデルアート臨時増刊「鉄道模型スペシャル」です。12/19 に「No.1」が発売されました。

鉄道模型専門誌というよりも鉄道模型レイアウト製作専門とした方がわかり易いかも知れません。この鉄道模型スペシャルには車両製作に関する記事はありません。また、新製品紹介コーナーのようなものもありません。レイアウトの作例とテクニックに関する記事が詰まった雑誌です。

創刊号は「特集 鉄道が走る昭和の街」となっており、昭和をテーマにしています。しかし、作例の街並みは「昭和の鉄道模型をつくる」の街並みに比べたらずっと近代的で、今もどこかに残っていそうな情景が多いです。

対象はレイアウト製作の初心者～中級者に設定しているようで、「鉄道模型ちゃんねる」に比べたら紹介されているテクニックは誰にでも取り入れやすいものとなっています。もちろん「昭和の鉄道模型をつくる」をつくるのに比べたら工作やら塗装やらで道具を揃えなければならないし、手間もかかりますが。

紙面はイラストと写真が多用されたヴィジュアルな構成となっていて、レイアウトの写真はもちろん実在の街並みの資料写真も盛り込まれており、自分の製作時の参考になると思います。

モデルアート社の雑誌は立ち読みばかりだったのですが、今回は思わず購入してしまいました。 配布されているチラシによると次号は 2008年 6月中旬発売予定となっています。

私以外に周囲にも何人かいたし、ネットでもそんな話を見かけた気がするのですが、 UNIX MAGAZINE は買った後捨てられない雑誌でした。 単なるインストール How-To だけでなく普遍性を持った話も多く、いつか役に立ちそうな気がしてしまうのです。

UNIX をいじる時間が少なくなり、記事の大半をスルーしてしまうようになっても購入は続け、書庫に貯め続けていました。 UNIX USER はとっくに捨てても「ユニマガ」の大半は捨てないでいたわけです。特に古いものはスペースの確保が容易い実家で眠らせています。

そんなときに見かけたのが、この「UNIX MAGAZINE Classic with DVD」です。 収納スペースの確保にいつも悩まされているカミさんの了解は簡単に取り付けることができ、やや高価だがと思いつつも Amazon で買ってしまったわけです。

創刊号（1986年11月号）から月刊としての最終号 (2006年4月号) までが PDF 化されて 4枚の DVD に収められています。１冊が一つの PDF ファイルとなっています。 総インデックスのようなものはありませんが、文章はきちんとテキストデータになっています。

93年あたりから表紙に見覚えがありますねぇ…

それとこの製品は DVD と共に新しい記事の詰まった本が１冊入っています。目次には懐かしい執筆陣の名前が並んでいます。 以前の記事で述べた通り、私にとって sendmail は CF の知識で終わっていたので p.76 からの「CF と sendmail」がツボにはまりました。 「女子大生の放課後」の皆さんの近況も (小さなコラムですが) 懐かしく思いながら読みました。 また、「UNIX MAGAZINE DVD 探検」という DVD の記事を読む際に案内となるような記事も含まれています。 この記事と毎年 4月号の直近１年間総目次を使えば目的から記事を探すこともできるのではないかと思います。

まあ、改めて全ての過去記事を読み返すことはしませんが、我が家にとってこの本は空きスペースをもたらす大きな効果がありました。 気になった方はアスキーの詳細情報も覗いてみるとよいと良いでしょう。

Google Webmaster Tools で既に確認済みだったはずのサイトの確認ステータスが「未確認」となってしまいました。

「サイトを確認」のページのメッセージを見ると以下のように確認用 META タグが変更になり新しい文字列を設定するように指示されています。

確認ステータス: 未確認
2007/12/17 に最終試行: 確認 META タグは ****** としてください。
確認した META タグは ++++++ です。

ただし、"******" と "++++++" は新旧の確認用文字列です。

１年以上 Google Webmaster Tools を使っていますが、このようなことは初めてです。 ヘルプを見たり Web 検索してみたりしても定期的に新しい文字列を設定しなければならないという情報は見当たりません。 取り急ぎ、META タグを更新すると即時に Google Webmaster Tools は利用可能となりました。 これまでのデータも消えてはいないようです。

そう言えばと思い出したのが、数日前に Google のアカウント情報を変更してメールアドレス (ログイン ID) を変えたことです。 このタグの文字列はメールアドレスを元に生成されているのかも知れません。 だとするとメールアドレス変更時は META タグの変更も忘れずにしなければなりませんね。

引き続き年末を迎えての備忘録モードで、今回は sendmail 関連です。 私の知識は「sendmail.cf を作るには WIDE の CF を使って生成」というところで終わっているのですが、最近は CF など使わず m4 を使うのですね。

今回はテスト用にメールサーバを立ててクライアント端末から SMTP 接続を受け付け、自ドメイン以外は全て既定の他メールサーバへ配送する設定を行ったのですが、その手順についての備忘録です。

• 設定を変更するには /etc/mail (システムによっては他のディレクトリかも) 内のファイルを編集後、同ディレクトリで make を走らせればオッケー。make により sendmail.cf ファイルや必要なデータベースファイルが生成される。
• /etc/mail/access
  RELAY を受け付けるネットワークを記述するファイル。 例えば以下のようにクライアント端末の存在するネットワークを記述する。

  10.0    RELAY
  192.168 RELAY
  

• /etc/mail/local-host-names
  自ドメインを記述するファイル。ここに記されたドメイン宛のメールを受け取る。

  example.com
  

• /etc/mail/sendmail.mc
  以下の点を修正
  自ドメイン以外は mail.example.com にメールを配送するよう以下の行を追加。

  define ('SMART_HOST', 'mail.example.com')
  

  デフォルトの sendmail.mc に在った、

  DAEMON_OPTIONS(`Port=smtp,Addr=127.0.0.1, Name=MTA')dnl
  

  ではローカル (自ホスト) からの SMTP 接続しか受け付けないので、クライアント端末からの SMTP 接続も受けるように、

  DAEMON_OPTIONS(`Port=smtp, Name=MTA')dnl
  

  と変更した。

• sendmail.mc では "dnl" からその行末まではコメントとして扱われる

実はだいぶ古いバージョンの sendmail-8.12.8 (on RedHat Linux) を使ってこれらのセットアップを行ったのですが、最近の 8.14.x でもこの辺は変わっていないと思います。

年末を迎えての備忘録モードです。 前回の記事に関連して BIND 9 の主にキャッシュ関連についてメモしておきます。 この辺はしょっちゅう触っているわけではないので、書いておかないとすぐ忘れてしまうのです。

• 実際の DNS 環境ではキャッシュサーバでキャッシュされるし、DNS クライアントでもキャッシュされ、多段のキャッシュが起こっている。 このように多段でキャッシュが行われる環境でも、キャッシュサーバはオリジナルの TTL を返すのではなく経過時間だけ減らした TTL を DNS クライアントに返すので、コンテンツサーバ (＝ゾーンを管理するサーバ) で設定した TTL よりキャッシュの存在期間が延びることはない。
• SOA レコードの TTL はネガティブキャッシュの生存期間となる
• bind を使用したキャッシュサーバにおいて TTL の制御に以下のオプションを使うことができる。

  max-cache-ttl
  max-ncache-ttl
  

  これらは TTL を伸ばすものではなく、それを超えた TTL が返って来たときに設定されたその値に縮めるもの。 特に SOA の TTL は、昔と意味が変わっているので、メンテナンスされず不適切に大きな値のままのものがあるかも知れず、この設定は重要。

• セキュリティ上の理由よりキャッシュサーバとコンテンツサーバは分けるべき。
  1. コンテンツサーバ上でキャッシュ汚染が生じないようにするため。
  2. 外部向けコンテンツサーバは公開しなければならないが、公開されたキャッシュは DDoS 攻撃 に用いられてしまうから。
• キャッシュをダンプするには "rndc dumpdb"。rndc は最初に "rndc-confgen -a" を実行しないと使えないかも。

参考までに先の記事でも紹介した「DNS & BIND クックブック」の関連する項を挙げておきます。

レシピ 3.2  ネームサーバが rndc と協調動作するように設定する
レシピ 3.20 キャッシュを抑制する
レシピ 3.21 メモリ使用量を制限する
レシピ 5.3  キャッシュの中身を見る

DNS にはキャッシュの仕組みが組み込まれているので、レコードを変更してもキャッシュには古い情報が残っていてそちらが参照されてしまう場合があります。この新旧の情報が混在してしまう期間を「プロパゲーション期間」と呼ぶことを最近知りました。 ただし、この「プロパゲーション」という言葉を使って説明している文章を見かけたら眉に唾をつけた方が良いようです。 言葉がわからなかったので Web 検索してみたのですが、こちらのブログ記事に共感してしまいました。「通常プロパゲーション期間は１～２週間です」とはどういうことかと。

Web サーバの移転 (IP アドレスの異なる旧サーバから新サーバに切り替えること) を考えて見ましょう。

サーバ移転により変更が必要となってくる DNS レコードは A レコード、PTR レコードです。 実際のところ、新アドレスの PTR レコードと旧アドレスの PTR レコードは同時期に並存可能で、あらかじめ新アドレスのレコードを登録し、しばらく経ってから旧アドレスのレコードを削除すれば良いだけです。なのでプロパゲーションが問題になるのは A レコードの書き換えということになります。

A レコードの変更手順を確認しましょう。

1. あらかじめ変更する A レコードの TTL を短く (ここでは 600 秒＝10分とする) しておく。 この作業をいつまでに行う必要があるかは既 TTL の値による。例えば変更前の TTL が 86,400 秒ならば少なくとも 2. のアドレス変更の１日前までにこの作業をしなければならない。
2. サーバを切り替えるために A レコードの IP アドレスを変更する。
3. 新サーバの安定稼動を確認して TTL を元の値 (86,400 等) に戻す。切り戻しを考えなければ、これを 2. のアドレス変更と同時に行っても良い。

以上の手順で行えば理論的にはアドレス変更から 10分以内に新しい A レコードの値が参照されるようになるはずです。 ただし、厳密には 1. 2. はセカンダリサーバへの反映も考慮する必要があります。通知 (NOTIFY) 機能を使用していれば問題ないですが、そうでなければリフレッシュのタイミングを計算する必要があります。　

実際のところ世の中には TTL を無視するキャッシュが存在するようです。私は実地経験が少ないのでこの辺りは何とも言えないところですが、ブラウザやプロキシサーバ等の実装も関係していそうな気がします。少なくとも私の周囲の DNS キャッシュサーバはまともな動作をしているように見えます。

いずれにせよこのような手順を採れば、プロパゲーション期間が「１～２週間」とはならないはずです。 まあ、業者の立場としては面倒な事前作業やお客さんへの説明をすっ飛ばして、「プロパゲーション期間中なので１～２週間は我慢してください」と言って片付けてしまうのが楽でしょうけれど。バズワードの一種かも。

関連してオライリーの「DNS & BIND クックブック」という本を紹介しておきます。 やりたいことからその実現方法を引けるので超有名なバッタ本 (「DNS & BIND 第４版」) よりも実務的です。 本書の「レシピ 2.16 ホストを移動する」に先の手順が書いてあります。 入門用には勧めませんが、一通り DNS の知識はあるし「DNS & BIND」の旧版も持っているけれど、最新版を買うほど熱心ではない、という人にはちょうど良いと思います。

それは私なのですが…

---

関連記事
「DNS のキャッシュについてもう少し」

あまり話題にはなっていないようですが、Microsoft Live Search の Web 管理者向けツール "Live Search Webmaster Center" のβ版が公開されています。 Windows Live ID (hotmail 等のアカウント) を持っていれば利用することができます。

ざっとどんなことができるのか紹介しておきます。

Summary:
上の画像がそうです。最後にクロールされた日付や (多分 ranking) Top 5 pages 、インデックスされたページ数等が確認できます。

Profile:
Web サイトのプロフィール設定画面です。最初のサイト登録時と同じ項目が並びます。 "Sitemap address" で sitemap ファイルの位置を指定することができます。
また、"Verification" でサイトの認証方法を指定することができます。 オーナーシップ確認のために指定された META タグをサイトの HTML の中に埋め込んだり、指定された XML ファイルをサイトに置いたりする、例のあの手続きです。

Keywords:
指定された語句で検索したときに当該サイトからどのような結果が返るかを確認できます。 残念ながらまだ日本語はまだ使えないようです。

Top links from:
当該サイトからリンクしているサイトで Live Search の (多分 ranking) ベスト 10 を表示します。

Top links to:
当該サイトにリンクしているサイトで Live Search の (多分 ranking) ベスト 10 を表示します。

Sitemap:
sitemap ファイルの更新をマニュアルで通知することができるようです。

エラーもよく起こしているし、ヘルプも十分でないように見えるし確かにβ版という感じです。 とりあえず現時点ではサイトマップファイルを Live Search に伝えることができる点がポイントでしょうか。

自分で言うのも何ですが、このブログのように雑多な内容で、しかも更新がまばらというブログは RSS リーダーで購読するのがお勧めです。RSS リーダーを使えば更新を知るのは容易ですし、記事の選別もしやすいです。 しかも、このブログは全文配信なのでわざわざサイトを閲覧する必要がありません。(たまには見に来て欲しい気もしますが…)

これまでは RSS リーダーによる購読数が把握できないのが嫌で RSS フィードについてはあまり宣伝はしていなかったのですが、このたび FeedBurner 経由でフィードを配信するようにしてこの問題を解決しましたので、これを機にRSSリーダーの使用をお勧めしておきます。

新しいフィードの URL は

• http://feeds.feedburner.jp/blogger323

です

既に購読いただいている皆様は、既存 URL での配信も引き続きご利用いただけますので、特に設定変更の必要はありません。 まあ、何かの機会に登録しなおしていただけると、把握している購読者数が増えて私も張り合いが出るとは言えます。

これって RSS フィードのアイコンなのですね。ヘタレと言われそうですが、認知していませんでした…

Microsoft Word で既に「図 1」、「図 2」、「図 3」… と振っている図表番号を、後から章番号を入れて「図 1-1」、「図 1-2」、「図 2-1」… のようにしたいときの操作です。Word 2002、2003 で確認しています。 知っている人は知っていそうですが…

1. 任意の場所で図表番号の挿入操作を行います。「挿入」－「参照」－「図表番号」ですね。
2. 「図表番号」ダイアログボックスで「番号付け」を押します。続いて表示された「図表番号の書式」ダイアログボックスで「章番号を含める」をチェックします。
   
3. この「図表番号の書式」ダイアログボックスで「OK」を押したタイミングで図表番号の書式が変わります。 ですのでその後新たな番号を挿入する必要はなく、「図表番号」ダイアログボックスで「閉じる」を押してかまいません。

ちなみに「図表番号」ダイアログボックスで「ラベル名」を追加すれば「写真 1」、「写真 2」… 等任意のラベルが使えるのですね。知らなかった。

他の文書からコピーした図表番号が章番号無しのときは、コピー後にこの操作を繰り返せば良いです。 このあたりの操作は時々フィールドコードを表示していじり倒したい誘惑に駆られることがありますが、本分であるドキュメント作成からはずれてしまいそうなので自重しております。

---

関連記事

• Microsoft Word 目次の書式設定