2013年12月26日木曜日

Exchange 2007 の3ノードクラスタで、2番目のメールボックスサーバーへのメールボックス作成に失敗する

昨日、Exchange 2007 の既知不具合を踏んだ。
今頃 Exchange 2007 の情報かい、という感じで需要ないと思われるが記録を残しておく。
3ノードクラスタの動作確認で問題発生
Exchange 2007のメールボックスサーバーの高可用性構成には "ローカル連続レプリケーション (lcr)", "クラスタ連続レプリケーション (ccr)", "スタンバイ連続レプリケーション (scr)", "シングルコピークラスタ (scc)" の4種類がある。
高可用性: Exchange 2007 ヘルプ
今回担当したシステムでは、昔ながらの共有ディスク構成である scc を選択。ベストの選択かどうかはともかく、ディスクサイズ節約という観点では、scc 以外の選択肢は無いので。
サイジングの結果、Active-Active-Passive の3ノード構成になった。
3ノードって滅多に無いので、この時点でやや不安ではあった。

で、メールボックスを新規作成する試験を実施したところ、見慣れぬエラーが発生。
サーバー <servername> 上のプロキシの生成プログラム DLL が見つからないか、初期化に失敗しました。現在の受信者のプロキシ アドレスを計算できません。すべてのプロキシ アドレス生成プログラム DLL が対象となるサーバーにインストールされていることを確認してください。
2007 の既知の不具合だった
調査したところ、すぐに下記の情報に行き着いた。
シングル コピー クラスタのインストール: Exchange 2007 ヘルプ
複数のクラスタ化メールボックス サーバーが存在する SCC では、フェールオーバー クラスタにインストールされている 2 番目以降のクラスタ化メールボックス サーバーに新しいメールボックスを作成できないという、既知の問題があります。
なんで既に枯れてる 2007 にこんなしょぼいバグが残ってるんだ。
その対処方法は下記ページに書かれている。
Exchange 2007 シングル コピー クラスタ (SCC) の 2 台目以降のクラスタ化メールボックス サーバー (CMS) 上でメールボックス作成を有効にする方法
このページによると、どうやら、AD内に本来自動的に作られるべき "Microsoft MTA" オブジェクトが、クラスタの2番目以降のサーバでは作られないので、手作業で作ってくれということのようである。さっきのエラーメッセージの「プロキシの生成プログラムDLL」って、全然関係ないじゃん。Microsoft 製品のエラーメッセージは相変わらずアレだ。

というわけで、上記ページの手順に従って Microsoft MTA オブジェクトを作成して本件は解決した。
今後 Exchange 2007 で3ノード以上の scc を組む人の参考になれば幸いである。そんな人いないか。

2013年12月24日火曜日

2013年12月13日金曜日

[VBA] Excelで簡易Diff

SIerにお勤めの社畜の皆さんこんにちは。社畜Excel職人のdsp74118です。
ご挨拶はさておき、今日の本題へ。
ExcelでDiffしたい
我々SIerの仕事は、1にExcel、2にExcel。3、4がWordで5にPowerPointであるから、Excelで行う作業を如何に効率化するかが、サボる業績を上げるための至上命題である。
さて、我々SIerは「2つのデータのDiffをExcelで見たい」というシチュエーションによく遭遇する。 Excelのブック同士のDiffを取るのであれば、WinMergexdocdiff プラグインとかを使えばよいのだが、当記事は、同一シート内の2つの列でDiffを取り、それを見やすく整形することをテーマとしている。
例えば下図Figure.1のような状況。
Figure.1 A列とC列を比較したい
A列とC列に似たようなデータが入っているが、微妙に違う。これのDiffを取る(SI業界では"突合"と言う)にあたり、Excel使いとして飼い慣らされた社畜であるならば、同一データを同一行に揃えたくなるだろう。
Figure.2 こういう風に同じデータが同一行に揃うと嬉しいよね
このような整形処理を実現するVBAをこの度書いたので、ここに公開する次第である。
Posted in 

2013年12月1日日曜日

2013年11月25日月曜日

PMシンポジウム2013 参戦レポート

