ただつらつらと日記が書かれていくようです。

タグ: はてなダイアリーからの移行記事 (10ページ目 (18ページ中))

お得なSSLサーバ証明書に関するメモ…の補足。

昨日、「お得なSSLサーバ証明書に関するメモ。 – お仕事日記。」ってエントリーを書いたけれど、結論としては、値段も高いけど、ケータイサポート率も高いVerisignもいいけれど、GeoTrustのSSL証明書って値段の割にケータイのサポートもそこそこでいいんじゃないだろうか的な結論になってた…つもりだ。

で、今日、たまたま、PHPで有名なアシアルがSSL証明書を扱っているのを見つけた。で、デモページがあったのでブラウザでアクセスして、証明書を眺めてみたが、そのルートCAがGeoTrustと同じ「Equifax Secure CA」であることがわかった。

てか、ApacheとかIISへの導入方法のインストラクションは、GeoTrustのサイトへのリンクじゃないですか…ってことで、日本ジオトラストとアシアルが売ってるSSL証明書は、結局、同じモノではないかと思う。で、アシアルから買った場合は、12,800円/年。うーむ、これは安い(汗)

しかし、アシアルのサイトを眺めてみたけれど、サイトシールに関する言及がさっぱりないことに気がついた。もしかして、サイトシールが提供されない(…もしかして、ケータイ向けのSSL証明書ってことなら、PCのブラウザで表示するサイトシールを提供してなくても仕方ないってなるんだろうか…)から、この安さってことなんだろうか(汗)まさかねぇ…。

まぁ、安さを追求するなら、GoDaddyとかRapidSSLに買いに行けば、3000円くらい/年でSSL証明書を入手することもできるわけで、ま、ちょっといろいろと微妙な世界ではあるんだけどなぁ。

お得なSSLサーバ証明書に関するメモ。

最近、SSLサーバ証明書を更新する必要があって、いろいろと調べ回ってみた。まぁ、そもそもSSL証明書なるものの価値というのは、どれくらい多くのブラウザやケータイが、そのSSL証明書のルートCAの証明書を持っているかという辺りで決まってそうだというのが、調べてみての感想。とはいえ、SSL証明書の商売って、結構、儲かってそうな印象(汗)も受けた。

例えば、PCのブラウザだけをターゲットとしてSSLを使うのであれば、とりあえず、GoDaddyのサイトでも行って買ってくるのが一番安いのではないかと思う。アメリカのGoDaddyとお取引する関係で、実際にやったことないけれど、決済周りとかいろいろとややこしいことになりそう。とはいえ、実在性証明などが伴わない、一番安いSSL証明書で\2,700/年くらいだった。(どういうわけかGoDaddyのサイトでは、日本円の価格を表示することができる)この辺の値段を知ってしまうと、日本国内で買うことができるSSLサーバ証明書のお値段は激しく高いことになる。

日本国内でもGoDaddy級のお値段を設定しているSSLサーバ証明書屋さんもあるが、その辺を除けば、普通のSSL証明書は、だいたい2.5万円~8万円くらいが相場ではないかと思う。GoDaddy系のルートCAのSSLサーバ証明書が発行される「JCert」のSSLサーバ証明書は結構安かった(1FQDNのドメイン認証なSSLサーバ証明書で¥26,250)

ま、EV証明書となるともっと高くなるが、SSLを使って通信内容を暗号化したいと思うクライアントがブラウザのアドレスバー辺りが緑色になってうれしくなるという要件でもない限り、、、特段、必要ないのかもなぁと遠い目をしてしまった。普通のSSL証明書でも、サーバとクライアント間の通信は暗号化されるわけだし、実際にアドレスバーが緑になるメリット感はあるのだろうか。うーむ、わからん。

一方、GMOが売っている「GlobalSign」のSSLサーバ証明書とかだと、ケータイ対応に若干の難しさがあるような気がした(ちなみに、私が使ってるケータイのN904iは未対応だったし…汗)が、ケータイを使わないのであればアリだろうなぁ。ケータイ端末を100%近い割合でカバーしたいならVerisignのSSLサーバ証明書を買うことになりそうだけど、結構いいお値段である。

なんだかんだ調べてみて、2006年からVerisignグループ入りした「GeoTrust」のSSLサーバ証明書がなんとなくお買い得な印象を受けた。ケータイ端末のカバー率に関して「92.8%の携帯電話で利用可能」って書いてある割には、標準価格が36,540円で、キャンペーン価格で22,050円。ほどよく安い気がする。まぁ、ケータイのカバー率が100%に近い「Verisign」か、ほどよい値段の割には結構ケータイをカバーしている「GeoTrust」で我慢するのかはなかなか難しい選択肢だ。

