Windows Server の証明書サービスを復旧させる方法

amatsukami.jp サーバの SSL 通信部分はボクしか使わないため、オレオレ証明書を使っている。この証明書はボクが勝手に発行したので、他人がブラウザで開くとエラーが出る。ボクのためだけの物なので今の所は問題が無い。
でね、この勝手に証明書を発行するシステムが Windows Server にはあるわけだけど、ftp の証明書の期限が切れていたので更新しようとしたら更新ページがエラーで表示されない。なんだこれ?? 何かいじったかなと思っていじって見るも特に設定は問題なさそうに見える。

エラーの内容は、web.config ファイルが見つからない的な内容なのだが……う~ん、あるよなぁと思っていろいろ調べて見ると、本来あった場所の web.config を見に行かずになぜか C:\Windows\System32\certsrv\ っていうフォルダを参照しに行ってた。

なんだこりゃー!?

何かのパッチでそういう設定に変わったのかしら? Windows Server 2016 や 2019 がそうなってるとか?

そんなわけで C:\Windows\System32\certsrv\ に関係するファイルをコピーしたら普通に動くようになった。もー!

もう一つトラブル事。今、仕事で組んでいるシステムがだいぶ完成してきて、色んな人がアクセスするようになった。ボクはサーバ上のファイルを直接編集していたんだけど、それだとボクのミスでうまく動かなかったりすることがある。そんなときに他の人がアクセスしに来ると、動かないぞってことになってしまう。

そこでボクの開発機にウェブサーバを立ち上げて、開発はそこでやることにし、今のサーバはちゃんと動くものだけ更新することにした。そこで自分のマシンに IIS を入れて PHP を入れて MySQL を入れたんだけどこの時、MySQL の Version 8 を入れてみたのね? SQL 文なんてのは共通だし、別に何か問題が起きるなんてことはないだろうと思って、この新しい開発環境に今まで開発してきたソースファイルをぶっ込んだから、いきなり動かないwww

おい。

エラー内容は SQL 文の Syntax エラー。構文エラーだ。単純にスペルミスとかそういう系のミス。えー、そんなバカな、ちゃんと動くソースですぜ? 間違ってるわけないじゃん、と該当する SQL 文とにらめっこするもどこがおかしいのか全く解らない。
そりゃそうだ、元の環境では動くんだもの。

これは MySQL5.6 系と 8 系で何か根本的なことが変わったのか?
とはいえ SQL 文は規格化されていて、MySQL のバージョンが上がったからと言って勝手に変えていいものじゃない。まぁでもダメ元で調べて見たら、MySQL 8 から新しい内部関数が増えていることが解った。そしてその増えた関数の名前が今回のシステムで使っているカラム名と同じだったのだ。
つまり MySQL はそれを命令だと解釈していたため、エラーになっていたのである。
もー!

解決策はこのカラム名を別の名前に変えるか、カラムを必ず ` で囲むか。
まぁ開発中のものなんでカラム名を変えたので良かったのだけど、ボクの中で意味が定着してしまっていて他の単語がすぐにおもいうかばなかったので `で囲んだ。すると問題なく動いた。

下の写真は大戸屋のカツ煮定食。大戸屋ってセントラルキッチンじゃないのでカツ煮もホクホクとイイ感じのが出てくるんだろうなと思って頼んだんだけど、脂でベチョベチョのカツだった。残念。

SMB3.0 とか金融とか kobo とか

ボクはウェブサービス以外で自宅のサーバとやりとりするときは VPN をつないでやっているのだけれど、PC はともかく(起動時に VPN を勝手につなげるようにできるので)、モバイル端末ではイチイチ VPN 接続してからサーバにアクセスしなければならない。それに、VPN 分のオーバーヘッドも発生する。

VPN 経由で主に使うサービスはなんと言ってもファイル サーバだ。サーバ上にある様々なファイルにアクセスしたいわけだ。なので、Windows の共有フォルダがそのままインターネットで使えれば、VPN を経由しなくてもすぐに使える。

SMB3.0 から、それが可能になった。いや、今までも可能っちゃぁ可能だったんだけど、セキュリティ的にお粗末な実装だったため、とてもじゃないがインターネット網に出すわけには行かなかった。

と言うわけで、ちょっと自宅サーバの SMB をインターネット網に出して見た。

接続速い! ファイル転送も速い! いいじゃんコレ!!