ブログに書くまでがイベントです(キリッ
というわけで、2013年11月21日~22日の PMシンポジウム2013 に参加してきたので、簡単に所感などをまとめることとする。
Posted in 

2013年11月8日金曜日

Windows のオブジェクトのアクセス権を操作するコマンド subinacl が便利だった

Windows のファイル、レジストリ、SAMオブジェクト(ユーザー、グループ)等のアクセス権を操作する MS 製ツール "subinacl" が便利だったのでメモっておく。
当記事ではファイル/フォルダのアクセス権操作についてのみ言及する。

2013年11月1日金曜日

『ログオン後のNumLock状態はレジストリで制御できる』という大嘘

当記事はWindows7を対象に書いているので、他のバージョンでは動作に差異があるかもしれません。あらかじめご了承ください。
「NumLock状態を制御したい」という要件
ITインフラの(というか社内OA構築系の)仕事をしていると、顧客から「端末のNumLockは全台一律(On|Off)にしてよ」という要件が出ることがたまにある。
で、その方法をググると、「レジストリの値を変更すれば良い」という情報が山ほど出てくる。ところが、得られる情報は半分は正しくて、半分は嘘である。

2013年10月28日月曜日

VDI環境でフォルダリダイレクトの中身がぶっ飛んだ話

先日、客先のVDI環境で掲題の大障害を踏んだのでメモ。
客先本番環境でのみ発生し、切り分けのために構築した検証環境では再現していないため、詳しい発生条件が分かっていないが、二度と同じ障害を踏まないために記録として残しておくこととする。
まずは環境の説明
特定されなそうな範囲で書くと、本番環境は、下記の構成である。
・VMware Horizon View。
・自動デスクトッププール。
・ADはWindows Server 2008 R2。
 ユーザー認証用のドメインというかフォレスト(以下「フォレストA」)は元からあって、Viewのコンピュータアカウントを入れるために新規に別フォレスト(「以下フォレストB」)を構築。2つのフォレストで双方向信頼関係を結んでいる。
・移動ユーザープロファイル。
・デスクトップとドキュメントをファイルサーバにフォルダリダイレクト。

2013年7月27日土曜日

2013年7月18日木曜日

階層構造になっているセキュリティグループ内のユーザーを再帰的に検索するLDAPフィルタ

"LDAP_MATCHING_RULE_IN_CHAIN"。非常に有益な機能だと思うが、日本語の情報がほとんど無かったので記事にしておく。
普通のLDAP検索フィルタは、ネストしたセキュリティグループに対応不可

Active Directory環境では、セキュリティグループのメンバーにセキュリティグループを入れるというネスト(入れ子)構造をよく使うと思う。セキュリティグループは会社組織と対応付けされることが多いので、例えば○○部のセキュリティグループの下に●●課のセキュリティグループと▲▲課のセキュリティグループを入れるといった具合だ。
ところが、このような構造において、「○○部に所属するユーザを全員取り出す」といったLDAP検索フィルタを書こうとすると難儀することになる。
Figure.1 ネストしたセキュリティグループ

上図のような構造で、GroupAに属するユーザーを取り出すLDAPフィルタを書く場合、単純に考えると
(&(objectClass=user)(memberOf=CN=GroupA,DC=example,DC=com))
と書けばよさそうだが、これではUser1しかヒットしない。memberOf句はグループのネストに対応していないので、指定したグループ(GroupA)の直下にいるメンバーしか見つけてくれないのだ。
AD独自の演算子で、ネストしたセキュリティグループを再帰的に検索
実はADのLDAPには、この問題を解決してくれる独自の演算子が用意されている。
Search Filter Syntax (Windows)
に紹介されている"LDAP_MATCHING_RULE_IN_CHAIN"がそれだ。
具体的には下記のように記述すればよい。
(&(objectClass=user)(memberOf:1.2.840.113556.1.4.1941:=CN=GroupA,DC=example,DC=com))
このフィルタなら、GroupAの下にあるGroupBのメンバーも再帰的に検索してくれるので、User1、User2の両方がヒットする。  "1.2.840.113556.1.4.1941"がLDAP_MATCHING_RULE_IN_CHAINのOIDなのだそうな。
手っ取り早く試すなら、ldifdeコマンドで
ldifde -f export.ldf -r "(&(objectClass=user)(memberOf:1.2.840.113556.1.4.1941:=CN=GroupA,DC=example,DC=com))"
とか書いてみるとよい。

2013年6月27日木曜日

自己学習による元手ゼロのPDU申請(Cat C: Self-Directed Learning)

PMPホルダーにとってPDU稼ぎは頭痛の種であるが、この度、セミナー等を受講しなくても無料でPDUを取得できる"Cat C: Self-Directed Learning"の申請にチャレンジし、無事受理されたので、3年後の自分のためにもメモを残しておく。
※PMIのサイトは頻繁に仕様変更をするので、近い将来、当記事とは申請方法が変わっているかもしれない。これは2013年6月末時点での手順であることをお断りしておく。
※PMI Code of Ethicsには「PMIのサイトのスクリーンショットを他所で使ってはならない」とは書いてないっぽいので当記事は問題ないと思っておりますが、もし何らかの規約に抵触しているようであれば、ご指摘いただけると幸甚です。
Posted in 

2013年5月17日金曜日

自前でWevDAVサーバを立てて、DropboxをWebDAV化する

さくら VPS に Dropbox をインストールして WebDAV 化する | 澍法雨に感動した。一言で言うと、LinuxサーバをDropboxのWevDAVゲートウェイにするという技である。記事タイトルにはさくらVPSとあるが、別にさくらVPSでなくても、普通のLinuxサーバでよい。
この手を使えば、OtixoとかDropDavとかの有料サービスを使わなくても、DropboxにWebDAV経由でアクセスできる。
WebDAVの何がイイかって、普通のDropboxクライアントアプリと違ってPCのローカルにファイルが残らないし、Proxyだって超えられちゃう。
Windows7ならWebDAVをネットワークドライブとしてマウントできるので、使い勝手もローカルフォルダと同じ。こいつぁすげえ。
早速、手持ちのCentOSサーバでやってみた。

2013年5月12日日曜日

2013年5月10日金曜日

ownCloud5.0.5+クライアント1.2.5で複数アカウント・複数PC間のファイル共有を試す

約1年越しでownCloudを触ってみてるのでレポートする。

ownCloud5.0で漸く実用レベルに?

昨年はownCloud4.0とWindows版クライアントアプリ1.0.3で検証していたが、そこから情報更新が滞ったのには訳がある。実のところ、複数のPC間でファイル共有を試してみたところ、ファイル更新時にうまく同一ファイルと認識されずコンフリクト扱いとなってしまう現象が頻繁に発生した。これでは使いものにならないので、検証をやめていたのだ。

今年の3月にownCloudが5.0になり、クライアントアプリも先月1.2.5になったので、再度試してみた。

2013年5月6日月曜日

Vimperatorプラグインnextlink.jsを動くようにした(WIP)

先日の記事の続き。とりあえず、一部サイトで動くようになったので、公開する。
あまりちゃんとテストしてないが、Googleの検索結果、@IT、Bloggerあたりで正常動作確認済み。動かないサイトはITProなど。まだ追求はしていない。2013.05.07 ITProで動かない理由は判明(文末に追記)
直し方はかなり「無理やり」であり、ホントに「とりあえず動く」だけなので、公式(https://github.com/vimpr/vimperator-plugins)へのpull requestはしないつもり。versionは"0.3.9 altered"としておいた。
HTMLをDOMとしてパースする処理はhttp://jsdo.it/kjunichi/qDCfあたりを参考にさせていただいた。

根本的に直すのであれば_libly.jsの修正が必要だと思うが、流石に影響範囲が広すぎるし、そもそもそういう直し方でいいのかという議論もあると思うので、俺みたいな素人ではなくvimprのコアなメンバーの皆様のご判断が必要と考えている。

2013年4月16日火曜日

Vimperatorプラグイン nextlink.js が動かないので調べた

2013.05.06 続編あり(とりあえず動くようにした)。 
 nextlink.jsとは何か
nextlink.jsは、AutoPagerize風のページ継ぎ足しを手動で実行することができるVimperatorプラグイン(だった)。
Googleの検索結果などの複数ページに跨るコンテンツを表示した状態で、キーボードより ]] と入力すると、1ページ目の下に2ページ目が継ぎ足される。さらに]]と入力すると、下に3ページ目が継ぎ足される(はずであった)。

