Cannot find daemon loader org/apache/commons/daemon/support/DaemonLoader

Apacheのcommons-daemonを使ってサーバープログラムをデーモン化しようとしていたらjsvcの起動でエラーに遭遇。

「Cannot find daemon loader org/apache/commons/daemon/support/DaemonLoader」

調べても解決してるっぽい記事がでてこない。
原因はjsvcの-cpオプションに指定するjarを相対パスでしていたことだった。
jsvcは-userを指定して実行ユーザーを変えたりできるのでJVM実行時のカレントディレクトリは別の場所になっているようだ。
-cpに指定するパスはすべて絶対パスにすることで起動に成功した。

dockerコンテナを別のコマンドで立ち上げる方法はver.1.1から？

docker1.1からコンテナを別のコマンドで立ち上げることができるようになるかも。
https://github.com/dotcloud/docker/issues/1228#issuecomment-45546178

dockerコンテナは停止してもstartコマンドで再度立ち上げることができる。
しかし、現在(v1.0)はstartコマンドはdocker runの時に実行したコマンドでしか起動できない。
もし障害が起きてコンテナが停止して、更にはコンテナがstartで起動しなくなっていたら、原因解析やデータを救出したりすることが難しくなる。

現時点でできる対策としては
・必ずsshdを同時に起動しておく
・volumeや--volumes-fromなどを使ってデータを隔離しておく
といったところ。

最悪これらの設定をしていなかった場合は停止したコンテナを一度commitしてイメージを作成してから再度docker runすることでコンテナが停止したタイミングのデータにアクセスできる。
まぁこれができれば問題ないじゃんって話もあるけど同じコンテナですぐに繋げられる方が楽だよね。

nsinitというのを使って直接dockerの空間にアタッチする方法があるので、それを使えばデータ救出や障害解析ができそう。

とはいえ、実験とかの時に無駄にコンテナを量産しなくてすむし、ぜひぜひ別コマンドでの起動に対応して欲しい。

dockerのEXPOSEはdocker run -Pもしくはdocker run --linkで意味を持つ

dockerのハマりどころとしてEXPOSEが理解できないというのがあると思う。
EXPOSEは書いただけで何か動作が変わるといったものではなく、他の機能から参照されて意味を持つ。
dockerに入門したてだとEXPOSEを指定しないとコンテナにネットワーク接続できないと勘違いしてしまったりするがそんなことはない。
EXPOSEしなくてもdocker run -pオプションでポートを外部公開できるし、dockerネットワークのIPを使ってコンテナ間もしくはホスト・コンテナ間で通信可能だ。

僕の知っている限り、EXPOSEの指定はdocker run -PもしくはDockerのlink機能を使ってコンテナ間連携をするときだけ意味を持つ。

doker run -PはEXPOSEしているすべてのポートをpublishする。
マッピングの指定をしないのでdockerが勝手にホストのポートを割り当てる。

docker run --link は連携対象のコンテナを指定するとEXPOSEしているポートに接続するための環境変数を付けてコンテナを起動する。

linkのドキュメント：
https://docs.docker.com/userguide/dockerlinks/


(この記事の情報は docker ver0.11.1 にて確認しています)

dockerは再起動しても変更が消えることはない

dockerに関する記事で「dockerは再起動すると変更が元に戻る」っていう書き方をしている人が多いけど誤解なのでこういう書き方はやめていただきたい。
docker run の意味は新しいコンテナでプロセスを起動するということであって再起動ではない。
そしてdockerには再起動という概念は別にあって、それは停止したコンテナに対するdocker startだ。
docker restartというコマンドもある。この再起動の場合にはコンテナ上の変更が元に戻るということはない。

cakephpのカスタムValidationでレコードの存在チェック

cakephp2.xにてカスタムValidationを使ってレコードの存在チェックを行う。
管理画面で各種IDを直接入力するような場合のチェックを想定。

/** 使い回しのため親クラスにカスタムValidationの関数を用意する */
class AppModel extends Model {
    public $uses = array('User');

    public function existsUser($check) {
        // countを使って存在チェック
        $count = $this->User->find('count', array('conditions'=>array('id'=>$check), 'recursive' => -1) );
        return $count > 0;
    }
}

/** validateの設定 */
class SampleModel extends AppModel {

    public $validate = array(

        'user_id' => array(

            'existsUser' => array(

                'rule' => 'existsUser',

                'message' => '存在するユーザーのIDを入力してください'

            )

        )

    );

}

クラウドによるパスワード管理はLastpassかKeePassのどちらが最適か。

クラウドでパスワードを管理

最近ではヘビーユーザーでなくてもWindowsもMacもAndroid端末も使っているという人が多くなってきているだろう。
そういう人は管理しているパスワードをすべてのデバイスから見れるように同期したいと思うようになるはずだ。

これを実現する方法として下記の２つが有力だ。

• Lastpassというクラウドサービスを使う
• KeePassというパスワード管理ソフトとDropBoxなどのオンラインストレージを組み合わせて使う

LastpassとKeePass+オンラインストレージの違い

パスワードの保存場所

Lastpass

Lastpassが提供するクラウドストレージ上にパスワードが保管される

KeePass

KeePass自体はクラウドを前提としたものではなく、ただのパスワード管理ツールである。DropBoxやGoogle Driveといったクラウドストレージサービスにパスワードファイルを置くことでパスワードを一元管理できる。

価格

Lastpass: iPhone/Androidから使う場合は1$かかる
KeePass: 無料

その他

ギズモードによれば自動入力などはLastpassの方が便利のよう。
十分なセキュリティ対策はされていると思うが日本ではLastpassはそれほど知名度がないし、ストレージにDropBoxなどが使えるKeePassの方が安心感がある。

参考

・ギズモードの本家サイト(英語)の記事：LastpassとKeePassの比較

VirtualBoxにWordpressを入れるとテーマインストールができない(dns解決失敗)

エラー

VirtualBox上のWordpressのテーマを検索しようとすると、エラーが発生してテーマ選択することができなかった。

curl関数の結果をechoしてみると「name lookup timed out 」というエラーメッセージを発見。DNSの解決がうまくいっていないようだった。

構成

VirtualBox 4.3.6
WordPress 3.8

VirtualBoxネットワーク構成
アダプタ１： NAT
アダプタ２：ホストオンリーアダプター

解決方法

VirtualBoxのネットワーク構成との関連で問題が起きているようだった。

/etc/resolve.conf でDNSを 8.8.8.8 （GoogleのパブリックDNS) に向けたところ正常に動作するようになった。

ホストオンリーアダプターのせいかと思ったが、NATオンリーにしても問題は解決しなかった。