【ソフトウェア】

Let's Encrypt でワイルドカードあり／なしを共存させようとして小ハマリしたのでメモ。
Let's Encrypt は、無料で、手軽にSSLを実装できるので重宝している。
いつか有償化されるのではないかと恐れおののきながら使っているが、無料で使える間は便利に使わせて頂きます。

Let's Encrypt では、サブドメインにワイルド―カードを指定して SSL を聞かせる事ができる。
たとえば、このブログのドメインは「blog2.zunbe.com」であるが、「*.zunbe.com」という証明書を取得して使用している。

ここで、サブドメインのない「zunbe.com」に対して証明書を取得するには、どうしたらいいのだろうか。
順当な方法としては、certbot を2回実行して、証明書を取得する。

$ certbot certonly \
  --manual \
  --preferred-challenges dns-01 \
  --server https://acme-v02.api.letsencrypt.org/directory \
  -d "zunbe.com"

$ certbot certonly \
  --manual \
  --preferred-challenges dns-01 \
  --server https://acme-v02.api.letsencrypt.org/directory \
  -d "*.zunbe.com"

こうすると、それぞれのコマンドで、DNSレコードの「_acme-challenge.zunbe.com」に設定するテキストが取得できる。
すなわち、DNSに設定するべきテキストは2個出てくる。
しかし、この2個のテキストを、どうやって「_acme-challenge.zunbe.com」に設定するのだ？

別の取得方法としては、certbot のオプション「-d」を重ねて指定する方法がある。

$ certbot certonly \
  --manual \
  --preferred-challenges dns-01 \
  --server https://acme-v02.api.letsencrypt.org/directory \
  -d "zunbe.com" \
  -d "*.zunbe.com"

これなら「_acme-challenge.zunbe.com」に設定するテキスト1個だけ取得できるのかと思ったのだけれど、この場合でも2個出てくる。
どうやって「_acme-challenge.zunbe.com」に設定するのだ？

頓挫してしまった。(T_T)

う～ん、と悩む...
う～ん、と悩む...
う～ん、と悩む...
閃いた！
もしかして「_acme-challenge.zunbe.com」という同じホスト名で2レコード登録できるのか？

と、いう事で、やってみた。
できるやん！

ホスト名はプライマリ・キーみたいなもので、ユニークにしか設定できないものだと思い込んでいた。
盲点だった（いや、ずんべ の知識が足りんだけなんだけど)。

nslookup で確認してみる。
2レコード設定されている。OKだ。

$ nslookup -type=TXT _acme-challenge.zunbe.com 8.8.8.8
Server:         8.8.8.8
Address:        8.8.8.8#53

Non-authoritative answer:
_acme-challenge.zunbe.com       text = "1nCuhGmf1*********************3gpreFMIoC23k"
_acme-challenge.zunbe.com       text = "oN2q26lEF*********************gOpze4H6lHLM"

Authoritative answers can be found from:

ブラウザで証明書を表示させてみる。
「zunbe.com」「*.zunbe.com」とも、SSLが効いている。OKだ。

とりあえず、これでヨシ！

最近、キーボードから入力するときに、半角入力（IMEオフ）と全角入力（IMEオン）が、どうにも、うまくコントロールできない。
以前は、きちんとコントロールできていて、半角を入力したい時に全角モードであったり、逆に全角で入力したい時に半角モードになっていて、イラっとする様な事はなかったように思うのだが、最近は、頻繁にイラっとしている。

たとえば、このブログのURL「blog2.zunbe.com」を入力して頭を上げると、こんなになっている。

まぁ、ずんべ が年を取った結果なのだろうとは思うのだけれど、しょっちゅうイラつくので、これをなんとかしたい。

ググってみると、以下のような情報が出てくる。

なるほど、そうだよね。
この線で考えてみよう。

という事で、ググってみる、AIに聞いてみる。
すると、以下のような情報が出てくる。

しかし、「設定」という項目は見当たらない。

更に調べると、以下のような情報が出てくる。

しかし、「キーとタッチのカスタマイズ」画面までは行けるが、そんな設定は見当たらない。

どうしろっちゅうねん。
Windowsでも、Googleのツールでも、何でもそうだけど、何かバージョンが変わる度にインターフェースをコロコロ変えるのは勘弁してほしい。
ぜんぜん使いやすくない。

