いけてない ManifoldCF

最近 Apache ManifoldCF のパッチワーカーをやってます。
対応コネクタが豊富だし GUI で設定出来るしで結構使えるのですが、
一番の難点がドキュメントの不備だと思います。
どんなに便利で有能だったとしても使い方が判らなければ使い物になりません。

一応、公式サイトには HTML と PDF でユーザマニュアルが置いてあるのですが、
これが数年前から未更新のために最新仕様に追随出来ていません。
これでは折角の機能も全くの無駄になってしまいます。

という訳で、有用そうなのに使われていない機能を紹介していきたいと思います。
まずは JCIFS による Windows 共有からのクロール (ファイル収集) です。

「ManifoldCF JCIFS」で検索すると下記のロンウィットページが上位に出ますが、
これは情報が古過ぎて使えないので参考にしないで下さい。
Apache ManifoldCF -セットアップ-

Windows 10 以降の SMB/CIFS 3.x からクロールするには下記手順に従って下さい。

  1. jcifs-ng の JAR ファイルを Maven リポジトリからダウンロード。
    https://mvnrepository.com/artifact/eu.agno3.jcifs/jcifs-ng
    バージョン番号 (*1) をクリック→「bundle」をクリック。
  2. ダウンロードした JAR ファイルを下記ディレクトリにコピー。(リネーム不要)
    (ManifoldCF ホーム)/connector-lib-proprietary/
  3. 下記ファイルを編集。
    (ManifoldCF ホーム)/connectors.xml
  4. 下記一行を編集しコメントアウトを外す。
    <!--repositoryconnector name="Windows shares" class="org.apache.manifoldcf.crawler.connectors.sharedrive.SharedDriveConnector"/-->

    <repositoryconnector name="Windows shares" class="org.apache.manifoldcf.crawler.connectors.sharedrive.SharedDriveConnector"/>
  5. ManifoldCF を再起動。

(*1) どのバージョンが ManifoldCF で対応しているかが明示されていないため、
最新版から順に試してみる以外の確認手段がありません。
因みに ManifoldCF 2.18 は jcifs-ng-2.1.2 に対応していますが、
どうしても判らなければソースパッケージの build.xml で調べましょう。
(2021/02/24 追記)
2.18 は 2.1.2 用にビルドされているのですが、実際に試してみたところ 2.1.4 まではそのままで動きました。2.1.5 は残念ながらエラー画面を生じさせます。

これで ManifoldCF のリポジトリコネクション一覧に「Windows Share」が追加されます。
注意すべき点としては、ジョブ設定画面の「セキュリティ」タブでは、
必ず「共有セキュリティ (Share security)」を無効にして下さい。
多分、古い SMB1 用の設定なので、最近の Windows 共有ではエラーになります。
ユーザマニュアルにもその旨がしれっと書かれているんですが、
まず気づかないと思うのでお気をつけ下さい。

最近 Apache ManifoldCF のパッチワーカーをやってます。
対応コネクタが豊富だし GUI で設定出来るしで結構使えるのですが、
一番の難点がドキュメントの不備だと思います。
どんなに便利で有能だったとしても使い方が判らなければ使い物になりません。

一応、公式サイトには HTML と PDF でユーザマニュアルが置いてあるのですが、
これが数年前から未更新のために最新仕様に追随出来ていません。
これでは折角の機能も全くの無駄になってしまいます。

という訳で、有用そうなのに使われていない機能を紹介していきたいと思います。
まずは JCIFS による Windows 共有からのクロール (ファイル収集) です。

「ManifoldCF JCIFS」で検索すると下記のロンウィットページが上位に出ますが、
これは情報が古過ぎて使えないので参考にしないで下さい。
Apache ManifoldCF -セットアップ-

Windows 10 以降の SMB/CIFS 3.x からクロールするには下記手順に従って下さい。

  1. jcifs-ng の JAR ファイルを Maven リポジトリからダウンロード。
    https://mvnrepository.com/artifact/eu.agno3.jcifs/jcifs-ng
    バージョン番号 (*1) をクリック→「bundle」をクリック。
  2. ダウンロードした JAR ファイルを下記ディレクトリにコピー。(リネーム不要)
    (ManifoldCF ホーム)/connector-lib-proprietary/
  3. 下記ファイルを編集。
    (ManifoldCF ホーム)/connectors.xml
  4. 下記一行を編集しコメントアウトを外す。
    <!--repositoryconnector name="Windows shares" class="org.apache.manifoldcf.crawler.connectors.sharedrive.SharedDriveConnector"/-->

    <repositoryconnector name="Windows shares" class="org.apache.manifoldcf.crawler.connectors.sharedrive.SharedDriveConnector"/>
  5. ManifoldCF を再起動。

