「ドメインサービス」ページのリニューアル第一歩！

当社は、ドメインとサーバーを提供するサービスであるが、
ここ数年間、新規のお客様の募集をしてこなかった。
ストックビジネスなので、既存のお客様からの安定収益があれば、
特に大きな投資等を行わない限り、何とかやっていけるからである。

でも今年は、サーバー代の仕入原価がものすごく高騰していたので、
さすがに値上げしないと利益を圧迫するようになってきた。

特に、ドメインについては、値上げと円安のダブルパンチで、
事業開始時の２倍以上に膨らんでしまった。
ドメインの種類によっては、既に赤字になっているものも出てきた。

というわけで、新規のお客様を募集するのにあたって、
ウェブサイトを作り替えることにした。

値上げについては・・・新規のお客様に適用すればよく、
既存のお客様は据え置きにしようと思う。
これは当社の創業時以来の変わらぬポリシーで、

新規の見込客にキャンペーン適用するよりも、
既存のお客様にキャンペーン適用するべきだ！

という凝り固まった考え方による。

それはさておき、サービスのリニューアルについては
ＡＩを通さずに、まず自分でいろいろと考えてみた。

３０年前の創業時とは時代が変わっていて、
今や高品質の大手サービスが乱立している時代なので、
当社のような零細企業は、同じ土俵で勝負しても仕方がないのだ。

ＡＩ（Gemini等）に、当社の強みについて尋ねてみると、
ホームページの文言を拾ってきて、
非セルフサービス型の個別対応サポートが得意、というような回答が出てくる。

電気屋さんに譬えてみれば、
全員が安さを求めて家電量販店やネット通販を選ぶとは限らず、
値段は高くても近所の街の電気屋さんで買う、という人も一定数いるのだから、
そういう人だけに絞り込めばよいことになる。

一般的に、ドメインとサーバーの業者を探す場合、
普通に探せば、つまり Google検索やＡＩのプロンプト入力で探せば、
大手の人気サービスが出てくる。

「自分で検索して探して比較検討できる」ということができる人は
大手の人気サービスを選ぶのが正解だけれども、
そういうことが苦手で「お任せしたい」という人も、いる。

そういう人向けのページを作らないといけないな、と思う。
とりあえず入り口の１ページ、ランディングページを作るのにあたって、
Geminiに相談してみた。

入力したプロンプト：

合資会社ユースマネージメントのドメインサービス事業部のホームページ
https://www.domainservice.jp/
を、新設の「ドメインサービス」という定番サービスのランディングページにしようと思います。
このサービスについて。
・ドメインを独立して管理するための１年間のサポート込みのサービス
・ＤＮＳまでは付いているが、ホスティングサービスは別。
・錦の御旗は「ドメイン独立宣言！」。旗の画像をバナーに使用。
・ドメインはサーバーのおまけではない、の主張。
・今こそ、ドメインだけを独立して管理しよう、という掛け声。
ランディングページのただき台をつくってみてください。

出てきた画像：

最初、誤字があったので何度か作り直しているが、これを少しだけアレンジして載せてみた。

ドメインサービス
https://domainservice.jp/
https://ドメインサービス.jp/

後は、少しずつ完成させていこうと思う。

サーバーを変更したら、フォームメール（ postmail.cgi ）のCGIが動かなくなった件

 サーバーマシンを新しいマシンへ変更すると、CGIやPHPのスクリプトが動かなくなるケースが多い。
特にCGIの場合、古いものを使っていることが多く、仕様が変わっていたりするケースもある。

さて今回、新しいマシンでフォームメールが「500 Internal Server Error」が出て動かなくなってしまう、という事象が出た。
このエラーだけだと詳細が分からないのでとりあえずログを見ると、

「End of script output before headers: postmail.cgi」

というエラーが出ていた。
何らかの理由でCGIスクリプトが異常終了した、ということなのだろうが、これでも原因が分からない。
こうなると、SSHでコンソールで、直接コマンドを入力して実行してみるしかない。

./postmail.cgi

と入力したら、

「Can't use 'defined(%hash)'   jcode.pl line 684」

というエラーメッセージが出てきた。
どうやら、postmail.cgi から呼び出される jcode.pl の684行目に問題があるらしい。

さっそく Google検索で、このエラーメッセージ
「Can't use 'defined(%hash)'   jcode.pl line 684」をそのまま入れてみると、

