Kanboard

Kanban Project Management Software

ちょっと、面白そう。

今度試してみようかな。

そういえば、昔、Tugboat.GTDを少しだけ試してみたことがあったのを思いだした（＾＾；

XML parsing failed : (413 Request Entity Too Large)

svn update（厳密には、TortoiseSVNからの作業）を行おうとすると、こんなエラーが。。。

XML parsing failed: (413 Request Entity Too Large)

文字通り、リクエストデータのxmlがデカすぎるってことのようなのですが、同様の報告は過去にもあったようで、413 Request Entity Too Largeの内容で一発で解決。

Subversionのリポジトリを割り当てているLocationディレクティブ内に、

LimitXMLRequestBody 0

を記述してApacheを再起動すると解決。

どの程度の大きさのデータをリクエストしてエラーになったのかが分からなかったので、いったん、チェックをしない設定にしました。ただ、セキュリティ等のことを考えると、実際にはチェックを行うようにすべきなんでしょうね。

参考） LimitXMLRequestBody ディレクティブ

Fess

めっちゃひさしぶりに更新（笑

オープンソース全文検索サーバー Fess

5 分で簡単に構築可能な全文検索サーバー と記載されていますが、確かに、サクッと構築することができました（笑）。
Apache Solr で構築しようと考えていたのですが、セットアップやら、フロントエンドは自前で作る必要があったりするなど、そこそこ時間がかかりそう。その昔、Apache Luceneを作って、某アプリケーションに組み込む検索機能を構築したことはあるのですが、今はとにかくサクッと環境を構築したかったので。

» Continue reading

0x82

Shift-JISにおいて 0x82 で始まる２バイト文字には、アルファベット、数字、ふりがなが含まれるんですね。

つまり、「ひらがな」というデータは、その気になれば（？）８バイトではなく４バイトで格納出来るってことに（笑

KVMでネットワークをNATにしている場合

KVMでネットワーク環境をBridgeからNATに戻したわけなんですが、思わぬところではまってしまいました・・・。

VM1 192.168.11.201(外部) ⇔ 192.168.101.201(内部)
VM2 192.168.11.202(外部) ⇔ 192.168.101.202(内部)

というようなネットワークを構築していて、192.168.101.201から192.168.101.202に通信を行う場合、VM2からみると、192.168.11.201からアクセスしてきている感じになるんですね。

PostgreSQLの pg_hba.conf などで、接続元IPアドレスを192.168.101.201などに限定していた場合、接続が拒否られてしまうことに・・・。この部分で１時間ほど悩んでいたような・・・。

VM2でifconfigを実行しても、192.168.101.202しか見えない（当然）ので、なかなか気付きませんでした（悩んだ末に、試しに 192.168.0.0/16 でアクセスを許可するようにすると接続出来たので気付きました）。

＃KVMをきちんと使っている人からすると当たり前のことなのかもしれませんが。

PostgreSQL全機能バイブル

PostgreSQL9.2対応。

それはさておき、ストリーミングレプリケーションに関する説明などもあり、運用面においてもそれなりに有用なのではないかと。

先日、同期レプリケーションを行っているPostgreSQLで、スレーブ側の端末でトラブルが発生してしまったわけでして。ディスク障害やメモリ障害、CPU障害といった致命的な内容ではなさそう（端末およびPostgreSQLは稼働し続けていたので）なのですが、かといって放置するわけにも行かず、スレーブ端末をシャットダウンする必要がでてきてしまいました。単純にスレーブを停止させると、マスター側のトランザクションが止まってしまうのは知っていたので、さてさて、どうしたものか？

同期レプリケーションの設定方法や、マスターに障害が発生したときの資料はWebでも結構見つかるのですが、スレーブ側に障害が発生したときの資料ってのがなかなか見当たらず・・・で、いろいろと調べてたどり着いたのが、この書籍でした（笑）。
PostgreSQL 9.1 - 同期レプリケーションの障害対応 のところで、この書籍が紹介されていたので。

まずは、テスト機で検証してみるかな・・・。

