野菊のハッカー:TIPSとかKludgeとか

ThunderBird 2.0のアドレス帳に自前のLDAPサーバを指定する

以下、prefs.jsとかの知識がある前提での覚え書き。

検索フィルタの指定を行う

Mozilla定義のアトリビュート名と自分のLDAPがあっていない場合

user_pref("ldap_2.servers.myldap.attributes.cn", "氏名:cn;lang-ja,cn");

user_pref("ldap_2.servers.myldap.attrmap.Company", "companyname");

user_pref("ldap_2.servers.myldap.attrmap.DisplayName", "cn;lang-ja,commonname"); // これはNGだった

送信メール作成画面の宛先指定欄のドロップダウンリストに、例えば「会社名」とか「組織名」みたいな付加情報を付けたい

user_pref("mail.autoComplete.commentColumn", 2); // 1 にすると、検索しているディレクトリ名が表示されるので、２にする。

user_pref("ldap_2.servers.myldap.autoComplete.commentFormat", "[divisionshortname;lang-ja]");
user_pref("ldap_2.servers.myldap.autoComplete.nameFormat", "[cn;lang-ja]");

参考になるサイト
LDAP in Mozilla Thunderbird
Mail and news settings
アドレス帳の隠し設定

# by signal-9 | 2009-09-18 12:50 | TIPSとかKludgeとか | Trackback | Comments(0)

Proxy.pacをCGI(ASP.NET)でユーザ毎に切り替えてみるテスト。

　Proxy.pacで利用者にプロキシ設定を配っているのだが、「人によってその設定を変えたい」という話。
　例えば、ユーザＡでログインした場合にはＡ－プロキシを使わせ、ユーザＢだったらＢ-プロキシを使わせ…というのをどうしたらいいか。

　いちいちログイン画面出して…つーのはＮＧだし、お金もかけたくないからアリモノだけでなんとかしたい。

　もちろん、マトモな方法としては　グループ・ポリシーでProxy設定を行うなどの方法が正解なのはわかってるのだが、ちょっと思いついたのが、Proxy.pac自体をロードする時にユーザIDに応じて差し替えちゃえばいいんじゃね？というアイディア。

　既存のProxy.pac共有サーバは、利用者と同じドメインに入っているIISなので、とりあえずはそのまんまWindows認証を流用してみることにする。

IISに統合Windows認証ありの仮想ディレクトリ　ProxyPac を作成する。

テスト用のスクリプトを用意。やることはProxy.PACファイルをMIMEタイプを付けてクライアント返すこと。

protected void Page_Load(object sender, EventArgs e) {
string uname;
string filename;
uname = HttpContext.Current.User.Identity.Name; // ドメイン名￥ユーザIDが返る
if ( uname == "mydomain\\userID" ) { // ￥記号はエスケープね
filename = MapPath("Special.pac"); // 特別なプロキシ設定ファイル
} else {
filename = MapPath("Normal.pac"); // 標準的なプロキシ設定ファイル
}
if(System.IO.File.Exists(filename)) {
System.IO.FileInfo fileInfo = new System.IO.FileInfo(filename);
long nSize = fileInfo.Length;
Response.Clear();
Response.ContentType = "application/x-ns-proxy-autoconfig"; // pacのMIMEタイプ
Response.WriteFile(filename, 0, nSize);
Response.End();
}
}

ＩＥブラウザ側で、このサーバ(myserver)を明示的にイントラネットに属させる。

ブラウザ側で自動プロキシ設定URLを　http://myserver/ProxyPac/ProxyPac.aspx に切り替えてテスト。

挙動的にはよさげだが、保守運用がめんどくさいかなぁ。

# by signal-9 | 2009-09-15 18:02 | TIPSとかKludgeとか | Trackback | Comments(0)

WSS3.0(Windows SharePoint Service)のトラブルシュート。

　こういう仕事は基本的に受けないのだが、加藤あい似の担当者の女性の美脚に迷ってウカウカと受けてしまったWindows SharePoint Serviceの立ち上げのお手伝い。

「インストールは終わって画面はちゃんと出るし操作もできるので、基本的な設定はできてると思うんですが検索機能が動かないんです」

「はあ」
（ううううううんミニスカは目の毒だなぁウレシイけど）

「よく見てみたら『イベントビューワー』に何かエラーも出てるし」

「はあ」
（なんつーかこのミニスカつーの発明した奴にはノォベル賞をやりたいよなマジで）

と、脳内勃起していても仕方ないんでちょっとググッみると、確かにちょいと問題があるようである。

■問題：「WSS3.0で基本認証のみ有効のサイトは検索エンジンがクロールできない」
　単純に言うと；