さて、どうするか。
何らかキーバインドを設定するアプリをインストールすれば解決しそうだけれど、それはしたくない。
ググっても、AIに聞いても、それらしい設定は出てこないが、どこかに設定はないのか。

自分で探す...
自分で探す...
自分で探す...
自分で探す...
あった！

IMEアイコンを右クリックし、「プロパティ」をクリックする。

画面下端の「詳細設定」をクリックする。

「編集操作／キー設定」が「Microsoft IME」になっているはず。
「変更」をクリックする。

下にスクロールして、「無変換」を探すと「かな切替」になっている。
これをダブルクリックし、表示された画面で「IMEオフ」をクリック、「OK」で閉じる。

同様に、「変換」を探すと「再変換」になっている。
これをダブルクリックし、表示された画面で「IMEオン」をクリック、「OK」で閉じる。

これで、「無変換」で「IMEオフ」、「変換」で「IMEオン」になった。
この操作に慣れるまで少し時間がかかるかもしれないけど、とりあえず、これでやってみる。

DeleGate＋robots.txt で大ハマリしたので、メモ。

会社の公開サーバは、複数のサーバをひとつの固定IPアドレスで公開しているため、内向きの、いわゆるリーバース・プロキシを通すことで、インターネットから入ってくる接続を各サーバに振り分けている。
使用しているプロキシ・サーバは DeleGate。

DeleGateは、/robots.txt にアクセスがあった場合、自動的にプロキシ経由のURLを検索エンジンにヒットさせないように、robots.txt の内容を自動的に書き換えて返す。

たとえば、以下のような内容で /robots.txt が置かれていた場合…・

DeleGateは、以下の様に自動的に出力を追加する。

この動作は、/robots.txt が存在しているか否かに関わらず自動的に出力され、/robots.txt が存在しなくても、常に以下の様に出力される。

昨今は、WEBサイトがどんどんSSL化されつつあるが、httpsでアクセスした場合、/robots.txt にどのように記載してあったとしても、すべて捨てられてしまっている事に気付いた。
常に /robots.txt が存在しないものとして、DeleGateの自動出力だけが出力されている。
すなわち、/robots.txt を置いても置かなくても、/robots.txt にどのように記述してあっても、常にこのように出力される。

マヂすか。(涙)
まぁ、DeleGateと言えども、SSLで通信されている内容を傍受／復元して「内容を改ざんする」事はできないだろうから、SSLで通信をしている場合は、出力のすべてを置き換えるしか方法がないのだろうな。
もし、傍受／復元が可能だとすると、SSLでて暗号化している意味がない。
確かに、そりゃそうだと思う。

DeleGateが開発された当時は、まだSSLは一般的ではなく、特殊な環境であったと思うので、この動作でも大きな問題ではなかったのだろうけれど、ほとんどのWEBサイトがSSL化されている現在の状況では、この動作はちょっと厳しい。

困ったぞ。
サーバ上のコンテンツはインターネットから見える様にはしているが、検索エンジンにはヒットさせたくない。
そして逆に、このブログを含め、検索エンジンにヒットさせたいコンテンツもある。

DeleGateのマニュアルと読むと、MOUNT のオプションに「robots={no|ok}」という設定は存在しているが、どう設定しても出力は変化しない。
過去に仕事で X-Window のソースと格闘し、死ぬほど苦労した ずんべ としては、正直、こういったソフトウェアのソースコードは覗きたくない。はっきり言うと、ソースコードが「すごく汚い」のだ。たいていの場合、読めたもんじゃない。
さりとて、robots.txt が制御できないのも困る。

仕方がない、ソースコードを開いてみることにする。
がい、しかし、やっぱり、読むには辛いソースコードだ。
同じ構造体を、異なるソースファイルだと、異なる型で定義されていたり...、
関数の情報はヘッダファイルなどにまとめられておらず、各ソースファイルで必要に応じてという形で記述されていたり...。
マクロだらけで、結局、どういうソースに展開されるのか、ぜんぜんわからない...。
各ソースは、それが「クラス」であるかの如く振る舞うような作りになっているように思えるけれど、一貫性がない。

それでも頑張って、追ってみる、追ってみる、追ってみる。
「robots={no|ok}」を参照しているコードはあった。
しかし、その設定が、robots.txt の出力のコードの部分で使われているようには見えない。
やはりこの設定、ぜんぜん機能してないんじゃないか？

さて、どうするか。
設定では対処できそうにないので、ぶっちゃけ、やりたくないけど、プログラムを修正し、この問題を何とかしてみることにする。