Apache-Tomcat通信で接続エラー

Apache-Tomcatの通信部分でApache側に

APR does not understand this error code:

や

All workers are in error state for route

といったエラーが発生。

連続してリクエストを投げ続けているとき（処理し続けているとき）は、何の問題もなく安定しているのですが、数時間リクエストがなくなっている状態から、再度リクエストを投げ始めたときにしばしば発生しているようです。

mod_proxy_ajpでエラー発生。。。 や mod_proxy_ajp で Apache と Tomcat の間の通信が切断されてしまう の内容に近い感じでしょうか。
私のところの環境では、ApacheとTomcatの間にFirewallを設置しています。

BalancerMemberのところでは、disablereuse=on keepalive=offのパラメータを指定しているのですが、それが上手く効いていないんでしょうかね？？（他に、AJPの場合は関係ないのかもしれませんが、mod_proxy - ProxyPass、BalancerMemberのパラメータのdocumentを読んだのでまとめたを参考に、 SetEnv proxy-nokeepalive 1の設定も行っています）

mod_proxyの資料 では、

disablereuse：Apacheとバックエンドサーバの間にファイアウォールが存在して切断を切られる場合は On に設定する
keepalive：バックエンドサーバと Apache の間にファイアーウォールがある場合には、 このパラメータを使う。

とあります。コネクションプーリングをしないと、keepaliveを行う必要はないのでは？　と思ったりするんですよね・・・（なので、disablereuse=on keepalive=off という設定にしています）。まさか、設定が、onでは駄目でOnにしなければならないとか言うことはないと思うのですが・・・（ソースでIgnoreCaseあるいはUpperCaseなどをしているかどうか確認すれば確実なのですが）。

Firewallの部分の設定を変更してもらえるようであれば、そちらで対応するのが確実かな・・・。

snmptrapdでtraphandleが反応しない

snmptrapdで他からのメッセージを受信。
syslogには問題なく出力されているのに、traphandleが反応しない・・・。

例によって、例のごとく（？）、SELinuxの影響でした（苦笑

ただ、SELinuxを有効にした状態でコマンドを実行する方法がわからず、仕方なく、 setenforce 0 でpermissiveモードにして逃げてしまいました・・・（涙）。

# chcon -t snmpd_exec_t test.sh

のようにした場合、test.shそのものは実行出来るようになったのですが、その中で呼び出しているコマンド（例えばmailなど）を実行するタイミングでSELinuxに阻まれてしまいました・・・。

シェルスクリプトはさておき、それ以外の実行ファイルも片っ端からchconするというのは何か間違っているような気がするので、いったん、permissiveモードで逃げることにするかなぁ・・・。

CaptureNX2

Capture NX2を購入。

RAW現像／編集ソフトなら、他にも多くの製品があるのですが、D7000のRAWファイル(NEFファイル)を、オリジナルの状態を維持したまま編集可能、というのが選択の最大の理由かな。

早速何枚か編集してみたのですが、「カラーコントロールポイント」は結構便利ですね。
それ以外だと、露出補正／トーンカーブ調整程度しかまだ使っていませんが（＾＾；

ちなみに、Capture NX2はGPXファイルを用いたログマッチングは対応していないんでしょうか。まぁ、ViewNX2と使い分ければいいだけでしょうけど。

SSLInsecureRenegotiation

同じSSLクライアント証明書でも、端末によってアクセス出来たり出来なかったり、という現象に遭遇。

サーバーのログを見てみると、

SSL3_ACCEPT:unsafe legacy renegotiation disabled

のメッセージが。

で、調べてみると、IE-Apacheで急にSSLクライアント認証ができなくなった と同じ現象っぽい。

試しに、

SSLInsecureRenegotiation on

の設定を追加すると、一応アクセス出来るようになりました。

おそらく、Windowsのアップデート状況などに起因して現象が出る／出ないがあったのではないかと。

Insecureとあるだけに、可能なら on にしない方がよいのでしょうが、接続元の端末が特定出来ない状況では、 on にするのが現実的なところでしょうね・・・。