でもねぇ、色々懸念点はある。この SMB は過去何度も攻撃対象にされてきた。SMB の穴を攻撃するマルウェアもたくさんある。そのため、市販のルータは SMB で使うポートを塞いでいることが多い。今回もボクの自宅のルータが SMB のポートを塞いでるせいで最初アクセス出来なかった。

もう一つ、SMB に対する世間の印象も悪いことが挙げられる。過去、そうやって漕ぐ駅対象にされたおかげで、とにかく SMB が使うポートは必ず塞ぐのが基本という習慣がすっかり定着してしまっているのだ。なのでボク自身は、ボクのルータの設定だけで住むが、他人に「ここにアクセスしてー」って手軽に渡せる代物ではないのよねぇ……。

まぁでもとにかくできることは解ったので、今後、使用する方向で検討していきたいと思っている。

金融の記事、時々見るけど、そもそも言葉がサッパリわからないんだよね。
みんな解ってて読んでるのかなぁ? ボクはサッパリ解らないや。上記の意味も、もー、何が何だかサッパリだ。で色々調べた結果、とある企業の株価が急激に下がったりしたときのための保険みたいなのがあって(ヘッジとクレジット デフォルト スワップ)、その保険料がすげー値上がりしてる(つまりその企業はいよいよヤバいって事)、っていう意味らしい。レーバーデー開けってのはアメリカの休日明けで、要するに休み明けにクレジットデフォルトスワップの値上がりがすげーカーブを描いてて、倒産は誰しもが解ってたんじゃないの? っていうような記事だった。

秋葉で画面解像度が 1920×1200 の Android 端末2999 円で売ってたので買ってきた。何に使うかというと、これで Windows でデュアル ディスプレイをやるのだ。会社の開発機は、1920×1200 のパネルが二枚あるんだけど(NEC と EIZO)、自宅は 1920×1200 が一枚しかないのだ。

そして反応速度に難はあるが、動画をずっと再生して奥分には問題なし。
ただ、7 インチに 1920×1200 は業務では文字が細かすぎて使えなかったww

リバースプロキシの基本がわかってない(ぁ

さて、昨日は古い PHP で動く旧コンテンツを、リバースプロキシApplication Request Routing)を使って別のサーバに追い出すことに成功した。ということはだ、今別サーバで色々動いているものが、少なくとも見た目上は一つに集約できるのではないかということに気づく。

今、Redmine(プロジェクト管理)やグループウェア(Aipo)なんかが動いてはいるんだけど、それらは全部 HTTP でやりとりするのね。しかも Windows で動かすと全部独立したサービスで動くため、これらを一つの HTTP で動かすわけにはいかないという状況だ。

そこでどうしているかというと、不特定多数の人がアクセスするサービスはデフォルトに割り当て、ボク一人で使っている Redmine やグループウェアは TCP ポート番号を分けることによって使い分けていた。
たとえば、https://amatsukami.jp:9999/ なんて感じだ。でもこれはデフォルトの動作じゃないし、見た目もよろしくない。

リバースプロキシを使えば、https://amatsukami.jp/redmine/ ってやると https://amatsukami.jp:9999/ にアクセスするように設定できる。こうすることによって、全て https://amatsukami.jp/ で完結できる。

というわけでさっそく一番使用頻度が高いグループウェアで設定してみようとするんだが、これがうまくいかない。ホスト名が一致しないのだ。
どういうことかというと、リバースプロキシ経由になるということは、グループウェアにアクセスしに来るのはリバースプロキシと言うことになる(アクセス経路は以下の通り)。

ユーザ → リバースプロキシ → グループウェア

リバースプロキシとグループウェアは LAN 内で結ばれていて、お互い LAN 内の名前(ホスト名という)で呼び合っている。この LAN 内のホスト名はインターネットの世界では通用しない。でもグループウェアは呼ばれたホスト名で応答するように作られており、リバースプロキシは LAN 内でしか有効でないホスト名をそのままユーザに返してしまうため、インターネット網にいるユーザは結局アクセス出来ないのだ。

じゃぁ旧コンテンツはどうしているのかというと、旧コンテンツのエンジンである Pukiwiki Plus ! は返すホスト名を固定できるのだ。このホスト名をインターネットで通じる名前にしておけば問題ないというわけである。
ところがボクが使っているグループウェアにはこの機能が無い。
ただこの時、ボクはグループウェアの方に着目してしまったのよね……これが遠回りの原因になってしまった。グループウェアはオープンソースなもんだから、ソースとかを見始めちゃったのよね……orz
結局、この日は解決することができなかった
(正解はリバースプロキシ側に、ユーザがアクセスしてきた時のホスト名のままでアクセスするという設定があるのだった)