修正の方向性はふたつ考えられる。

【方向性1】の方が汎用性があるような気がするのだけれど、ざっとソースコードを追う限り、ちょっと面倒な修正になりそうだし、すべてのコンテンツの /robots.txt を書き換え、かつ、過去のコンテンツを復活させる場合も、新しいコンテンツを作る場合も、もれなく /robots.txt を置いていくのはちょっと面倒だ。
と、いう事で、汎用性は狭められてしまうけれど、【方向性2】で行くことにする。

以下の様に修正を行う事にする。

MOUNTのオプションに「sitepub={no|ok}」を追加する。
記述はこんな感じ。

「ok」の場合は「Disallow: /」を出力しない。
「no」の場合は「Disallow: /」を出力する。
設定が無い場合、上記以外の場合は「Disallow: /」を出力する。つまり、デフォルトは非公開。

一応、パッチも公開しておく。

delegate 9.9.13用パッチ

ただし、「自分が使えればいいや」レベルでの修正なので、いろいろきちんと作っていない。
使用は自己責任で。

DBD::mysqlで大ハマリしたので、メモ。

問題が発生した環境。

① CentOS 7.6
② Apache 2.4.37（自力でビルド）
③ MySQL 5.6.44（自力でビルド）
④ perl 5.16.3
⑤ DBD::mysql 4.050（自力でビルド）

各ソフトウェアは、ひとつのOS上で複数のバージョンを稼働させる必要から、yum や rpm を使わず、基本的に自力でコンパイルして動作環境を構築している。

この環境で、Apache経由でアクセスし、perl から MySQLに 接続したところ、500エラーが発生した。
エラーログを見てみると、以下の様に記録されていた。

このような組み合わせの環境構築は、これまでに何度も行っているが、はじめて見るエラーだ。
自力でビルドした DBD::mysql の共有ライブラリ（mysql.so）から、自力でビルドした MySQL の共有ライブラリ（libmysqlclient.so.18）にアクセスして、なぜかエラーになっている。どういうことだ？

とりあえず、実行環境を模擬した上で、読み込まれるライブラリを確認してみる。
問題なく読み込まれている。

LD_LIBRARY_PATH を指定しなければ、当然「共有ライブラリが見つからない」エラーになるはずだよな、と、念のため LD_LIBRARY_PATH を外して確認してみる。

が... あれ？ エラーにならない。
「/usr/lib/mysql/libmysqlclient.so.18」を読み込んでる。何これ？

確認してみると、このファイルは確かに存在している。
このディレクトリに、MySQLのライブラリをインストールした覚えはないのだが...。
これは、CentOSが標準でインストールするものだろうか。

自力でビルドしたMySQLのライブラリを確認してみる。

DBD::mysql は「libmysqlclient.so.18」をロードしようとするのだが、コンパイル時に指定した、自力でビルドした MySQL の「libmysqlclient.so.18」に接続できず、標準の「libmysqlclient.so.18」に接続しようとして、エラーになっているようだ。

しかし、「/lib」とか「/usr/lib」とか「/usr/local/lib」とかなら、自動で読み込まれるのはわかるが、「/usr/lib/mysql」が自動で読み込まれるというのは、どういうことなのだろう？
もしかして、/etc/ld.so.conf か？

ビンゴ！
このサーバには mariadb も入れてはいるが、インストールの時に、このファイルを入れた覚えはない。CentOS が勝手に入れているのだろうか。余計な事をしてくれる。

少し古い CentOS の場合、どうなっているのだろう？

mariadb ではなく、mysql として、同じ設定が入っていた。
では、この「/usr/lib/mysql」には何が入っているのだろうか。

「libmysqlclient.so.16」が入っている。
なるほどね、これまでは、バージョンが違っているから、たまたま競合しなかったのかと言う事なのか。

これは困ったぞ、どうするか...。
Apache は、DBD::mysql が共有ライブラリを読み込もうとするとき、/etc/ld.so.conf の設定に従ってしまうので、狙っていない共有ライブラリを読んでしまう。
それならば、Apacheを起動するときに、自力でビルドした MySQL のライブラリを読みに行かせるようにするしかないか。
と、言う事で、Apache の起動時の環境設定を変更する事にする。

以下の1行を追加。

Apacheを再起動。

無事、MySQL に接続できた。
ふぅ...。

このエピソードの続き。

CPUを換装してみた
CPUをオーバークロックしてみた