括弧内に過去形で書いたのは、久しぶりに使ってみたらちゃんと動かなかったからである。2ページ目は取れるが、3ページ目以降が取れない。
ちょっと調べてみたところ、なんとなく原因が判明。

2013年4月13日土曜日

単身赴任先のマンションに「フレッツ 光ネクスト マンション・スーパーハイスピードタイプ 隼」を引いた

2013年4月から関西で単身赴任することになってしまったので関西に引っ越してきたわけだが、引っ越しといえばインターネット回線契約がつきもの。
引っ越し先の近所にある某家電量販店に相談に行くと、フレッツ光かzaq(J:COM)のどちらかならすぐできる、と言われたので、折角なので「フレッツ 光ネクスト マンション・スーパーハイスピードタイプ 隼」をチョイス。マンションだと、折角光回線を引いてもラストワンマイル(建物内)がVDSLとかにされて超しょべえことが多いが、この「隼」くんはマンションでも各部屋まで光ケーブルを引っ張ってくれるグレートな奴だ。しかも1Gbpsだ。
ただしプロバイダはYahoo BB指定。キャンペーンで色々特典がついたので、まあよしとする。

申し込みから待つこと約2週間、昨日ようやく工事が終わった。

2013年4月12日金曜日

IDP拡張フィールドを含むCRLをOpenSSLがうまく処理できなかった話(未解決)

