いけてない Mattermost
突然ですが勤務先を退職しました。
暇な時間が増えたので、Linux 向けのチャットツール探して遊んでたんですが、
余りニーズが無いのかどれも丁寧なメンテがされているとは言えない状況で、
そりゃ Teams の一人勝ちもむべなるかなと痛感しましたね。
まず Zulip を試そうとしたら Debian 系専用だってんで早々に退散。
次に Rocket.Chat を試したんですが、
MongoDB とか GraphicsMagick とか、
特殊な環境に依存し過ぎで辟易とさせられた挙句、
6.5 からプラン変更になったコミュニティ版とやらが入手方法不明で断念。
GitHub でソース公開してるのがそれっぽいのですが、
ライセンス絡みの話なので明確に区別付けてくれないと恐くて使えません。
最後に辿り着いたのが Mattermost なんですが、
無償の Team Edition 特有の話なのか、
門前払いを目的としたかの如くの不親切さで相当の時間を浪費しました。
まー、Microsoft の如く、
「これ以上ユーザ増えたらメンテ大変なので嫌がらせ実装を増強」
といったポリシーでもあるのかも知れませんが、
導入開始でいきなり躓かされるのは全くいけてません。
何がいけてないって、ユーザ新規作成でまず躓くんです。
多分、管理者ユーザ作ったらその次くらいに行なう作業だと思うんですが、
そこで躓いたら絶対に導入を諦めちゃうと思うんですよね。
Mattermost の新規ユーザ追加には大きく二つの手段があって、
一つはアプリ画面から招待する方法で、
もう一つはコマンドラインの mmctl で追加する方法です。
わざわざどっちにも罠を仕掛けてあるという手の込んだ仕掛けになってます。
前者の場合、入力したメアドに招待メール送信してくれるもんと思いきや、
新規ユーザ登録用のフォーム用意するだけで、
その URL をコピペして自分で送信しろという手順になっています。
それならそれでそうと判る UI になってなくちゃ。
設定ファイルいじれば自動メール送信になるんですが、
初期設定ではそうなっていないために何やっていいのかさっぱり不明でした。
で、仕方なく後者の手順に挑戦するんですがここにも大きな罠が。
テスト用に適当なユーザ名とパスワードで試したんですが、
パスワードに「8 文字以上」という制限があるらしく、
それに違反するとユーザ追加時にエラーになってしまいます。先に言え！
しかもそのエラーメッセージが「failed to decode JSON payload into AppError.」。
原因がまるで通じないエラーメッセージの良い見本ですね。
さんざ調べて原因に辿り着いた時には悪意すら感じてしまいました。
という訳で、公式サイトの導入手順では触れられていませんが、
オンプレ環境に導入の折には config.json の下記設定をお奨めします。
- "EnableLocalMode": true
→mmctl コマンドの有効化 - "MinimumLength": 5
→パスワード文字数制限はまず最小値から - "EnableEmailInvitations": true
→招待メールは最初から有効に - "SMTPServer", "SMTPPort"
→招待メール用にサイトに合わせた設定が必須 - "EnableSMTPAuth", "SMTPUsername", "SMTPPassword", "ConnectionSecurity"
→SMTP 環境によってはこの辺りの設定も - "DefaultServerLocale": "ja", "DefaultClientLocale": "ja"
→英語の苦手なユーザが多いなら必須
招待メールに関しては、実際クラウド版では既定値で有効だそうです。
オンプレ版ではメール送信に SMTP 設定が必須という事情は判りますが、
「SMTP 未設定で招待メール送信に失敗」エラーでも吐かせりゃいいじゃん。
最初から「招待」ボタンをグレーアウトする今の実装だと、
行なうべき作業をユーザに誘導出来ていないんですよ。
UI ってもんは「マニュアルで説明すれば判る」レベルでも失敗で、
その UI の中で完結された状態でユーザに伝える必要があると思います。
そういうことに気付かせてくれるという意味では良い教科書になっていますね。
続: 作者ホームページ引越し
引越し先は CentOS なので Apache は RPM パッケージなのですが、
標準の httpd.conf が「Options Indexes」になってたので、
index.html の無いディレクトリが中身丸見えでした。
autoindex.conf による /icons/ 丸見え問題は、
どうせ他人の用意したコンテンツなんでどうでもいいんですが、
/var/www/html ごと丸見えってのはどうなのよ。
早速ディレクトリごとごっそり抜き取った人がいたようなので、
ftp:// 代わりに用意した /src/ 以外は -Indexes にしました。
あと、特に支障なさそうだったんで、
リダイレクトスクリプトに付けた確認ダイアログは外しました。
これでロボットさんもリダイレクトされてくれるかと。
作者ホームページ引越し
hp.vector.co.jp がサ終ってんで、取り敢えず全コンテンツを移しました。
http://www.unixusers.net/authors/VA012337/
RewriteRule の記述が楽になるようにわざわざ階層揃えたのに、
.htaccess が無効になってるようで、
JavaScript でページ毎にリダイレクト処理を追記しました。
めんどくせー！
JavaScript だと 301 リダイレクト使えないので、
検索エンジンは書換えが期待出来ないでしょうね。
念の為に噛ませた確認ダイアログがクローラを排除しちゃうので、
暫く様子見て問題なさげなら確認無しで無条件リダイレクトにする予定。
いけてない ManifoldCF
最近 Apache ManifoldCF のパッチワーカーをやってます。
対応コネクタが豊富だし GUI で設定出来るしで結構使えるのですが、
一番の難点がドキュメントの不備だと思います。
どんなに便利で有能だったとしても使い方が判らなければ使い物になりません。
一応、公式サイトには HTML と PDF でユーザマニュアルが置いてあるのですが、
これが数年前から未更新のために最新仕様に追随出来ていません。
これでは折角の機能も全くの無駄になってしまいます。
という訳で、有用そうなのに使われていない機能を紹介していきたいと思います。
まずは JCIFS による Windows 共有からのクロール (ファイル収集) です。
「ManifoldCF JCIFS」で検索すると下記のロンウィットページが上位に出ますが、
これは情報が古過ぎて使えないので参考にしないで下さい。
Apache ManifoldCF -セットアップ-
Windows 10 以降の SMB/CIFS 3.x からクロールするには下記手順に従って下さい。
- jcifs-ng の JAR ファイルを Maven リポジトリからダウンロード。
https://mvnrepository.com/artifact/eu.agno3.jcifs/jcifs-ng
バージョン番号 (*1) をクリック→「bundle」をクリック。 - ダウンロードした JAR ファイルを下記ディレクトリにコピー。(リネーム不要)
(ManifoldCF ホーム)/connector-lib-proprietary/ - 下記ファイルを編集。
(ManifoldCF ホーム)/connectors.xml - 下記一行を編集しコメントアウトを外す。
<!--repositoryconnector name="Windows shares" class="org.apache.manifoldcf.crawler.connectors.sharedrive.SharedDriveConnector"/-->
↓
<repositoryconnector name="Windows shares" class="org.apache.manifoldcf.crawler.connectors.sharedrive.SharedDriveConnector"/> - 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 共有ではエラーになります。
ユーザマニュアルにもその旨がしれっと書かれているんですが、
まず気づかないと思うのでお気をつけ下さい。
Android SDK R20 の emulator でハードウェアキーボードが使えない (続編)
R18 に戻すというのは確かに簡単で確実ではあるんだけど、いつまでも古い revision を使い続けるのは忍びないので改めて調べてみたところ、hw.keyboard の値を yes にする方法を見つけました。hardware-qemu.ini を手で書換えてはいけなかったんですね。ちゃんと AVD Manager から設定しなくては。
- ADV Manager を起動。
- 対象の ADV を選択し「Edit...」をクリック。
- Hardware: 欄の「New...」をクリック。
- Property: 欄から「Keyboard support」を選択し「OK」をクリック。
- Hardware: 欄に追加された「Keyboard support」の「Value」カラムをクリックし「yes」を選択。
- 「Edit AVD」をクリックし確認ダイアログを「OK」で閉じる。
- 必要な ADV の数だけ上記を繰返したら ADV Manager を閉じて完了。
後は、ADB Manager から起動しようが、起動 option 付のショートカットから起動しようが、不通に実キーボードが有効になります。単純な話でしたね。
とは言え、これ程重要なことは release note なり README なりに書いておいて欲しいものですねー。R20 から初めて使い始めた人は、Android emulator ってソフトウェアキーボードしか使えないもんだって思い込んでしまってもおかしくないと思います。
Android SDK R20 の emulator でハードウェアキーボードが使えない
Windows 用の Android SDK を R20 に上げたら、emulator (ADV) 環境でソフトウェアキーボードしか使えなくなってしまったので対処法。
- 下記 URL から R18 をダウンロード。
http://dl.google.com/android/android-sdk_r18-windows.zip - zip から android-sdk-windows/tools/emulator-arm.exe を展開。
- 展開したファイルを %ProgramFiles%\Android\android-sdk\tools にコピー。
- 同様に 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 に変わったので意図的なんでしょうね。