下の写真は浅草橋で一番美味しい(とボクが思い込んでいる)、ろく月の豚白湯麺とチャーシュー丼。うまいー!

リバースプロキシって便利!

TAMA Networks の旧コンテンツは Pukiwiki Plus ! というシステムで動いている。コイツは PHP 5.2 じゃないと動かない。5.3 以降では動かないのだ(どうも動くらしいのだが、IIS ではセキュリティ関連の機能がまったく働かない)。そのおかげで、amatsukami.jp サーバはずっと PHP を更新できないでいる。そうこうしているうちに PHP は 7 になってしまった。

一方、現在の TAMA Networks は WordPress というシステムで動いていて、これは現役のシステムであり、バージョンアップもされている。
そしていつかは WordPress が PHP5.2 では動かなくなるはずだ。現に WordPress のプラグインなどは 5.2 で動かないものもチラホラ出始めている。
しかし、先の Pukiwiki Plus ! のおかげで、こちらは PHP のバージョンを上げられない。
何かいい方法はないものか? と、色々考えたあげく、二つの方法を思いついた。

  1. amatsukami.jp サーバで複数のバージョンの PHP が動くようにする
  2. リバースプロキシを使って、Pukiwiki Plus ! を amatsukami.jp サーバから追い出す

と言うわけで①を試そうとしたんだが、IIS7.5 ではこれがどうもうまくいかない。
いや、7.5 でもできると思うんだけどなぁ……。結果的に旧コンテンツが動かなくなるw
そこでやる気を失って放置してたら、ウェブサーバが落ちたwww
どうやら旧コンテンツの実行にものすごく時間がかかるようになってしまったためで、旧コンテンツそのものにアクセス出来ないようにしたら、復活した。

これが 9/11 頃である。

その後も①に色々挑戦するも、何故かうまく動かない。まぁ amatsukami.jp サーバは 6 年も稼働し続けているし、その間、いろんな設定ミスだのなんだのをしてきたから内部がけっこうヤバいことになっているのかもしれない。
さっさと新しいサーバに移行しなければ……という結論には達するものの、技術的な勉強も兼ねて仮想サーバ(こちらは IIS8.0)に PHP を 2 バージョン(5.2 と 7)をセットアップした。するとすんなり両バージョンで PHP が動くではないか。なのでこの設定をそっくりそのまま amatsukami.jp サーバに持ってくると……やっぱり動かないorz
う~む、やはり amatsukami.jp サーバが怪しいんだなぁ……(実は PHP の設定が不味かった)。

そこで amatsukami.jp サーバにリバースプロキシを設定する。そして https://amatsukami.jp/scripts/pukiwiki/ 及び https://amatsukami.jp/pukiwiki/ にアクセスしに来たら、それは仮想サーバの Pukiwiki を呼び出すように設定した。
と言うわけで上のメニューにある「今は昔」のリンク先は amatsukami.jp サーバではなく、仮想サーバで動いているコンテンツだったりする。

将来的にサーバを新調したら、どっちの方法でやるかは悩むな。サーバを新しくしたら当然そっちでは複数のバージョンの PHP が動かせるはずだ。となれば別にリバース プロキシに頼らなくてもよい。
ただ将来的な設計で、ロードバランサなどを置く場合は、そもそも全てのサイトがリバース プロキシでの運用になるだろうし……。まぁそれはその時になったら考えよう。

下の写真はシャンブラとボクが勝手に呼んでいる『上海ブラッセリー』の塩やきそばと半チャーハン。ここのチャーハンは紅生姜が入っているのが特徴だ。半チャーハンの写真がフタルあるのは、ここ、半チャーハンはお代わり自由だったんだけど、それがなくなり、「普通」「大盛り」「特盛り」が選べるようになった。その大盛りと特盛りの比較写真が、チャーハンが二つ並んでる写真だw
あくまでも半チャーハンの大盛りと特盛りなので、大盛りが普通のチャーハンくらいの量だと思ってもらえれば間違いないと思われる。ただし、残っているチャーハンの量に影響されるのか解らないが、けっこう日によって量は違ったりするw

ようやっとドメイン・コントローラが 2 台体制になる