次のような答えた返ってきて、そのとおりに修正したら、見事にcgiが動作した。

従来のGoogle検索だけでも探せば答えにたどり着いたかもしれないけれども、
解決策がストレートに出てきたのは嬉しい。

以下、GoogleのAI回答：

Plesk Migratorでエラーが出て移行が開始できない！

Pleskで管理しているサーバーを新しいマシンへ移行する時、
新しいマシンもPleskならば、「Plesk Migrator」という機能を使って、
全自動で移行を行ってくれる。差分移行もできるので、とても便利だ。

本日、試しに１台、移行をやってみたら、最初にエラーが出て進まなかった。
ここ数年で、セキュリティ関連の制限が厳しくなったので、
古い方のマシンの場合、うまく動作しないことが多い。

今は、ＡＩという便利な相棒がいるので、さっそく活用してみることにする。

今までは、Googleにエラーメッセージをそのまま入れて検索したりしたけど、
今は、同じことをやっても、きちんとＡＩの回答が出てくるようになった。
この回答で十分なケースもあるけれども、より深い回答を得るためには、
やはり Gemini や Copilot の専用ページから入力した方が効率がよい。

さっそく入れてみたプロンプト：

plesk migrator実行後に次のエラーで失敗します。

Failed to fetch basic information about resellers, clients and domains data from source servers Cause: Command execution failed on the local server with non-zero exit code. command: rsync -r --chmod=Fu=r,Du=rwx,go= --timeout=30 -e 'ssh -i /usr/local/psa/var/modules/panel-migrator/sessions/20260703203631/ssh-keys/id_rsa.xxx.xxx.xxx.xxx -p 22 -o PasswordAuthentication=no -o StrictHostKeyChecking=no -o GSSAPIAuthentication=no' /usr/local/psa/admin/plib/modules/panel-migrator/backend/lib/python/parallels/plesk/source/legacy/extras/plesk_17_0_pmm_shared/ root@xxx.xxx.xx.xx:/root/plesk_migrator/plesk_migrator-7l9u3nzyui3jq8lnikx0b4zdfb2fbty1/pmm_agent exit code: 255 stdout: stderr: root@xxx.xxx.xxx.xxx: Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password). rsync: connection unexpectedly closed (0 bytes received so far) [sender] rsync error: unexplained error (code 255) at io.c(232) [sender=3.2.7] That is a critical error, migration was stopped.

以下、AIによる回答：

エラーログの提示をありがとうございます。原因がはっきりと特定できました。

発生している Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password) というエラーは、「移行先（Obsidian）から移行元（Onyx）へ、自動生成したSSH公開鍵を使って接続しようとしたが、移行元サーバーに拒否された」ことを意味しています。

Plesk Migratorは、最初にパスワードで接続が成功した後、高速なデータ転送（rsync）を行うために専用のSSH鍵を生成して移行元に配置しますが、その鍵認証の段階で弾かれています。

この問題は、以下の3つの対処法のいずれかで解決する可能性が非常に高いです。順番に確認・実行してみてください。

対処法1：移行元（Onyx）のディレクトリ権限（パーミッション）を修正する

移行元サーバー側の /root や .ssh ディレクトリの権限がセキュリティ的に緩すぎると、SSHの仕様により鍵認証が強制的に拒否されます（これが最も多い原因です）。

【手順】移行元（Onyx）サーバーにSSH（root）でログインし、以下を実行します。

Bash

# /root ディレクトリの権限を修正

chmod 750 /root

chown root:root /root

# .ssh ディレクトリの権限を修正

chmod 700 /root/.ssh

chown -R root:root /root/.ssh

# authorized_keys の権限を修正

chmod 600 /root/.ssh/authorized_keys

設定後、再度 Plesk Migrator を実行してみてください。

対処法2：移行先（Obsidian）で古い暗号方式（ssh-rsa）を許可する

Plesk Onyxが動いている古いOS（CentOS 7など）と、Plesk Obsidianが動いている最新OS（AlmaLinux 9やUbuntu 24.04など）では、安全なSSHの暗号方式の基準が異なります。最新OS側（移行先）のSSHクライアントが、古い暗号方式（ssh-rsa）を拒否しているケースです。

【手順】移行先（Obsidian：新しいサーバー）にSSHでログインし、以下を実行します。