WSSの画面でいくら検索をかけても結果が表示されない
イベントビューワにエラーコード 2436 などが表示されている

　これはMSのサイトでも明示されているとおりの仕様ではある。このクローラは認証にフォームやBASICを使っていると使用できない。

　で、どうするかなんである。困っている美脚を放置するなんてことができるか？　いやできはしないのである！

　確かに上のＭＳのサイトには（日本語のものは明らかに誤訳－フォーム認証の訳をそのまま引きうつしている－なので、英語版を参照のこと）手順が書いてあるが、この「手順」を読んでそのまんま理解できるやつはそう多くはなかろう。
　というか、明らかに不備がある。日本語のは論外としても英語版でさえ説明不足もいいところである。

　Webを漁ると、いくつか解決策を提示しているサイトもある。例えばCodenameさんのBlogとかquick2seekさんのサイトとか。
　だが、WSSという仕掛けはネットワーク含めた環境の設計がけっこう重要な要素で、この環境で上手くいったからそのまんま適用できるというわけでもない。美脚もこのあたりはやってみたらしいのだが上手くいかなかったと。

「うううううん。基本認証諦めるってわけにはいかないんですか？　元々イントラで使う仕掛けだし御社はちゃんとＡＤ動いてるし」

「それがこのサーバ、運営委託していてhttpアクセスには必ずプロキシを経由しなきゃいけないんですぅ」

「…ヤリイカかぁ。こりゃあWindows認証は通らないわなぁ」

　ファーム構成つーことになると話は厄介だが、幸いなことに単純なシングルサーバだ。
　で、こうしてみた。

　話の都合上、サーバ名（NetBios名）をfoo, DNS名をfoo.bar.co.jpとする。

まずインストール時にWSSが勝手に作ったSharePotal-80 Webアプリケーションを削除。
別にそのまま使ってもいいのだが、美脚が弄り回した環境をいったん綺麗にしちゃいたいので（笑）
Webアプリケーションを自前で作成しなおす。
　「アプリケーション構成の管理」→「Webアプリケーションの作成または拡張」→「新しいWebアプリケーションの作成」
　新しいIISWebサイトを作成する
　ポート80 / ホストヘッダ指定なし
　認証プロバイダ：NTLM
　ＵＲＬ：/foo.bar.co.jp：80
　検索サーバ：foo
「アプリケーション構成の管理」→「Webアプリケーションの作成または拡張」→「既存Webアプリケーションの拡張」で、上で作ったWebアプリケーションを拡張する。
　「新しいＷｅｂサイトを作成する」：ただしこのときポートは上で使っていたのと変えてしまう。ここでは9080を指定。
　ポート9080 / ホストヘッダ指定なし
　認証プロバイダ：NTLM
　ＵＲＬ：foo.bar.co.jp：9080
　「領域」：イントラネット
「認証プロバイダ」で、
　「規定」サイトが「匿名アクセスの有効化」・統合Windows認証であることを確認。
　「イントラネット」を「匿名アクセスの有効化」「基本認証」をＯＮ

この状態で、IISの管理画面でディレクトリセキュリティを確認すると
foo.bar.co.jp:80　→　匿名許可・統合Windows認証
foo.bar.co.jp:9080　→　匿名許可・基本認証
になっているはず。
iisreset。

　大筋こんな感じで。

　つまり、どうもmssearchは領域「規定」で定義されたサイトをクロールするようなので、そこだけNTLM認証にし(http://foo.bar.co.jp:80)、一般アクセスには同じサイトをポートを変えて見せてしまう(http://foo.bar.co.jp:9080)というセンである（今考えたらポート番号が逆の方がよかったなぁ）。

　これで良しとは思わないが－「ファームにしたい」なぁとか思った瞬間に破綻する－、とりあえず検索できるようになり美脚からソンケーの眼差しで見られたので、これでいいや（爆）

　で、美脚ともう暫く過ごしたかったので、ついでに細かい問題も。

■PDF検索設定

IFilter入手＆インストール。このとき合わせて１７×１７ドットのアイコン(pdficon_small.gif)も入手しておく。
すでにWSSが導入済みで、Searchが動いている場合には一時停止
ＭＳの資料どおりレジストリの設定
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Shared Tools\Web Server Extensions\12.0\Search\Applications\GUID\Gather\Search\Extensions\ExtensionList\
38
REG_SZ
pdf
を新規作成。
前で入手したアイコンGIF（pdficon_small.gif）を　\Program Files\Common FIles\Microsoft Shared\Web Server extensions\12\TEMPLATE\IMAGES　にコピーする。
\Program Files\Common FIles\Microsoft Shared\Web Server extensions\12\TEMPLATE\XML　にあるDOCICON.XMLのセクションに以下の行追加。
<Mapping Key="pdf" Value="pdficon_small.gif" OpenControl=""/>
できればサーバ再起動（できなければsearchサービスを起動）。

ちなみにフルクロールはcmdで
stsadm -o spsearch -action fullcrawlstart
だが、この設定をやる前にすでにアップ済みのPDFがある場合には、フルクロールしても対象にならない模様。
事前登録済みのPDFファイルは削除して再登録が確実。

■XML Webパーツで「タイムアウト」が発生する

　外部のニュースサイトを設定してFeedを表示させようとしたら「Webパーツがタイムアウトしました」が出る。

　この話はMSの解説にもある。

WSSのweb.config（IISからみるとwebroot/VirtualDirectory配下のサイト個別のweb.config)をエディタで開く
以下のセクションを追記する
<system.net>
<defaultProxy>
<proxy proxyaddress="http://プロクシ:ポート" bypassonlocal = "true"/>
</defaultProxy>
</system.net>
iisreset