あと、インテックが扱っている「EINS/PKI+」ってサービスでは、ルートCAがRSAになっているSSLサーバ証明書を買うことができそうだ。値段が通常料金で5万円/年だから安いサービスではないけれど、ケータイには割とRSAのルートCAの証明書が入っているので、ケータイをターゲットとするWebサイトでSSLを使いたい場合には選択肢になりうるのかもしれない。

非定型業務の可視化って…。

InterstageのBPMエンジンの新しいのが出たらしい。

富士通、「Interstage BPM」新版-現場の“非定型作業”も可視化:

http://enterprise.watch.impress.co.jp/docs/news/20091109_327677.html

業務プロセスには、あらかじめ定義可能な「定型業務」と緊急発生する予測不可能な「非定型業務」の2種類が存在する。従来のBPMは、このうち定型業務をあらかじめモデリングして定義しておくことで、可視化を行うものだ。そのため、予測不可能な非定型業務の可視化は不得意といえた。

 例えば、「注文数や納期の変更」「発注元により異なる製造工程」「取引先ごとに異なる修正指示」などの非定型業務は、「業務プロセス全体の80%を占めるとも言われ、メールや電話で都度確認して作業状況を把握するしかなかった。そこで従来の定型業務に加え、非定型業務をいかに可視化するかが課題となっていた」(矢作氏)のだという。

以前、BPMエンジンが動作するミドルウェアを扱っていたせいか、やっぱり、非定型業務っていうのは非定型業務としてビジネスプロセスを遷移させるしかないんじゃないかと思われ。やっぱり、例外処理は例外処理なわけで。

ま、確かに、非定型業務の可視化は課題だとは思うけれど、もし、どういうことが起こるか予想しうるのであれば、それはやっぱり定型業務として、ひとつのビジネスプロセスとして定義しうるんじゃないかと思うけどなぁ(汗)うーむ、なんつーか、仮に、非定型業務が業務プロセス全体の80%を超えてたら、BPMエンジンを導入している意味が消失してるような気もするわけだし、BPMエンジン導入前のBPRとか大丈夫かという世界なのかもしれず。あー。

ムームードメインでドメインを更新したら、お名前.comにトランスファー

ムームードメインで管理している.netドメインがあって、そろそろ更新の季節だというメールが届いた。そうですかということで、素直に更新しようとしたら、コントロールパネルの画面にこんな文章が出てきて、手が止まった。

ドメインの更新に伴い、更新時に『お名前.com』へのトランスファー(移管)処理が行われます。トランスファー申請中は、ドメインの操作が行えません ので、予めご了承下さい。

* レジストラが変更になりましても、お客様側での設定やドメイン料金は変更されませんのでご安心ください。

* 入金確認後、トランスファーが完了するまで10日程度 かかる場合がございます。

* トランスファー更新にともなって、承認のため、「トランスファー承認手続きのお願い○○」及び 「Domain Transfer Request for ○○」という件名のメールが送信される場合がございますが、 こちらに対する手続きは一切必要ございません。

* トランスファー更新の後、60日間は他のレジストラへの移管を行うことが出来ない場合がございます。

* 移管状況の詳しい内容はドメイン詳細でご確認できます。

いきなり、お名前.comにトランスファーしますと言われても、意味がわからないんですけど…と思い、ヘルプページやサポートフォーラムを覗いてもさっぱりその辺への言及がなかった。こういうのって、なんか気持ち悪い気がする。で、ちょっと調べてみて、なんとなくわかったのでメモ。

ICANNのサイトを見ると、ムームードメインはICANN認定のレジストラではないから、ムームードメインがgTLDドメインを扱うためには、上位レジストラとしてICANN認定のレジストラが必要になる…と。

で、確か、ムームードメインは、eNomが上位レジストラだったんだけど、しばらく前にpaperboy&co.がGMOの連結子会社になった関係で、ムームードメインの上位レジストラをeNomからお名前.comに変えるというのがGMOグループ内の決定となったといったところだろうか。まぁ、上位レジストラがどうなっていようが、ドメインを使う分には問題ない…はず(レジストラのサービスの質を担保するためのICANN認定なんだろうし)だから、とりあえず、同意することにした。

初心者向けサービスを標榜する割には、しれっと「お名前.comにトランスファーします」なんて意味不明なことを言い始めるもんなぁ…って、どうなんでしょう。

さくらインターネットのレン鯖のMLのreply-to関係の設定をいじってみた。

さくらインターネットのレンタルサーバでは、fmlによるメーリングリスト機能を利用できる。サーバのコントロールパネルから送信先のアドレスを編集できたり、設定を変更できたりする…が、使っていて、ちょっと不便なことがあった。それは、メールヘッダの「reply-to」に関する設定をコントロールパネルから変更できないことだ。