(*1) どのバージョンが ManifoldCF で対応しているかが明示されていないため、
最新版から順に試してみる以外の確認手段がありません。
因みに ManifoldCF 2.18 は jcifs-ng-2.1.2 に対応していますが、
どうしても判らなければソースパッケージの build.xml で調べましょう。 

これで ManifoldCF のリポジトリコネクション一覧に「Windows Share」が追加されます。
注意すべき点としては、ジョブ設定画面の「セキュリティ」タブでは、
必ず「共有セキュリティ (Share security)」を無効にして下さい。
多分、古い SMB1 用の設定なので、最近の Windows 共有ではエラーになります。
ユーザマニュアルにもその旨がしれっと書かれているんですが、
まず気づかないと思うのでお気をつけ下さい。

Android SDK R20 の emulator でハードウェアキーボードが使えない (続編)

R18 に戻すというのは確かに簡単で確実ではあるんだけど、いつまでも古い revision を使い続けるのは忍びないので改めて調べてみたところ、hw.keyboard の値を yes にする方法を見つけました。hardware-qemu.ini を手で書換えてはいけなかったんですね。ちゃんと AVD Manager から設定しなくては。

  1. ADV Manager を起動。
  2. 対象の ADV を選択し「Edit...」をクリック。
  3. Hardware: 欄の「New...」をクリック。
  4. Property: 欄から「Keyboard support」を選択し「OK」をクリック。
  5. Hardware: 欄に追加された「Keyboard support」の「Value」カラムをクリックし「yes」を選択。
  6. 「Edit AVD」をクリックし確認ダイアログを「OK」で閉じる。
  7. 必要な ADV の数だけ上記を繰返したら ADV Manager を閉じて完了。

後は、ADB Manager から起動しようが、起動 option 付のショートカットから起動しようが、不通に実キーボードが有効になります。単純な話でしたね。
とは言え、これ程重要なことは release note なり README なりに書いておいて欲しいものですねー。R20 から初めて使い始めた人は、Android emulator ってソフトウェアキーボードしか使えないもんだって思い込んでしまってもおかしくないと思います。

Android SDK R20 の emulator でハードウェアキーボードが使えない

Windows 用の Android SDK を R20 に上げたら、emulator (ADV) 環境でソフトウェアキーボードしか使えなくなってしまったので対処法。

  1. 下記 URL から R18 をダウンロード。
    http://dl.google.com/android/android-sdk_r18-windows.zip
  2. zip から android-sdk-windows/tools/emulator-arm.exe を展開。
  3. 展開したファイルを %ProgramFiles%\Android\android-sdk\tools にコピー。
  4. 同様に emulator-x86.exe もコピー。

R19 までは hw.keyboard = yes だったのに、hw.keyboard = no になったことに起因していると思われます。多分、Android 4.1 用の予測変換に対応するための措置なんでしょうけど、4.0.3 以前の ADV に対しては旧来のままにしてくれても良かったのにね。hardware-qemu.ini を手で書換えても emulator が自動的に上書きしてしまうので意味ありませんでした。hardware-properties.ini の既定値も yes から no に変わったので意図的なんでしょうね。

Cygwin 1.7.1 続報

先日お話しした、Cygwin 1.7.1 の vim が -iconv 状態で UTF-8 な環境では使い物にならないという件ですが、ここで報告してから丁度 24 時間後くらいに vim-7.2.264-2 として +iconv で re-build したパッケージが公開されてました。一応動作確認してみましたが、UTF-8 環境での cp932 や EUC-JP の編集も問題なく、一応の解決は見られたようです。.exrc の設定が必須なので、ある程度 I18N 状況に明るい人じゃないと対応出来ないとは思いますが、そのうちどこかにまとめサイトでも出来るといいですね。
さて、この blog は専ら私個人の備忘録的な位置付けで色々書いてるに過ぎないんですが、このレスポンスの速さを見るに、今回の vim の件って誰かこの blog 情報をチクったんじゃないかという気がしてます。7.2.264-1 の release が 2009/10/01 なんで、4 ヶ月も放置されてた障害が私が見つけた直後に修正されるってのは、偶然にしては余りに出来過ぎた話です。むむー、こんなトコをチェックしてる人はそんなにいないと思ってたんですがねー。
でも、どーせなら libtermcap の方を上訴してくれた方が幸せになれる人が多かったのに :-)