1. /etc/ssh/ssh_config をテキストエディタで開きます。
2. ファイルの最末尾に以下の1行を追記して保存します。
   Plaintext
   PubkeyAcceptedAlgorithms +ssh-rsa

 (※OSのバージョンによっては PubkeyAcceptedKeyTypes +ssh-rsa の場合もありますが、まずは上記を試してください)

1. 保存後、移行先サーバーで再度 Plesk Migrator を実行します（クライアント側の設定なのでSSHの再起動は不要です）。

💡 おすすめの対応手順

まずは手軽かつ安全な 「対処法1（パーミッション変更）」 を試してください。それでも改善しない場合は、OSの世代ギャップが原因である可能性が高いため、 「対処法2（暗号方式の追加）」 を行うことで、多くのケースで解決します。

サーバー冗長化（二重化）の再検討と、新たな挑戦

インターネットのサーバー障害で非常に困ってしまうことは、
一般ユーザーの場合、

・メールが届かなくなる、または送信できなくなる
・WEBサイトが開かなくなる
・WEBサイトが更新できなくなる

ということになる。

ところが、WEB上で何かの業務サービス等のサイトを営んでいる場合、
長時間のサーバー障害は、ちょっとやそっと困ったというレベルではなく、
ダメージがケタ違いに大きくなる。

インターネットのサーバーは、
障害ゼロ、つまり稼働率１００％というのは、現実的には不可能であるが、
それでもなるべく稼働率１００％に近づけるために、さまざまなアイデアや工夫がある。

基本的な手法として「冗長化（じょうちょうか）」というのがあり、
障害にそなえてあらかじめ予備を作って二重化しておく、という考え方である。

当社のサーバーは、安くもなく高くもないフツーなレベルだと思うけど、
今回の大障害を大反省して、トライ＆エラーを繰り返しながらも、
絶対に安全で信頼できるサービスを提供していきたい。

当社の強みは、この３０年間に築いた、苦難に満ちた実体験、の存在である。
お金をそれほどかけなくても、独自のアイデアでサーバー冗長化を実現する知恵は、十分にある。

実は、過去にも、同じことを考えてやっていたことがあったが、
なぜ今、止めてしまって、また同じ大障害を繰り返してしまったのか？
という反省をしなければならない。

サーバーを二重化して障害を防ぐためには、両方のサーバーの状態が
常に最新状態になっていなければならないと、障害時に役立たない。
簡単なようで、それができていなかったのだ。

お客様も、最初は、障害に備えて、両方のサーバーを最新にしてくれているが、
障害が全くなく何年も安定稼働が続くと、そんなことは忘れてしまう。

当社側も、ＧＭＯ社の「クラウドＶＰＳ」は、もう何年も障害がなく、
安心しきっていたので、肝心の予備サーバーが放ったらかしになっていて
いざという時にあまり役に立たなかった、という失策があった。

古いサーバーのままになっていたので、

・ＳＭＴＰサーバーが SPFとDKIMに対応できていない
・Let's Encryptの更新ができないのでＳＳＬ接続ができない

等の問題が露呈した。
これらがきちんと機能していれば、予備サーバーとしてきちんと機能していたはず、である

なので今回、暫定対応できたのは、

・メール転送機能
・障害のお知らせ（お詫び）ページの掲載（ただしＳＳＬ無し）

だけだった。

ということで、今回は、きちんと代替えできる予備サーバーを整備して、
本当の二重化に挑戦しようと思う。

技術的な話をすると、
メールサーバーについては、ＤＮＳのＭＸレコードを２つ入れておけば二重化ができるが、
ＷＷＷサーバーについては、少し工夫が必要になる。
ＤＮＳにＡレコードまたはＣＮレコードを２つ入れておくと
ラウンドロビン（交互に接続）になってしまうので、それはうまくない。

今回契約した ClouDNS というＤＮＳサーバーを使うと、
IPフェイルオーバーという機能で、障害時に切り替えることができるらしい。

無停止を希望するお客様には、これを選択できるようにすればよいが、
その代わり、２つのサーバーの内容を最新に保つ運用が必要になる。
障害時は暫定ページを表示されればよい、というお客様もいると思う。

とにかく、メールとＷＥＢがなんとかして二重化できていれば、
サーバー障害が起きてもそれほど困らないので、
ワクワクするようなサービスを安心して使えるはず、である。

この独自性のある仕組みを、これからの標準装備としようと思う。