ちなみに、デフォルト設定では、メーリングリストを介して配信されるメールの「reply-to」は、メーリングリストのアドレスになっている。つまり、メーリングリストを介したメールに対して返信すると、メーラーが「to」に指定するのはメーリングリストのアドレスになる。

そもそもメーリングリストとは何かを考えれば、そういう仕様でしかたないのかもしれないなぁとは思うが、ただ、単に「1個のメールアドレスで受けたメールを複数のアドレスにコピーして送るもの」としてメーリングリストを使いたいこともある。

そんな用途の場合は、fmlに任せるようなことではないのかもしれない…が、さくらインターネットのレンタルサーバ(少なくともビジネス向けのサービスの方は)のコントロールパネルでは、転送メールを利用するときに、転送先アドレスの指定がCSVでアドレス指定なので複数のアドレスを設定するときにかなり使いづらいという事情がある。…なので、仕方なくfmlにただメールを転送させることにした。

実際に会社の代表アドレスに、メーリングリストを使ってみると、さくらのレンタルサーバ上のfmlを介して届く関係で、reply-toがメーリングリストのアドレスになっている。なので、お問い合わせメールが届いて、それに普通に返信すると、問い合わせてきた人には届かなくて、社内だけに届いてしまう羽目になる。

そんなわけで、もし可能なら、メーリングリストでreply-toの付与を抑止できたらいいなぁと思ったけれど、その辺の設定項目がコントロールパネルになくて困った。さくらのレンタルサーバでは、SSHでログインすることが出来るので、fmlの設定をいじくってみることにした。

fmlのドキュメントなどを読んでみたら、「reply-to」の付与を抑止するには、設定ファイルに

&DEFINE_FIELD_FORCED

って書いてあるのを消せって書いてあったけど、そんなこと書いてなくて…どうしたものかと。なんとなく見てる設定ファイルを間違えているような気がしないでもないけど、なんとなく面倒な気がしたので、とりあえず、fmlが自動的にMLのアドレスを入れたreply-toを付与する前に、reply-toを書いてしまえばいいんじゃないかという…ちょっと邪道っぽい解決策を思いついた。

…というわけで、こんなのを設定ファイルに書き込んでみた。要するに、START_HOOKを利用して、reply-toにアドレスを指定してあるメールがMLに送られたら、改めて、そのメールアドレスをreply-toに入れてメールを配信するし、reply-toを指定していないメールに関しては、メールヘッダーのfromに書いてあるアドレスをreply-toに強引に(汗)入れて配信する…と。

$START_HOOK =q#

if (&GET_HEADER_FIELD_VALUE(‘reply-to’)) {

&DEFINE_FIELD_FORCED(“reply-to”, &GET_HEADER_FIELD_VALUE(‘reply-to’));

}

else {

&DEFINE_FIELD_FORCED(“reply-to”, $From_address);

}

#;

とりあえず、かなり強引なやり方ではあるけれど、reply-toでややこしくなる事態は回避できたような気がする。まぁ、思いつき型の解決策にありがちな、なにかのレアケースでややこしいことになりそうな気もしないけど、、、しばらく様子を見てみようかと。

MS製Firefoxプラグインがお粗末な件。

Firefoxを使ってたら、いきなりプラグインのいくつかを無効化するダイアログが開いたと思ったら、.NET向けのプラグインが無効化された。まぁ、一回も使った記憶がないからいいか…みたいな。

その背景には、こんなのがあったらしい。要らないプラグインを強制インストールするなよなぁ…ほんと(汗)

テクノラティジャパンがサービス終了とな。

Blog検索サービスの「テクノラティ」@日本がサービス終了するらしい。1週間前くらいにもう一個のBlogを登録しようとしたら、よくわからんエラー(OpenID経由で登録しようとしたんだけど、本来であれば、登録完了って出るはずのところで登録開始の画面に遷移してた)が発生して登録できなかった背景にはサービス停止があったようだ。

まぁ、思い出してみれば、Tecnorati以降、Googleブログ検索をはじめBlogを検索できるサービスが登場して、一瞬、賑わいを見せたけれど、結局、効率的なマネタイズがうまくいかなかったのだろう。例えば、Ask.jpのように脱落したサービスもあったが、Technoratiも例外ではなかったようだ。細かく見れば、アメリカのTechnoratiはサービスリニューアルを行ったタイミングだが、日本のTechnoratiが追随せずに、サービス終了したって感じだろうか。