　XML Webパーツを配置して、適当なニュースサイト(こことか)を指定して、適当なxsltを設定してやったらウマいことニュースが表示された。

　「すっごーい」

　「はは。いやいや。でもこれだと毎度毎度読みに行っちゃうんで、ホントはサーバ側で適当なタイミングで取得したデータを表示するだけにした方がいいと思いますよ。ちょっとしたスクリプトを作らないとだめですけど」

　「…えっと、よくわからないんですけど」

　あああああああああああカワイイなあ畜生しようがねぇオジサン作っちゃおうかなぁオネエちゃん綺麗だし（爆）

# by SIGNAL-9 | 2008-07-31 12:04 | TIPSとかKludgeとか | Trackback | Comments(2)

ASP.NETでFCKEditorを使う覚え書き

ここではMicrosoft Visual Web Developer 2008 Express Editionで、IISは使用せずWeb Developer 2008組み込みのWebサーバを使用するものとする。

本家サイトのダウンロードページから、最新のZIPファイル（本項記述時点ではFCKeditor_2.6.2.zip）とFCKeditor.Net（FCKeditor.Net_2.5.zip)をダウンロード。
それぞれ展開する。
デフォルトではIISに専用の仮想ディレクトリを作成するが、IISは使わないのでここではプロジェクトのWebサイトの下に配置する。
FCKeditor_2.6.2.zipを展開したディレクトリ(FCKeditor)をまるごとプロジェクトのWebサイトの下にコピーする（_（アンダーバー）付きのファイル・ディレクトリ、使用しないスキンは省ける）。
プロジェクトのWebサイトにbinディレクトリを作成する。
FCKeditor.Netを展開したディレクトリの\bin\Release\2.0にあるFredCK.FCKeditorV2.dllをbinディレクトリに配置する（bin右クリック→「既存項目の追加」で展開したFredCK.FCKeditorV2.dllを指定すると、binにコピーされる）。
FredCK.FCKeditorV2.dllを参照追加。
必要であれば、ツールボックスにも追加（「ツールボックス」→右クリック→「アイテムの選択」→「.NET Frameworkコンポーネント」で「参照」ボタン→FredCK.FCKeditorV2.dllを指定。ただしこれをやるならFredCK.FCKeditorV2.dllはサイト配下のbinではなく適切な共通ディレクトリの方がよかろう）
組み込みたいページの先頭に、
<%@ Register Assembly="FredCK.FCKeditorV2" Namespace="FredCK.FCKeditorV2" TagPrefix="FCKeditorV2" %>
を追加。
さらにコントロールのコード
<FCKeditorV2:FCKeditor ID="FCKeditor1" runat="server" BasePath="fckeditor/" Height="400px"></FCKeditorV2:FCKeditor>
を追加（BasePathがデフォルトだと"/fckeditor/"なので、アタマの/を除外）
念のため、fckeditor/fckeditor.jsのFCKeditor.BasePath = '/fckeditor/'のアタマの/もとっておく。
ページをビルドして確認（BasePathの設定がおかしいとhttp 404が出る）。

プログラム中ではFCKeditor1.Valueで入力内容が参照できる。

ただしナマのデータなので、そのまま使おうとすると局面によってはASP.NETがValidateRequestで引っ掛けてHttpRequestValidationException する場合がある。開発時には@pageでValidateRequest="false"にしておくとかすると便利かも（外し忘れると大変だが)。

# by SIGNAL-9 | 2008-07-10 14:13 | TIPSとかKludgeとか | Trackback | Comments(0)