このPCに CentOS7 をインストールして動かしているのだけれど、どうにもシステムクロックが思うように動いてくれない。

システムクロックの進みが異常に遅く、1分で30秒も遅れてしまう。
あっという間に時刻が大きくズレていく。

この動画は、時刻がズレていく様子。上が正常な時刻、下がこのPCの時刻。
動画の開始から終了までで、上は30秒進んでいるが、下は15秒しか進んでいない。

これくらいの大きなズレがあると、chrony でも、ntp でも、まったく同期が行われない。
また、nfsマウントしてコピーなどを行うと、コピー途中でOSがクラッシュしてしまう。

仕方なしに、かなり強引だけれども、cronで次のような設定をして1分間隔で強制的に時刻調整を行うようにしてみた。

この状態であれば、ある程度は正しい時刻を保ってくれるが、時刻を再設定するまでの1分の間に30秒も遅れてしまうので、シビアに時刻管理をしていると思われるnfsマウントは正常に動作せず、やはりコピー途中でOSがクラッシュしてしまう。
また、この方法では、さまざま負荷が大きい。

もう少し負荷を軽くするならば、ハードウェアクロックの値を拾ってシステムクロックを調整するという事も考えられる。
しかし、この方法では、1分の間に30秒遅れてしまう事に変わりはないし、ハードウェアクロックを基準に時刻を調整するなんて、本末転倒なおかしな話である。
この方法では、根本的に何も解決されない。

何か時刻の進み具合をコントロールする方法はないものだろうか。
WEBを漁ってみると、VMWare や VirtualBox などの仮想環境上に構築したゲストOSで時刻が遅れる場合があり、その対処として、OS起動時のカーネルのパラメータに「clock=pit」を設定すると回避できるという記述がけっこう見られる。
試しに、OS起動時にこのパラメータを手動でセットして起動してみる。
起動時に「e」を押して編集モードに入ってパラメータ「clock=pit」を追加し、「Ctrl+x」で起動させる。

しかし、この方法では問題は解消されなかった。
相変わらずシステムクロックは遅れていく。

更に探す。
時刻を刻むための基準となる何かがあるはずだ。
マザーボードの水晶振動子か、CPUの動作周波数か、CPUのFSB絡みか、メモリとの同期周波数などか...
このPCは、CPUを換装し、更にオーバークロックもしているので、このあたりが原因としてあり得そうだが...
このあたりに関連するキーワードを含めながら、更に探してみる。
探す...探す...探す...
あった！

カーネルにおけるタイマー事情 ～第4回 タイマーハードウェアの抽象化～