blog検索が登場した黎明期には、Web検索とは別のものとしてBlog検索が成立していたことになる。でも、その背景にあったBlog検索とWeb検索を分けていた要素、いい変えれば、Blog検索にしかできなかったことは、Blogにポストされたエントリーを早く検索可能になることくらいしかなかったんだろうと思う。

結果的に、Googleあたりがインデックス更新の頻度を上げて、Web検索にBlogも取り込んで、新しい情報を検索結果に引っ張り出せる仕組みを入れた時点で、Blog検索の独立系サイトはPVを集められない運命にあったのかもなぁと思うと、あらためてGoogleあたりの脅威ってのはいろんなところに潜んでいそうだ。

Williamson教授がノーベル経済学賞とな。

今年のノーベル経済学賞が発表されたようで、Elinor OstromさんとOliver Williamsonさんが受賞されたそうな。

no title

Oliver Williamsonって名前が記憶のどこかにひっかかったので思い出してみたら、学生時代のゼミで、O.E.Williamson著「市場と企業組織」(原題は「Market and Hierarchies」だっけか。まぁ、読んたのは和訳された本ですけれど。)を参考文献で読んでいたことを思い出した。企業間、および企業内の取引費用(transaction cost)に注目して…どうにかした議論だった気がする(汗)私が書いたレポートでは、産業組織論の文脈で、企業の垂直統合を考えるときに、取引費用の観点から言及したような記憶がうっすらと(汗)

オリバー・ウィリアムソン – Wikipedia

内容は難しくてエッセンスすら理解していないけれど、レポートを書くためにゼミ員同士で取り合っていた、あの緑色の「ウィリアムソン」本(…汗)の著者がノーベル経済学賞を取ったのかと思うと感慨深いような気がする。

HPがSolarisを売り始めたらしい件。

今更ながら、メモっておく。

日本HP プレスリリース HP ProLiant向けSolarisおよび関連サービスの提供開始 2009年9月15日

HPが自社のx86サーバ「Proliant」に、Solarisを載せて売り始めたらしい。SunがOracleに買収する前に結ばれていた契約に基づくものらしいが、HPもなかなかおもしろいことをやるなぁと思った。

そもそも、Solarisのいいところって、その堅牢性とかZFSのような先端的な機能もさることながら、ローエンドからミドルレンジ、そしてハイエンドなマシンまで、スケールアップしても、Solarisで面倒見てもらえることだと思っていた。例えば、Sun FireV100のようなSPARCが1個のったマシンからE25Kのような何個SPARCが刺さってるのかよくわからんマシンまでSolarisが動作するわけでスケールアップできるレンジの広さはさすがSolarisかなぁと。Solarisを選んでおけば、スケールアップに伴うOSマイグレーションなんて心配しなくていい…みたいな。

そういう観点からすれば、x86なProliantにSolaris乗っけても、HP的な「先」は見えていて、きっと、HP-UXと「Integrity」な世界だろうから、「先」に行くためには、SolarisからHP-UXのマイグレーションをやらなきゃいけなくなるんだろう。システムが成長して、HP-UXと「Integrity」な世界に入らなきゃいけない頃には結構ミッションクリティカルなシステムになってて、SolarisとHP-UXの間でややこしいことになりそうなんじゃないか…と。

じゃ、やや暴力的だけど、そういう可能性があるなら、最初からHP-UXで作っておくのがいいんじゃないかと思ったりするわけだし、x86命でがんばるのであれば、スケールアウトしてずらっと並べる使い方が多いような気がしていて、そうなると、可用性や堅牢性も(何をもってそう言うか…は検討の余地ありまくりだけど)そこそこであればいいのではないかと思うし、安けりゃ安いにこしたことがないような気がする。そうなると、SolarisもRHELも(…そして、CentOSも…)変わらないような気がするんだけどなぁ(…無知ですか、そうですね)

ぼんやりとそんなことを考えると、HP-UX+Integrity以前の規模で、まず、x86サーバを選択したとして、わざわざSolarisを積極的に採用する理由ってなんだろうか(まぁ、ミドルウェアがSolarisじゃなきゃダメなんですとか、お客さんがSolarisが好きなんです…とかいろいろありそうではあるんだけど。でも、そういう時の「Solaris」って、x86じゃなくてSPARCとの組み合わせが必要なんじゃないかとふと思う。)

それでも、HPはSolarisを載っけたサーバを売り始めるわけだから、お客さんがいるという想定だろう。そういったお客さんにとって、どの辺がSolarisの選択理由になっているのか少し気になる。もしかして、とにもかくにもSolaris最高!って感じのSolaris信者のみなさま方って、意外と元気だったりするんだろうか。

…なんちゃって(汗)

« Older posts Newer posts »