Compnet

仕事とか遊びとか、日々折々

2017-12-04(月)

StartSSL が終わった

Posted by Nakane, R. in impressions   

Web サイトを SSL 対応にしたり、ログイン時の認証をクライアント証明書で行うようにするときには電子証明書を使います。 本ブログでも、このようなことを記事に書いています。 このときに使う電子証明書は StartSSL で発行したものを使い、記事にもそのように書いています。

しかし、昨年 (2016年) に証明書発行に関する問題がいくつも発覚したことで、Mozilla の Firefox や Google の Chrome などの主要なブラウザーが、StartSSL (これを管理する StartCOM 社) が発行した証明書を信頼できない証明書として扱うようになりました。 StartSSL は一般に公開された認証局の中で数少ない、無料で証明書を発行してくれる認証局です。 発行できる証明書は DV 証明書で、有効期間がサーバー証明書が 1 年、クライアント証明書が 2 年にという条件が付きますが、なによりも無料というのは実験的な使用には十分に魅力でした。

Read more...



2017-10-09(月)

Pelican の ReST 用に HTML タグを手軽に使うためのロール拡張を作った

Posted by Nakane, R. in technical   

本ブログは以前の記事で書いた通り Pelican という静的サイトジェネレーターを使って構築しています。 その中で Pelican を採用した理由として「reStructuredText で書ける」ということを挙げました。 実際に Pelican に移行してから今日までのほぼ一年に 21 本の記事を書き、それらはすべて reStructuredText で記述しています (平均して 2 週間に 1 本のペース、少ないですね)。 加えて、それ以前に Wordpress に書いた内の 11 本の記事を reStructuredText で書き直して、新しいブログの側に転載しました (まだ 200 本以上残っていますが)。

テキスト エディターだけ記事を書けるのが reStructuredText で書くことの手軽さです。 表題や箇条書きなども特別な表記法ではなく、誰もが思いつくような書き方なので、読み返したときに読みやすいという点でも手軽といえます。 もちろん reStructuredText といえども万能ではなく、使いにくい点もいくつかあります。 Pelican を使ってブログ記事を書く前提ですが、記事を reStructuredText から HTML に変換したときに、表題に ID 属性が付けられないというのも、そのひとつです。

reStructuredText で書かれた記事を HTML に変換しすると、表題は h1h2 といったタグを使った表記に変換され、その表題から始まる節が div タグで括られます。 そして表題を基にした ID が生成されて、div タグに ID 属性が付けられるます。 このため、一応は表題 (正しくは表題から始まる節) を参照するリンクが書けられそうに見えます。 しかし、表題に英数字以外が含まれていると、先頭の英数字部分だけが ID になったり、id1、id2 のような機械的に割り振られた ID になったりするため、どんな ID 属性が付くかは変換してみないと分からず、そうそう手軽だとはいえません。

また、打ち消し線を記述する方法がないというのもあります。 raw というロールを使って、reStructuredText の記述中に HTML による記述を埋め込むコトができなくはありませんが、見栄えの点からいってあまりいいとは思えません。

前者を解決するには reStructuredText を HTML などに変換する仕組み、つまり Docutils のソースコードに手を加えなくてはならないみたいなので、そうそう手を出せません。 しかし reStructuredTextdel タグ相当の記述方法を追加するだけなら、何とかなりそうです。 そこで、Pelican の拡張機能 (プラグイン) として、del タグ相当の記述方法を reStructuredText に追加しました。

Read more...


2017-09-24(日)

AWS を触ることにした

Posted by Nakane, R. in technical   

クラウド プラットフォームというと、AWSAzure の二大巨頭を筆頭に各社がひしめき合っている状態で、筆者はずっと Azure 一本で評価してきましたが、そろそろ AWS をなんとかしなければならなくなってきたみたいです。

Azure では初回契約時に 250 ドル分の無料利用枠が提供され、その範囲内である程度の検証・確認作業できます。 利用料が 250 ドルを超えると、そのときから請求が始まります。 これに対して、AWS には、EC2 では t2.micro 限定で 750 時間までといったような制限があるものの 12 ヶ月間の無料利用期間が提供されています。 期間中でも無料枠以外の利用分は普通に請求されます。

Azure の場合は初回契約時の無料利用枠の他にも、MSDN サブスクリプションの購入で 50 ドルから 100 ドル相当の無料利用枠が毎月提供されるといったものもあります。 なお、MSDN サブスクリプションに付随する無料利用枠には用途制限があって、開発・検証用途以外での利用は認められていません。 社内利用と検証用途だけの利用に制限された Microsoft パートナー向けの無料利用枠といったものもあります …

Read more...


2017-07-19(水)

続々:YAMAHA RTX で Azure と VPN 接続する

Posted by Nakane, R. in technical   

半年ほど前に、YAMAHA RTX ルーターで Azure と VPN 接続をするための設定に関する記事を公開し、それに関する追加の検証結果を数日前に公開しました。 これらの記事では、RTX ルーターと Azure の仮想ネットワーク ゲートウェイとで IPsec の VPN トンネルを確立するための RTX ルーターの設定を紹介しています。 半年ほど前の記事では、RTX 側からの SA の更新 (再作成) の失敗により、VPN トンネルを通じた通信ができなくなる現象に対する回避策を紹介しています。 また数日前の記事では、SA の有効期間を Azure 側の値に揃えることで、特別な回避策が不要になる旨の検証結果を紹介しました。

これで一区切りと思ったのですが、改めて数日前の記事に挙げた RTX ルーターの設定を眺めていたら、IKE SA の有効期間が RTX の初期値と同じことに気づきました。 そうであれば、IKE SA を明示的に設定しなくても大丈夫ではないかと、再び検証します。

Read more...