bs_zuho01k
3/4 に組み始めたサーバを、ようやく本社に設置した。長かった~~。とはいえ、3 月の中旬頃からしばらく放置していたが(ぁ
結局、RAID-5 として運用すると飛ぶという現象はマザーボードが不良品だと言うことで、マザーボードを買い直したらあっさりと動いた。まぁ、そんなもんですよね、えへへ。そしてこれでようやく会社の LAN 体制が一段落した。長かったー! 思えばこの LAN 体制にしなくちゃと思ったのが、2012 年の 10 月だからなー。実に 1 年半後に実現である。

どういう体制かというと、ウチの会社は本社と第二開発室に別れている。で、この本社と第二は VPN によって結ばれているのだが、本社にはサーバがないため、本社から第二のマシンにアクセスするには IP アドレスを直打ちするしかなかった。しかも基幹サーバは第二側にあるのだ(2012 年の 10 月に設置)。ちなみにこの第二の基幹サーバの名前は KUROHA という(ぁ
そして、第二側にも問題があった。ドメイン・コントローラというか社内 LAN の名前解決をするサーバがこの KUROHA しかないため、KUROHA が何らかの理由で動いてないとき、社内 LAN のマシン名を解決できないのだ。一応仮想サーバ上にドメイン・コントローラ(TETMET という)は立ててあるのだが、これは KUROHA 上で動いているので KUROHA が落ちたら TETMET も落ちてしまい、何の意味もない。
今回、本社にドメイン・コントローラを設置したことにより、KUROHA が落ちても本社のサーバが名前解決を提供するので、第二側の問題もこれで解決したのである(VPN はルータ同士で張っているので、KUROHA や本社のサーバが落ちても切れるということはない)。

ところでこの KUROHA は元々 GLacé / Galette のエロゲ部隊が伝うために立てたサーバで、コンシューマ/パチスロ部隊はまた別のサーバを用意する予定だった。そしてさらに本社側にもサーバを立てるというのが当時のボクの構想だ。なので本当はあともう一台サーバが必要と言うことになる。

まぁとにかく、本社側にサーバが立ち、さらにドメイン・コントローラ(DC)が本社に置かれることにより、ネットワークのセキュリティが本社と第二で統一され、さらに DNS も置かれたので、マシン名で第二のマシンにアクセス出来るようになった。
これで色んな人から「KUROHA にアクセス出来ない」って言われなくて済むー。
しかも本社に置いたサーバは 8 コアの CPU だじぇ。仮想マシン、いっぱい動かせるじぇ!

こうやっていろいろいじっていると、インフラって楽しいよね、と思う。

サーバをまた組む

rural_sy00e
本社用にサーバを作っても良い(というか作って欲しい)という要請があったので、サーバを一台組んだ。ボクの職場は本社の他に開発室が二つあり、ボクは二つ目の開発室で働いている。この二つ目の開発室には、2012 年の 10 月にくみ上げたサーバが稼働中である(Windows Server 2012)。
で、本社には昔から会社の人が立てたサーバがあるのだが、こちらはファイルサーバと FTP しか提供しておらず、本社と他の開発室が VPN で繋がっているのに名前が引けなかったりと色々不便があったのだ。そのため、前々から本社にサーバを置きたいなと思っていた。

というわけでさっそく秋葉へ……!
今回も AMD で行かせていただきます(ぁ

  • CPU -> AMD FX-8320 (8 Core / 3.5GHz / TDP125W)
  • Mother -> ASRock 970 Extreme3 R2.0
  • Memory -> DDR3 16GB (8GB x 2)
  • HDD
    • TOSHIBA DT01ACA050(500G / SATAII / 7200) x2  -> システム用&仮想マシン用
    • HGST HMS5C4040ALE640 (4TB / SATA600 / 5400) x 3 ->データ用

本社の基幹サーバということで、将来的に様々なサービスを提供することを考え、前回よりも CPU がリッチに。また仮想マシン用の HDD も専用の 7200rpm のものを用意した。そして今回、ケースも頑張った! TDP が 125W だと聞いて、風通しのいいケースに。Antec の P280 というケース。色んな所に穴が開いていて、さらにファンもたくさんついている。
さらに HDD の所にもファンを 2 個追加した。というか、このケース、かなり気に入った。amatsukami.jp も次期サーバを組むときはこう言うのにしたいなぁ。ただこのケース、大きい上に電源が下においやられていて、けっこうケーブルが届かないという場面が(汗)。というかそのことを組んでる途中で気づいた。最初から解っていれば、ケーブルの取り回しとかを考えながら組んだのだが……ちょっとそこが失敗。

さて、くみ上げもスムーズ行き、OS インストールも滞りなく終わり、4TB の HDD で RAID-5 を設定し、そのまま放置していたらいつの間にかサーバが飛んでいた。おお? なんだー?
とりあえず原因を探るためにイベント ビューアを開くがそれらしいイベントは記録されていない……。そこでもう一度放置してみると、6 時間くらいで飛ぶことが判明。ただこの時、すぐ原因に行き着くことはできた。と言うのも、RAID-5 を組む前は 6 時間以上動いていたからだ。
ただ、ここからが長い戦いの始まりだった。なにせ 1 回の検証に 6 時間かかる。何かの設定などを変えてその結果が出るのが 6 時間後なのだ。そこで解ったのが、以下のことだ。

  • SATA03 ポートに挿すと、HDD を認識しなくなることがある
  • RAID-5 の時だけ飛び、普通に使っている分には飛ばない

ところが、SATA03 を使わなければいいのかというとそう言うワケでもなく……。
結果的にマザーボードの不良品という所に行き着いたのだが、なんだかんだでこのサーバを実際に本社に設置するのは 4 月になってしまうのであった……orz
こういう不具合は原因特定が非常に時間がかかるなぁ……。
140304DSCF5933 140304DSCF5936
140304DSCF5938 140304DSCF5940
140304DSCF5942 140304DSCF5945
140304DSCF5946 140304DSCF5948
140304DSCF5951 140304DSCF5955

Windows Server 2012 R2

本社が新しい開発室を立てたので、そこのサーバを作ることになった。
おぉ、Windows Server 2012 R2 を試すちゃーんす! Windows Server 2012 R2 はいわゆる Windows 8.1 のサーバ版。はてさて、どんな風に変わっているのか……って思ったんだけど、今回のサーバは別に大したことはしないので、あんまり違いを感じることはないかも(汗)。

まずは土曜日に秋葉にパーツを買いに行った。今回は会社でいらなくなったマシンが与えられ、サーバとして足りない部分を買ってくると言う感じ。会社でいらなくなったマシンは Core i3 マシンで、ビデオ・カードとして Radeon HD5770 が刺さっていた。とりあえず Core i3 ではコア数が足りないし、なぜか Micro-ATX マザーだったので、マザボと CPU と、そして HDD を買うことにした。
構成は以下の通り。

  • CPU -> AMD FX-6300 (6 Core / 3.5GHz / TDP95W)
  • Mother -> ASRock 970 Extreme3 R2.0
  • Memory -> DDR3 16GB (8GB x 2)
  • HDD
    • HDT722516DLA380 (160G / SATAII / 7200) -> マシンに最初からついていた
    • HDS724040ALE640 (4TB / SATA600 / 7200) x 3 ->データ用
    • MK8037GSX (80GB / SATA150 / 5400) -> 自宅に余っていた東芝製 2.5 インチ。仮想サーバ用

日立の 4TB を 3 台買ってきて、それに RAID-5 を組むという目論見である。
CPU に AMD を選んだのは単純にボクの伝統である。ボクはずっとサーバには AMD を使ってきた。また、コアが多くて安い CPU が AMD ってのもある(汗)。

組み立てと OS のインストールはすんなりと終わった。次に RAID-5 の構築に取りかかる。これは Windows Server についているソフトウェア RAID を使う。ここからが、長い戦いだった。RAID-5 の同期がまったく終わらないのだ。
土曜日にパーツを組み立て、日曜日の未明からはじまった同期が日曜日が終わっても 40% とか。マジデスカ!? RAID-5 の同期は確かに RAID の中では遅い方だけど、Windows Server の RAID-5 ってそんなに遅いの!? なんだこれー?
しかもね、色々と設定しているとサーバを再起動することがあるんだけど、なんどか再起動してたら、同期が 0% に戻った……orz。えー……。

そんなこんなで、なんと、このサーバを新しい開発室に置けたのはさらに一週間後になるのであった。恐るべし RAID-5……。ところで最後の空の写真は何かというと、2/1 の明け方に知人を送り届けたとき、たくさん鳥が飛んでいたので思わず撮ってしまったものだ。鳥の種類は解らない。
知人の話によると、この近くの寺院に大量の鳥が住み着いていて、それが飛んで来ているのではないかという推測があるらしい。
140202DSCF5861 140202DSCF5863 140202DSCF5864
140202DSCF5865 140202DSCF5868 1402010402