Linux上で時刻を刻むための情報に「clocksource」という情報があるらしい。
むむむ、「clocksource」とは、そのままのズバリの名称ではないか。(^^;

確認してみる。

このPCで利用可能な設定は「tsc」「acpi_pm」の2種類という事らしい。

現在の設定はどうか。

「tsc」が設定されている。

試しに、設定を「acpi_pm」に変更してみる。

この状態で時刻をウォッチしてみると...
おぉ！ 時刻が遅れなくなった！
上が正常な時刻、下がこのPCの時刻。

しかし、この設定は、サーバを再起動すると元の「tsc」戻ってしまうようなので、「acpi_pm」を常態設定にする必要がある。
お手軽に設定するなら、/etc/rc.local などで、以下のような設定をしてもいいとは思うのだけれど…

ここは、起動時のカーネルオプションの設定を変更する事にする。

PCを再起動し、狙い通りに設定されているか確認する。
起動オプションに「clocksource=acpi_pm」が設定されている。
OKだ。

念のため、CentOS起動後の設定を確認する。
「acpi_pm」が設定されている。
OKだ。

chrony の同期状況を確認する。
ntpサーバの頭に「*」が付いており、同期されている。
OKだ。

更に、nfsマウントを設定し、大量／大容量のファイルをnfs経由でコピーしてみる。
システムクロックがおかしい状態では、数GBをコピーするとOSがクラッシュしてしまったが、システムクロック調整後は、何十GBコピーしても問題なくコピーが続く。
OKだ。

やっと予定通りの運用ができるようになった。
まだまだ知らない事がたくさんあるな。
まだまだ勉強が必要だ。

一連記事：

このエピソードの続き。

mSATAアダプタ・アダプタ

SSD化した事で、どの程度ディスクアクセスが変わったのかを計測してみた。

使用したツールは CrystalDiskMark。
計測した環境は以下の通り。

・OSは Windows 7 SP1 (x86)。
・Windows Update を最新まで適用。
・Security Essentialsをインストール。

CrystalDiskMark は、デフォルトの設定のまま、ハードディスクの場合とSSDの場合で3回ずつ実行して平均を取った。
結果は以下の通り。

シーケンシャル・アクセスでは、大差ない。
ランダム・アクセスでは、約20倍の速度だった。

ATA-100 のインターフェースが足枷になってたいして速度が出ないという結果を恐れていたのだけれど、まぁ、速くなったと考えていいのかな。

一連記事：

このエピソードの続き。

CentOS 5.9 + TLS 1.2

今回は、delegate でリバース・プロキシを組んでいる環境で TLS 1.2 での接続を行う。

現在の環境では、FireFoxで警告が出てしまう。

リバース・プロキシの環境では、ブラウザの接続先はプロキシ・サーバとなるため、プロキシ・サーバが TLS に対応していなければ、この警告が出る。
従って、プロキシ・サーバがロードしている openssl ライブラリを更新して対処する事にする。

現在のプロキシ・サーバがロードしている openssl は 0.9.8x。古い。(^^;

これを、新しい openssl を読み込ませるように更新する。

それでは、トライしてみる。

(1).openssl を手動でインストールする。

(2).opensslライブラリを差し替える。

この環境では、単純に delegate のディレクトリに openssl ライブラリを置く事で、そのライブラリを読むようにしている。

このシンボリックリンクを置き換える。
既存の openssl ライブラリ（0.9.8x）をバックアップする。

新しい openssl ライブラリ（1.0.2s）のシンボリックリンクを作成する。

確認する。

delegate を再起動し、ロードされた openssl ライブラリを確認する。

上記(1)でインストールした openssl 1.0.2s がロードされた。

(3).正常な鍵マークが復活！

無事、TLS 1.2 で通信された。

これでよし！

WordPress用の楽天アフィリエイト プラグインを作った。

これまで、Amazonのアソシエイトを中心に商品リンクを貼っていたのだが、Amazonアソシエイトは規約が変更され、ある程度の売上実績がないとAPIが利用できなくなってしまった。

[重要] Product Advertising API 利用ポリシーの変更について

そこで、楽天アフィリエイトにもAPIがあるので、主軸を楽天アフィリエイトに移そうと思う。

API一覧 - 楽天ウェブサービス

Amazonでは、商品のコードは「ASIN」と呼ばれる商品コードに統一されており、どのような種類の商品でも、同じAPIで「ASIN」を商品コードとする事で商品リンクが作成できた。
しかし楽天では、商品の種類によって、呼び出すAPIや商品コードの指定方法が異なるので、ここが少々めんどくさい。
とりあえず今回は、楽天市場用、楽天ブックス（書籍）用、楽天ブックス（DVD/Blu-ray）用の3種類のプラグインを作成する事にする。

また、以前に、Aliexpress用プラグインを作成しているが、この実装に合わせて、以下の様な書式で商品リンクの挿入ができるようにし、キャッシュ機能も実装する。

(1).楽天市場

楽天市場の商品では、商品コードを拾うのが少々めんどくさい。
ページのソースを開き、ソース中の以下の様な記述を探す。

商品コードは「:」で区切られていて、前半が店舗コード、後半が商品コードと思われるが、「:」も含めて全体が商品コードであるので、これを商品コードとして記述する。
小さいサイズの商品リンクも表示できる。

実際の表示は以下のようになる。

(2).楽天ブックス（書籍）

楽天ブックス（書籍）の商品では、ページ中に表示されている「ISBNコード」を商品コードとして記述する。

実際の表示は以下のようになる。

(3).楽天ブックス（DVD/Blu-ray）

楽天ブックス（DVD/Blu-ray）では、ページ中に表示されている「JANコード」を商品コードとして記述する。

Aliexpress用プラグインとフォーマットを合わせてあるので、これらを混在させて並べてもOK。

大きいサイズ。

小さいサイズ。

これでヨシ。
とりあえず、バージョン1.0。

あるWEBサイトで、最新の FireFox でSSLの警告が出るようになった。

SSLは Let's Encryptで、何か更新処理を誤ったのだろうかと思ったのだけれど、他のブラウザ（Internet Explorer 11、Edge、Google Crome）では警告は出ておらず、FireFoxのみで警告が出ている。スマホでも同様にFireFoxでは警告が表示される。
この警告が出るのは、企業のサイトでは、ちょっとマズい感じ。

この警告がどうして出るのかいろいろ調べてみると、証明書そのものも問題ではなく、プロトコルの問題のようだ。
どうやら、各ブラウザが2020年に TLS 1.0、TLS 1.1 での接続ができなくなるように動作が変更されるようなので、FireFoxは、その事前警告を出しているようだ。

このWEBサイトはレンタルサーバで、OSは CentOS 5.9。
root権限が貰えているサーバであるけれど、テスト環境があるわけではないので、様々アップデートをかけるのは少々リスクが大きい。なんとかWEBサーバのみに影響範囲を抑える形で対処したい。

いろいろ悩んで、以下の方法で対処する事にした。

① 最新のopensslをユーザ領域に手動でインストールする。
② Apacheの起動スクリプトを修正し、上記(1)でインストールしたopensslをロードさせるようにする。

それでは、トライしてみる。

(1).opensslを手動でインストールする。

稼働しているApacheは、古いバージョンのライブラリをロードする様になっている。
Apacheを再コンパイルするなどすると影響が大きいので、インストールしたライブラリのバージョンを偽装する事にする。

(2).Apacheが上記(1)でインストールしたライブラリを正しくロードするか、依存関係を確認してみる。

まず、通常の起動。
/usr/lib 配下のライブラリがロードされる。

次に、上記(1)でインストールしたライブラリをロードさせての起動。
上記(1)でインストールしたライブラリがロードされた。

よし、いけそうだ。

(3).Apacheの起動スクリプトを修正する。

Apacheの起動部分に、LD_LIBRARY_PATHでopensslのパスを挿入する。
これにより、上記(1)でインストールしたライブラリは、Apacheに限定して使用される。

(4).Apacheを再起動する。

が、残念ながら、phpのモジュールのロードでエラーが発生してしまった。

がんばってphpの再インストールもトライしようかと思ったけれど、このWEBサイトではphpは使用していないので、phpのサービスを停止する事で対処する事にした。

(5).サーバのコントロール・パネルでphpのサービスを停止する。

(6).再びApacheを再起動する。

成功した！

(7).正常な鍵マークが復活！

無事、TLS 1.2 で通信された。

これでよし！

会社の開発サーバにおいて、Apache に設定する仮想ドメイン <VirtualHost></VirtualHost> は頻繁に設定を追加／削除する。
新しいプロジェクトが立ち上がれば仮想ドメインを追加、プロジェクトが終了すれば削除、プロジェクトが再開すれば設定を復元。

これまでは、以下の様に設定して運用していた。

Apache の「httpd.conf」では、以下の様に仮想ドメインのまとめ設定ファイル「vhosts.conf」をインクルードしておく。

読み込む「vhosts.conf」では、以下のように必要な仮想ドメインの設定ファイルをインクルードする。
不要な仮想ドメインは「#」でコメントアウトされている。

その上で、ディレクトリ内に置かれている仮想ドメインの設定ファイルを置いておくのだが、ただ置いただけでは、どの仮想ドメインが現状で有効であるのかわかりにくいため、archives ディレクトリを作成して、無効なドメインは移動して隔離していた。

仮想ドメインを追加／削除／復元するには、vhosts.conf の記述を変更した上で、仮想ドメインの設定ファイルを archives ディレクトリから移動し、Apacheを再起動していた。

十分簡単だとは思うのだけれど、もう少し簡単にならないだろう。
ん～と考えて、はっと気が付いた。
Include ディレクティブって、ワイルドカード（*）が使えるじゃないか。

と、言う事で、以下の様な設定での運用に変更。

Apache の「httpd.conf」では、以下の様に仮想ドメインのまとめ設定ファイルをインクルードしておく。
「+」が付いているのがミソ。

その上で、以下の様に仮想ドメインの設定ファイルを配置する。
先頭が「+」である設定ファイルのみが読み込まれる。

仮想ドメインを追加する場合は、先頭が「+」の設定ファイルを作成して置く。
仮想ドメインを削除する場合は、先頭の「+」を「-」にリネームする。
仮想ドメインを復元する場合は、先頭の「-」を「+」にリネームする。
その上で、Apache を再起動する。

仮想ドメインが有効か無効かは、ファイル名を見るだけでわかる。

なんてことない技だけど、これでずいぶん運用が楽になった。(^^)