いけてない Cygwin 1.7.1

気がついたら Cygwin が 1.7.1 という新しい version になってたんですが、こいつがかなりいけてない。利用者を無視した独善的な「改良」を一方的に押しつけた結果、実用的に使えない代物になり下がってしまいました。もう release から一ヶ月以上経つと言うのに、誰も文句言わないってのはそれだけ使い倒されてないってことなのかしらん。
一つ目は勝手に termcap library (libtermcap) を撤廃しちゃったこと。まぁ最近の主流は terminfo かも知れないので、BSD なおじさん以外は policy 的には容認出来るとは思いますが、往年の UNIX な source が幾つか compile 出来なくなって嘆いている声も無くはない筈。まー、面倒なんでメンテしてられっかという気持ちは判るんですが、そもそも Cygwin ってそういう UNIX な source を Windows 上で compile したいってところから始まってるんじゃないのかしらん?それとも「UNIX = Linux」という考え違いをしてるのかなー。
二つ目は UTF-8 化です。既に Windows NT architecture は内部コードに UCS2 を使ってるんで、Cygwin も親和性を高めるために Unicode をって気持ちは判ります。でも、そういう運用が可能かどうか、もう少し調べてから移行すべきだったかと。最初は「設定をいじると UTF-8」にしておいて、暫く様子を見てから「標準が UTF-8」にすべきだったと思います。いきなりだったんで色々不都合出てますね。
特に CJK 圏ではまだ Shift_JIS が幅を効かせてたりして、text file の中身は Shift_JIS の方が多いと思います。で、Cygwinvim で開こうとすると UTF-8 じゃないので化け化け。vim って I18N 化してた筈と思って色々 .exrc に書いてみたけど駄目なので「vim --version」とか打ってみると見事に「-iconv」とか言ってきやがります。誰だ、libiconv 抜きの環境で build したのは。
因みに一つ前の古い vim (7.2.148-1) は +iconv なので、setup.exe でその古いのを install すれば vimShift_JIS なファイルも編集出来ます。但し、Linux な人は要注意。Linux の iconv と GNU libiconv では charset 名称の「Shift_JIS」が違うものを指します。GNU libiconv では「\」が 0xa5 に mapping された、そんなんどこで誰が使ってるのか聞いたこともない code 体系なので、当然「\」を含んだ text は編集出来ません。GNU libiconv では「cp932」を使いましょう。vim 的には「japan」が「cp932」の alias になってるのでそっちでも構いません。一応必要な設定を挙げとくとこんな感じ。

set fileencodings=cp932,utf-8,euc-jp,iso-2022-jp,latin1
set fileencoding=cp932
set encoding=utf-8
set termencoding=utf-8

fileencodings の順序は優先順位になってるので、utf-8 を優先させたい人は逆順にしましょう。あと、fileencoding も設定しておくと、空の text file を作成する時にその code が有効になります。これは utf-8 でも構わないと思います。

VMwareTools その後

VMware も 6.5.3 になって VMwareTools の非英語圏締出しに拍車が掛かって来ましたね。US-ASCII を前提とした個所が多過ぎて、もう個別の shell script に「LANG=C」を追加してたんじゃ追い着かなくなってます。特に vmware-config-tools.pl の中で「gcc --version」でバージョンチェックしているところがあって、LANG=C じゃないと必ず非対応コンパイラ扱いです。仕方ないので、起動時に「LANG=C ./vmware-config-tools.pl」とした方が手っ取り早そうですね。
因みに、これとは別に vmware-guestd や vmware-toolbox や vmware-users 辺りに「LANG=C」を追加するという hack は必要になるので面倒です。こいつらは config 時以外にも起動されるので、vmware-config-tools.pl に細工したって付け焼刃にしかなりません。兎にも角にも、VMware は非英語圏をとことん忌み嫌っている様子が徐々に表面化して来てます。時代に逆行するこの流れ、何とかならないもんでしょうかね?