windows

WindowsとCertbotとSSL証明書と。

備忘録的エントリになります。

レンタルサーバーとかだと、LetsEncryptの Certbot で運用・・・なんてできませんよね。
LetsEcryptに対応している(コンパネとかで)レンタルサーバーだといいんですが、対応していない場合、なんとかして LetsEncrypt のフリーのSSL証明書をゲットしなければなりません。

探し方が悪いのかググっても情報がバラバラで何がどうなってんのかさっぱり分からない。かなり試行錯誤しながら、SSL証明書の取得および更新を半自動化するスクリプトを組むことができました。

まずはCertbotのインストール

私は ガチガチのWindows ユーザーなので、まず最初に WSL1(Ubuntu 20.04)でやろうとしましたが、Certbotの公式サイト(https://certbot.eff.org/)に載ってる説明されている方法だと、snapdをインストールして・・・と書かれているのですが、WSL1ではsnapdは非対応でした。

WSL2とsystemd稼働環境だといけるみたいですが、WSL2はあまり使いたくありません。で、残る選択肢は Windowsで動作するCertbotをインストールするしかありません。

Windows版のcertbotのインストールはWinGetを使うと超絶カンタンです。
コマンドプロンプトから、下記のようにコマンドを叩くだけ。途中権限昇格がポップアップされますが、大丈夫でしょう。

 >> winget install certbot

通常、C:\Program Files\Certbot\binに実行ファイルが格納されていますので、環境変数 PATH に追加しておくといいでせう。

Linuxとかだと、関連するファイルは、/etc/letsencrypt/ に配置されてるようですが、Windowsだと、C:\Certbotに関連するファイルが作成されるようです。

一つ注意点として、certbotを実行する際、管理者権限が必要です。まず管理者権限のコマンドプロンプトで実行しないと、エラーになります。

SSL証明書の取得

インストールが完了したらほぼ作業は終わり。あとは、下記のようなCMDファイル(batファイルでもいいけど)を書いた方がいいです。
インストールして初回実行時だけ、メールアドレスの登録プロセスが出ますが、特別な理由がない限り、メールアドレスは登録しておいた方がいいでしょう。SSL証明書の期限切れ前に、メールで知らせてくれます^^;

今回は証明書の取得をウェブサーバー上で行うのではなく、自分のPCで証明書を取得しますので、Manualプラグインを使用します。ドメインの認証方法は、通常と同じくデフォルトのhttp認証でドメインの認証を行います。

要するに、自分がそのドメインのオーナーかどうかは、レンタルサーバー上へ FTPなどで認証ファイルを置くことで認証を行います。
認証ファイルをレンタルサーバーへ転送するには、cURL を使います。Windows10から curl.exe が標準でバンドルされるようになってるはずです。

読めば大体分かりますが・・・、
(1) –manual で Manualプラグインを使用します。
(2) -d でSSL証明書を取得したいドメイン名を指定。
(3) –key-type で rsa を指定。レンタルサーバーがRSAしか対応していない場合は指定する。
(4) –agree-tos, –manual-public-ip-logging-ok は指定しないと途中で聞いてくるので初めからYes。
(5) –manual-auth-hook,–manual-auth-cleanup は、後述。

最後の(5)で、–manual-auth-hookと–manual-auth-cleanupは、認証情報をセットアップ、クリーンアップするスクリプトを指定します。
これは下記のように、certbotを実行中、http認証する前、後にコールされ実行されます。

※この2つのフックについては、公式？のドキュメント、Pre and Post Validation Hooks 参照のこと。

具体的には、スクリプトが実行されるとき、ドメイン名や、認証テキストなどが環境変数を通して渡されますので、環境変数から渡されたパラメータを使用して、レンタルサーバーへcURLを使って放り込みます。具体的には、以下のようなスクリプトを用意します。

上記ファイルにも書きましたが、FTPサーバーへのアカウントを直書きしているので、そのままコピペはダメです。あくまでサンプルですので、暗号化・復号化は自分で実装してください。

※ また、FTP以外のSCPとか使ってレンタルサーバーにアップしている人・・・cURLのほかにも SCPもWindows10以降はバンドルされているので、その辺はテキトーに書き換え必要。

正常に認証が通れば、SSL証明書が、C:\Certbot\live\ドメイン名 ディレクトリに証明書が生成されているはずです。
実際には、シンボリックリンクになってますが。これらのファイルをレンタルサーバーのコンパネで設定してください。

SSL証明書の更新

LetsEncryptは3か月(90日)しか使えません。自前のサーバーでは、crondなりで更新スクリプトを回せばいいのですが、 レンタルサーバーだと全部手動になります。
少しでも楽するため、SSL証明書の更新処理だけは自動化したいですよね。

更新の際も認証が必要になりますので、上記で使った certbot-preauth.cmd,certbot-postauth.cmdを使いまわします。。。

certbot renew する際の注意点として、複数のドメインの証明書をcertbotで管理する際、特定のドメインを指定して更新、というのは現状できないみたいで、renewするときはすべてのドメインを一括して更新されてしまいます。

-d でドメインを指定しても、エラーになり、いずれドメインを指定できるようにする、という旨のメッセージが出ます。まぁ、バージョンが上がれば、そのうちドメインを指定して更新処理(certbot renew)することができるようになるでせう。

と、まぁ、http認証をmanualプラグイン(手動)で運用できるようになりました。８８８８８８。

・・・ですが、ワイルドカードSSL認証の場合は、デフォルトのhttp認証ではなく、dns認証をするしかありません。
やり方は上記とほぼ同じですが、–preferred-challenges dns を付け足し、-d で アスタリスクをつけたドメイン名を指定するだけ。
ただし、自動化するには、–manual-auth-hookでDNSのTXTレコードを設定する処理が必要です。
DNSの設定をAPI経由などでできないと無理っぽそう。

今更ながら Visual Studio Code でデバッグ環境構築

2年ぐらいかかっていた業務用のウェブシステムのリプレース案件がこの夏ようやく完了。
なんせ仕様調査からシステム構築、デザイン、データベース設計、コーディングをたった一人でやって(web系が分かる人が僕しかいいない環境なので・・・)、前のシステムにあった訳の分からない仕様を撲滅しつつ、妥協できるところは妥協し、譲れないところは譲らず我を通したせいで文句を言われつつ、自分にとってなんとか納得のいくものができたつもり。
幸いなことに、使っているユーザーさんから、前より使いやすくなった、との声をもらえたのでそれだけでもよかったかな、と思います。
あとは営業さんがユーザーさんに簡単な講習会をやって終わり・・・という段階になってやっと強烈なストレスから解放されました。

前置きはともかく・・・

ちょっと時間が空いてきたので、前から興味があった Visual Studio Codeを触ってみよう、と思いいろいろ調べてある程度のデバッグ環境を構築できてきました。そもそもVisual Studio Codeを使ってみようと思ったきっかけは・・・

  • C#やC++で一つのファイルで完結してしまうような小さいコンソールプログラムをたまに書くけど・・・簡単なデバッグ環境が欲しい
  • msbuildとか要らん！そもそも XML は好かん。 nmakeで必要十分だし書くの慣れてる。
  • Visual Studio 2019のIDEを使えば手っ取り早いんだけど・・・おいらのPC環境のせいかどうか分からないが、エディタのフォント表示が異常に汚い(ガタガタ）
  • Visual Studio 2019のIDEを使うほど大したコードを書くわけじゃないし、何より動作が重いし、キーバインドが慣れない
  • 拡張機能でvimのキーバインドがほぼ完璧に再現できるみたい？

早速インストールし、必要そうな拡張機能を入れて使いだしたんだけど、問題が発生。
ターミナル＞ビルドタスクの実行を行うと・・・cl.exe、csc.exe、link.exe などのツールへのPATH設定や環境変数などが定義されていないのでエラーに！

普段、c++やc#のコードをビルドするとき、Visual Studio 2019をインストールした時に入る、vcvars64.bat というBATファイルをコンソールウィンドウから実行することで Visual Studio 2019のビルドツールを使えるようにしてたんですが・・・はて・・・ターミナルの設定はどうすればいいのか・・・考えたあげく、下記のような コマンドファイルを作ってこれを setting.json の Terminal.Integrated.Profiles というキーに入れた。

REM ------------------
REM vs2019t.cmd
REM ------------------
@ECHO OFF
CALL "C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Auxiliary\Build\vcvars64.bat"
%comspec% %*

visual studio 2019のコンソール環境用にterminalのprofileを一つ追加。

下記のように デフォルトのプロファイルとして設定した。

ホントは知らないだけで、もっとスマートな方法があるのかもしれん！
結構ググったんだけど見つけられなかった。。。

で、実際のデバッグ環境としてはかなり良くなった！

ターミナル＞既定のビルドタスクの構成からtasks.jsonを作成してビルド方法を書くみたいだけど、一つのファイルをデバッグしたい場合は、cl.exe/csc.exeとかのコマンドを設定して、
複数のファイルがある場合は、nmakeかmsbuildとかにした方が効率がいいかもしれない。
tasks.jsonのテンプレートをいくつか用意しておいた方がいいかもしれん。

vscode/tasks.json テンプレ

.vscode/launch.json テンプレ

簡易ISOファイル作成コマンド

■2021年8月2日 追記

これの続きです。

自分用のツールの置き場、備忘録として記録しています😅

CDやDVDのメディアからISOファイルを作成するのは結構カンタンにできました。
これで殆どやりたいことはできたのですが、やっぱりディレクトリからISOファイルを作るにはどうするんだろう？？？ という素朴な考えがでてきまして・・・

————– 追記
これが 非Windows OSならば、mkisofs コマンド(genisoimage)をdnfなりaptなりのパッケージマネージャで入れれば解決するんだけど・・・いかんせん、Windowsはそういう便利なコマンドはありません。oscdimg という Windowsのインストールメディアを作成するツールを使えばできるそうです。実用性を重視する人は oscdimg を使うといいと思います😀
追記ここまで —–

ググるとこれもWindowsで標準機能でできるようで・・・具体的にはイメージマスタリングAPIとしてCD/DVD等のファイルシステム作成からメディアへの書き込みまでの機能がCOMサーバーとして提供されているようです。COMサーバーで実装ってことは、WSHやC#から簡単に使える・・・ってことです。

サンプルのコードはもうマイクロソフトのコミュニティーサイトに載ってましたので、これを適当にいじって、任意のディレクトリをISOファイルにビルドできるコードを書いてみました。一つ前に書いたDVDメディアからISOファイルを作るコードも統合してみました。

イメージマスタリングAPIは.NET Frameworkのクラスライブラリで提供されておらず、C#から使用するには、TLBIMPコマンドを使用してタイプライブラリからCLRアセンブリに変換し、コンパイルするときにこのアセンブリを参照しないといけません。Visual Studio のIDE環境を使用する場合はプロジェクトにIMAPI2FS.dllの参照を追加するだけでいいかもしれません。
僕みたいにコンソール画面でカチャカチャする場合は・・・

>> tlbimp c:\WINDOWS\System32\imapi2fs.dll

のようにすると、同名のアセンブリ(dllファイル)ができるので、ソースコードをコンパイルするときに、このDLLファイルを /r オプションで追加します。

殆どサンプルコードをコピペしただけなので、特に特筆するところはありません・・・githubにリポジトリ作ろうと思ったけど、ファイル1個だけなんでgistにした。

一応、タイプライブラリのインポートもあるので nmake用の makefileも書く。

DVDメディアのダンプ

Windows7の環境が必要になり開発用のプロダクトキー？を発行してもらい、後はHyperV環境で仮想マシンを作ってインストールするだけ。
って思ってたら、罠が・・・HyperVで稼働しているマシンにDVDを読めるドライブがねぇよ。。。
DVDメディアからISOファイルを作れば・・・と思い、Windows10のアクセサリの中にISOファイルを作るアプリを一応探してみたけど当然なく・・・、WindowsってISOファイルからメディアに焼く機能はエクスプローラから呼び出せるのに、その反対ができない・・・。

むむむ、linuxとかだと、ddコマンドで一発なのに・・・WSLからddでDVDドライブのデバイスを指定して・・・ってできないのかなぁ・・・。

仕方ないので窓の杜でフリーソフトを漁るか・・・とも思いましたが・・・、単にドライブをオープンしてダンプすればエエだけやろ？ ってことで、C#で書いた。C#からWindows APIをコールするところはマイクロソフトのサイトからコピペして、適当に。

要点は、Windows APIの CreateFile から返る SafeFileHandleをFileStreamに渡してバッファを介してコピーするだけ。
FileStream.CopyToAsyncメソッドを使えば一行で済むんだけど、やっぱり途中経過(進捗状況)は必要かなー、と思って無理やり FileStream.ReadAsync/WriteAsyncメソッドを使ったけど・・・。

SQLServer on Linux !?

これは、マイクロソフトがWindowsを捨て去る布石なのか？？

来年中盤以降に マイクロソフトのサーバーソフトウェア群における中核とも言える SQLServer の Linux 用・・・（たぶん Redhat Enterprise Linux用だと思うんだけど）をリリースするという・・・。
http://blogs.microsoft.com/blog/2016/03/07/announcing-sql-server-on-linux/

SQLServerがLinux上で稼働する、ということは、次に来るのは当然 “.NET Framework on Linux”とか？？？(Monoプロジェクトがありますけど・・・） もしそうなったら、もうWindows Serverである意味がないやん！

サーバーOSに関して考えればOSを選んでからサーバーウェアを選ぶという時代じゃないですよね。実現したいサービスがあって、それを実現するためのサーバーウェアを選択して、それから最終的にOSを選ぶ・・・っていう。

さらにクラウドコンピューティングとか仮想化とか・・・、正直、OSなんか、もう、どれでもいいんですよね。なんかもうWindowsとかLinuxとかMacOSとかBSDとか、どれでも、いいんすよ。

ま、こんなこと、今更感が満載なんですけどね。
追記：
そういえば、マイクロソフトは Xamarinも買収しましたよね。SQLServer on Linuxも含め、いずれはmonoプロジェクトも取り込んで、ネット上のクライアントとなるアプリ開発、サービス開発に必要なバックエンドソフトウェアと、必要なものがほとんどすべてマイクロソフトからリリースされることになったわけで。