CRLに関する備忘録。
CRLとCDPについておさらい
CRL(証明書失効リスト)とは、文字通り「失効したデジタル証明書のリスト」であり、失効済み証明書のシリアル番号が列挙されているものである。
CRLは一般的にWebサーバーやLDAPサーバー等に普通のファイルとして置かれており、デジタル証明書の検証をするシステム(認証サーバー等)はそのCRLをダウンロードして利用する。
下記は、とあるサーバーからダウンロードしたCRLの内容をOpenSSLで確認した例である。crlのファイル名はxxx.crlとする。(下記はDER形式の場合。PEMの場合は"-inform PEM"とする)
$ openssl crl -in xxx.crl -inform DER -text
Certificate Revocation List (CRL):
        Version 2 (0x1)
        Signature Algorithm: sha1WithRSAEncryption
        Issuer: /C=JP/O=HogeHoge, Ltd./CN=HogeHoge Public CA
        Last Update: Apr  3 10:00:00 2013 GMT
        Next Update: Apr 17 10:00:00 2013 GMT
        CRL extensions:
            X509v3 CRL Number:
                12345
            X509v3 Authority Key Identifier:
                keyid:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx

Revoked Certificates:
    Serial Number: 1234
        Revocation Date: Dec 12 00:00:01 2012 GMT
        CRL entry extensions:
            Invalidity Date:
                Dec 12 00:00:00 2012 GMT
    Serial Number: 1357
        Revocation Date: Dec 12 00:00:01 2012 GMT
        CRL entry extensions:
            Invalidity Date:
                Dec 12 00:00:00 2012 GMT
(snip)

2013年2月25日月曜日

CloudStack3.0のコンソールのキーバインド

多分いろんな人が既に言及していると思うけど、CloudStackのConsole Proxy(仮想サーバのコンソール画面をWebでユーザーに提供する機能)のキーバインドが結構ひどい。
端末側のキーボードが英語か日本語かによっても結果が違う。

当方、CloudStack 3.0ベースの某IaaSを利用中であるが、結構苦労している。
手元に英語キーボードと日本語キーボードの両方があるので、少し調べてみた。
なお、この某IaaSは、CloudStackにそこそこカスタマイズが入っているので、全ての環境で同じ結果かどうかは分からない。日本国内のIaaSなので、それ用にConsole Proxyのパラメータが設定されている可能性がある。
また、CentOS6.2での調査結果であることを最初に述べておく。他のディストリビューションやWindowsでは結果が異なるかも。

表を見ると分かるが、コロン、パイプ、アンダースコアなどに不自由する。これは厳しい。viを起動するとctrl+zで抜けなくてはならないし、そもそもファイルを保存できない。

2013年2月22日金曜日

CloudStackはCentOSベースの仮想アプライアンスと相性悪い

CloudStackにCentOS6.2ベースの仮想アプライアンスを入れて運用を始めた時の話。

まず、予備知識のおさらい。
CloudStackにCentOS6系のテンプレートを作成する際には、事前に
/etc/udev/rules.d/70-persistent-net.rules
を削除しておくのがお約束である。これをやっておかないと、テンプレートからインスタンスを作成した時に、NICを認識できなかったり、eth0のはずのNICがeth1やeth2として認識されたりと、色々な問題が起こる。
うっかり70-persistent-net.rulesを削除せずにテンプレートを作ってしまった場合、インスタンス作成後にファイルの中身を直してあげれば復旧可能である。

また、CloudStackにはインスタンスのSnapshotを取る機能があるが、そのSnapshotを復元するためには、Snapshotを元にしてテンプレートを作成し、そのテンプレートからインスタンスを作成するという手順を踏む必要がある。ここが素のHypervisorと違うところである。
すなわち、複製目的でテンプレートを作る時ばかりでなく、システム状態のバックアップを取る目的でSnapshotを取る際にも、
/etc/udev/rules.d/70-persistent-net.rules
を削除する必要がある。

で、仮想アプライアンスである。
今回私が取り扱ったそいつは、CentOSベースであるものの、好き勝手にいじれないように、CLIで使用できるコマンドはガチガチに制限されている(製品オリジナルのコマンドしか使えない)し、ファイルシステムの操作など一切できない。まあ、仮想アプライアンスって、そういうものである。
で、ファイルシステムが操作できないということは、
/etc/udev/rules.d/70-persistent-net.rules
を消したり編集することが一切できないのである。
これは困る。

実際にSnapshot作成⇒テンプレート作成⇒インスタンス作成を何度もやってみたところ、毎回結果が変わる。ほとんどの場合、NICの順番がおかしくなる(eth0とeth1が入れ替わるなど)。で、何度も試していると、たまに元通りのNICの順番になってくれることがある。なんだこの運ゲー。

以上、CloudStackと仮想アプライアンスの相性は決してよくない、というお話。