admin のすべての投稿

CentOS7でのezmlm-idx

qmail+ezmlm+ezmlm-idxでメーリングリスト。

CentOS7になってまで使っている人は少ないだろう。

が、あえて、この話題。備忘録的な意味も含めて。

 

この組み合わせはCentOS7でも使用可能。しかし、そのままでは使用出来ない。

ezmlm-idxが悪さをしており、ezmlmが一切動作しないのである。

 

原因は、ezmlm-idxにある「sub-std.c」。

「FATAL」と「USAGE」という文字列変数が定義されておらず、

Could not load plugin /usr/local/lib/ezmlm/sub-std.so: /usr/local/lib/ezmlm/sub-std.so: undefined symbol: FATAL

なんてエラーを吐き出す。なぜ、コンパイル時にエラーを出さないのか、小一時間程、問い詰めたい。

 

解決方法は、下記のように「sub-std.c」に「FATAL」と「USAGE」という文字列変数を定義してあげればいい。

const char FATAL[] = “sub-std: fatal: “;

const char USAGE[] = “sub-std: usage: “;

これで正常に動作する。なぜ、コンパイル時にエラーをd(ry。

 

もし、CentOS7でqmail+ezmlm+ezmlm-idxを使う際は参考にしてほしい。

うちもそろそろpostfixに移行しないと。

 

次回は、kickstartでNetworkの設定をする件について記載する予定。

 

 

レンタルサーバでCentOS7を使いたい場合

ぴっとさ~ぶ

CentOS7について

CentOS7について書いてよ!って言われたから書いてみようと思う。

弊社のレンタルサーバに導入可能なOSにCentOS7が追加された。

詳細はこちら→ http://www.pitserv.jp/

 

導入検証は1ヶ月以上前には完了していたが、

上記のホームページの修正が追いつかず、公開までに時間がかかった。

今後、CentOS7に関する技術情報を書いていきたいと思う。

 

ネタはそこそこ揃っている。はず?

MySQLの文字化け対応

下記のような仕様で管理しているDBと表示の際の文字コードが異なる場合がよくある。

DB:UTF-8
表示:Shift-JIS (プログラムソースコード:Shift-JIS)

その場合、日本語の文字化けが発生するので、回避策として下記の変換をしているが

mb_convert_encoding($mojibake, ‘SJIS’, ‘UTF-8′);

「髙」や「﨑」の特殊文字があると正しく変換されないため、おすすめできない。
しかし、下記を実施すると

mb_convert_encoding($mojibake,’SJIS-win’, ‘UTF-8′);

正しく変換されるがプログラム修正が多くなる場合がある。
そこでおすすめしたいのが、「set names cp932」だ。
データ取得前に、SQLで実行するだけと、プログラマにやさしい
これは「set names sjis」と実行し文字化けた場合にも有効なのだ。

OpenIG自習室(第11回:OpenAM連携 Vol.4)

takaです。

前回はOpenIGとOpenAMを連携させるためのエージェントアプリケーションをインストールしました。

今回はいよいよ、OpenIGとOpenAMの連携動作を確認します。

検証作業は、以下の環境で実施しています。
(同一ハードウェア上で複数サーバを起動しています)

OS :Ubuntu 12.04 LTS
CPU:Intel Celeron 2.20GHz
MEM:2GB

検証サーバ: www.example.com (192.168.0.10)
アプリケーションサーバ(Apache2+PHP:ポート80)
OpenIGサーバ(Tomcat6:ポート8080)
OpenAMサーバ(Tomcat6:ポート18080)


1. OpenIGのconfig.jsonを編集

OpenIGの設定を変更して、OpenAMから送信されたログイン情報を代理認証に使うようにします。
第6回で使った config.json を元に内容を変更します。

変更のポイントは、CryptoHeaderFilterを使ってOpenAMから送信されたログインパスワードを復号化する箇所です。
keyの値には、第9回2-6 で取得した復号化キーをセットします。

{   
    "name": "CryptoHeaderFilter",
    "type": "CryptoHeaderFilter",
    "config": {
        "messageType":"REQUEST",
        "operation":"DECRYPT",
        "algorithm":"DES/ECB/NoPadding",
        "key":"xxxxxxxxxxxx",
        "keyType":"DES",
        "charSet":"utf-8",
        "headers": ["password"],
    }
},

また、LoginRequestFilterのクレデンシャル(ログイン情報)はヘッダーから取得するようになっています。

参考までに、OpenAM連携用のconfig.jsonを全文掲載しておきます。

{
    "heap": {
        "objects": [
            {
                "name": "HandlerServlet",
                "type": "HandlerServlet",
                "config": {
                    "handler": "DispatchHandler",
                    "baseURI": "http://192.168.0.10:80"
                }
            },
            {
                "name": "DispatchHandler",
                "type": "DispatchHandler",
                "config": {
                    "bindings": [
                        {
                            "condition": "${exchange.request.uri.path == '/sample/login.php'}",
                            "handler": "LoginChain",
                        },
                        {
                            "handler": "ClientHandler",
                        }
                    ]
                }
            },
		    {   
		        "name": "CryptoHeaderFilter",
		        "type": "CryptoHeaderFilter",
		        "config": {
		            "messageType":"REQUEST",
		            "operation":"DECRYPT",
		            "algorithm":"DES/ECB/NoPadding",
		            "key":"xxxxxxxxxxxx",
		            "keyType":"DES",
		            "charSet":"utf-8",
		            "headers": ["password"],
		         }
		    },
            {
                "name": "LoginChain",
                "type": "Chain",
                "config": {
                    "filters": ["CryptoHeaderFilter","LoginRequestFilter"],
                    "handler": "ClientHandler"
                }
            },
		    {   
		        "name": "LoginRequestFilter",
		        "type": "StaticRequestFilter",
		        "config": {
		            "method": "POST",
		            "uri": "http://192.168.0.10:80/sample/login.php",
		            "form": {
		                "userid": ["${exchange.request.headers['username'][0]}"],
		                "password": ["${exchange.request.headers['password'][0]}"],
						"action": ["login"]
		            }   
		        }   
		    },
            {
                "name": "ClientHandler",
                "type": "ClientHandler",
                "config": {
                }
            }
        ]
    },
    "servletObject": "HandlerServlet",
}

2. 連携動作の検証

連携動作を確認する前に、OpenIGが稼働するWebアプリケーションコンテナを再起動します。
再起動後、Webブラウザでターゲットアプリケーションを閲覧します。
※簡易認証アプリの場合、http://www.example.com:8080/sample/admin.php を開きます。

正常であれば、ターゲットアプリケーションからOpenAMのログイン画面にリダイレクトされます。
OpenAMのログイン画面で、登録済みのアカウントを使ってログインすると、ターゲットアプリケーションにログイン済みの状態でリダイレクトされます。

もしも正常に動作しない場合、いくつかの切り分けポイントがあります。

ターゲットアプリケーションからOpenAMにリダイレクトされない場合、エージェントをインストールする際の設定に誤りがあるかもしれません。
エージェントをインストールしたディレクトリ(Agent_000というディレクトリが生成されます)にログが出力されますので、参考になるかと思います。
エージェントのログにエラーがなければ、OpenAM側のエージェント設定が原因かもしれません。

OpenAMからターゲットアプリケーションにリダイレクトされない場合、OpenAM側かOpenIG側かの切り分けが必要です。
OpenAMが稼働するWebアプリケーションコンテナのログファイルを確認します。
また、OpenAM管理画面でのエージェント設定内容を再度見直してみましょう。

OpenAM側で問題がなさそうな場合、OpenIGのキャプチャーログ(第4回を参照)を取得して、アカウント情報が正常にPOSTされているかを確認します。

これでOpenIGとOpenAMの連携が確認できました。
実際の運用では複数アプリケーションに対して連携することで、シングルサインオン(SSO)が実現できます。

また、簡易認証アプリでは実装していませんが、ログアウト機能によってシングルサインアウトも可能となります。
複数のアプリケーションを使って、シングルサインオン、シングルサインアウトのテストもできると思います。

(ひとまず)終わりに

11回にわたってOpenIGの勉強をしてきましたが、いかがだったでしょうか。
少しでも、皆様の参考となっていれば幸いです。

ForgeRock社のドキュメントでは、どちらかというとエージェントの利用が推奨されているように書かれています。
エージェントはOpenAMで集中管理できますし、ターゲットアプリケーションと同一サーバ上で稼働することができます。
OpenIGは、ターゲットアプリケーションと(原則的には)別サーバですし、設定はローカル管理なので煩雑になるというデメリットがあります。
リバースプロキシですから、ボトルネックとなるリスクも伴います。

とはいえ、SAMLなどフェデレーション機能を持たない「レガシー」なアプリケーションがまだまだ存在する中で、OpenIGを導入するメリットはあると考えております。
代理認証はエージェントだけで実装することができませんので、OpenIG+エージェントの組み合わせをうまく活用して既存の「レガシー」アプリも含めた、シングルサインオン環境の構築にチャレンジしてみてはいかがでしょうか。

ForgeRock社のコミュニティでは非常に活発なやりとりが行われていますので、わからないことがあれば積極的に活用してみてください。


(参考サイト)

ForgeRock社のOpenIGドキュメントを参考にさせていただきました。

OpenIG自習室(第10回:OpenAM連携 Vol.3)

takaです。

前回はOpenIGとOpenAMを連携させるための設定を行いました。

今回はOpenIGとOpenAMを連携させるためのエージェントアプリケーションをインストールします。
エージェントアプリケーションのインストール先は、本来であればアクセス保護をかけるアプリケーション(WordPressや簡易認証アプリ)が稼働するサーバですが、OpenIGを使った代理認証を行う場合にはOpenIGが稼働するWebアプリケーションコンテナへインストールします。

検証作業は、以下の環境で実施しています。
(同一ハードウェア上で複数サーバを起動しています)

OS :Ubuntu 12.04 LTS
CPU:Intel Celeron 2.20GHz
MEM:2GB

検証サーバ: www.example.com (192.168.0.10)
アプリケーションサーバ(Apache2+PHP:ポート80)
OpenIGサーバ(Tomcat6:ポート8080)
OpenAMサーバ(Tomcat6:ポート18080)


1. エージェントのダウンロード

ForgeRock社のダウンロードページより、J2EE Policy Agentsの中のTomcat v6.0 & v7.0をダウンロードします。
2013年9月時点での最新安定バージョンは、3.1.0です。
(ダウンロードには、事前のユーザー登録が必要です)

2. パスワードファイルの作成

第9回1. エージェント設定 でエージェントの名前とパスワードを登録しました。
そこで登録したパスワードがエージェントインストールの際に必要となるのですが、外部テキストファイルを参照する仕様となっています。
インストーラが参照するためのパスワードファイルを事前に作成します。

# echo エージェントのパスワード > /tmp/pwd.txt
# chmod 400 /tmp/pwd.txt

3. エージェントのインストール

ダウンロードしたZIPファイルを展開してインストールします。

# unzip tomcat_v6_agent_3.1.0-Xpress.zip
# cd j2ee_agents/tomcat_v6_agent/
# ./bin/agentadmin --install

最初に利用規約への同意を求められます。
その後、いくつかの項目について入力します。
入力の際、第9回1. エージェント設定 で登録した内容が必要です。

Tomcat Server Config Directory       : Tomcatのconfディレクトリのパスを指定します(例)/usr/local/tomcat6/conf
OpsnSSO server URL                   : OpenAMのURLを指定します(例)http://www.example.com:18080/openam
$CATALINA_HOME environment variable  : CATALINA_HOMEのパスを指定します(例)/usr/local/tomcat6
Tomcat global web.xml filter install : "true" を入力(またはEnter)
Agent URL                            : エージェントのURLを指定します(例)http://www.example.com:8080/agentapp
Agent Profile name                   : エージェントの名前を指定します(例)SAMPLE
Agent Profile password file name     : パスワードファイルのパスを指定します(例)/tmp/pwd.txt

最後に 1 を入力(またはEnter)するとインストールが実行されます。

処理が終わった後、エージェントアプリケーションをWebアプリケーションコンテナにデプロイします。

# cp ./etc/agentapp.war $CATALINA_HOME/webapps/

これでエージェントのインストールは完了です。
次回は、OpenIGとOpenAM連携の動作検証を行います。


(参考サイト)

ForgeRock社のOpenIGドキュメントを参考にさせていただきました。