[upki-fed:00755] Re: uApproveの挙動について

[Takeshi NISHIMURA <xxxxxxx@xxxxxxxxx>]

坂元様、みなさま
西村です。
坂元様、前メールでお名前を間違っており大変申し訳ございませんでした。

uApprove.jpとMySQL 5.5の問題について、5.5にてデフォルトのストレージ
エンジンが変更になった影響ではないかと考えております。(MyISAM→InnoDB)

MySQL 5.5にてuApprove.jpをインストールされる方は、テーブル作成後に
以下のコマンドを実行してストレージエンジンをMyISAMに変更してください。

ALTER TABLE ArpUser ENGINE=MyISAM;
ALTER TABLE ShibProvider ENGINE=MyISAM;
ALTER TABLE AttrReleaseApproval ENGINE=MyISAM;
ALTER TABLE ProviderAccess ENGINE=MyISAM;
ALTER TABLE CheckAlways ENGINE=MyISAM;

なお、先のメールにも書きましたように元々MySQL 5.0でインストールしたもの
をMySQL 5.5に移行した場合、ストレージエンジンはMyISAMのまま変更され
ないため、上記のコマンドは必要なく、件の問題も発生しません。

PS
なお、後日公開予定の2.2.1cについては以下の2つのテーブルが追加されて
おりますので、同様に変更が必要になります。
ALTER TABLE BackChannelAccess ENGINE=MyISAM;
ALTER TABLE NamesOfApprovedService ENGINE=MyISAM;


2014/01/10 16:48、Takeshi NISHIMURA <xxxxxxx@xxxxxxxxx> のメール：

> 坂本様、みなさま
> NIIの西村です。
> 
> 検証に時間がかかっており申し訳ございません。
> CentOS 5にて、MySQL 5.0で使っていたDBを移行したMySQL 5.5環境では
> 正常動作していたものの、
> MySQL 5.5環境で1から作り直したDBにて問題が再現されました。
> 
> 引き続き調査します。
> 
> (2013/12/19 1:51), Takeshi NISHIMURA wrote:
>> 坂元様
>> 西村です。
>> 
>> ご報告ありがとうございます。
>> 私の知る限りMySQL 5.5での動作実績はないと思いますので、こちらでも
>> 試してみようと思います。
>> 
>> 2013/12/17 18:14、Hideki SAKAMOTO <xxxxxxx@xxxxxxxx> のメール：
>> 
>>> TSNRの坂元です。
>>> 
>>> やや後ろ向きながら解決いたしましたので報告します。
>>> 
>>> 結論から申しますと、MySQL 5.5ではuApprove.jpがうまく動かないということの
>>> ようでした。
>>> 
>>> その後、環境の方も疑ってCentOS 5.10とOracleのjdk-6u33という組み合わせで
>>> 試したのですが、やはり駄目でした。そこで、CentOSの環境でMySQLを5.0.95に
>>> バージョンダウンした所、同じ設定で不具合がすべて解消されて正常に動くよう
>>> になりました。また、MySQL 5.1.70でも正常に動き、さらにIdPを2.4.0に上げて
>>> も大丈夫なようでした。ちなみに、PostgreSQL(9.2)でも試してみましたが、次の
>>> 例外が必ず発生して、こちらは動きませんでした。
>>> -----
>>> java.lang.NullPointerException
>>>        at ch.SWITCH.aai.uApprove.storage.LogInfoJdbc.getData(LogInfoJdbc.java:741)
>>>        at ch.SWITCH.aai.uApprove.viewer.Controller.doPost(Controller.java:211)
>>> -----
>>> 
>>> MySQLの5.0はすでにEoLを迎えており、5.1も今月いっぱいでEoLになるようです
>>> ので微妙なところではあるのですが、当面はそれで凌ごうと思います。もし関
>>> 係者の方が見ておられましたら、MySQL 5.5以降でも動くようにしていただけ
>>> ますと有り難いです。
>>> 
>>> よろしくお願いいたします。
>>> 
>>> P.S.
>>> PostgreSQL用にSQLコマンドを調整していて気づいたのですが、mysql.commandsの
>>> 45行目の
>>>  date_format(araTimeStamp,'%Y-%m-%d %H:%i%s')
>>> という箇所は、
>>>  date_format(araTimeStamp,'%Y-%m-%d %H:%i:%s')
>>> の間違いではないでしょうか？影響としてはログに記録されるタイムスタンプの
>>> フォーマットがおかしくなるぐらいで、クリティカルな部分では無いようですが。
>>> 
>>> 
>>> (2013/12/16 18:40), Hideki SAKAMOTO wrote:
>>>> 土屋先生
>>>> 
>>>> TSNRの坂元です。コメントありがとうございます。おかげさまで進展が
>>>> ありました。
>>>> 
>>>> 今回やった事で効果があったと思われる作業をまとめますと、以下の通りです。
>>>> ・ArpUserテーブルからauUserNameが重複しているもので、他のテーブルに紐付け
>>>>  されているデータがないレコードを削除
>>>> ・ArpUserテーブルのauUserNameにUNIQUE属性付加
>>>> ・MySQLのJDBCドライバを5.1.27にアップデート
>>>> 
>>>> 現状でまだ残っている問題は、以下の通りです。
>>>> ・選択した属性情報提供の設定が次回以降ログイン時に無視されることがある
>>>> ・[新] 属性情報提供のリセット機能の挙動不審
>>>> 
>>>> 以下、詳細となります。
>>>> 
>>>>> 症状からすると，uApprove が確認結果などを格納するデータベースがうまく参照
>>>>> できていない可能性が疑わしいように思います．
>>>>> 
>>>>> common.properties の storageType と databaseConfig の設定，および
>>>>> storagetType=database の場合は database.properties の設定を確認されてはど
>>>>> うでしょうか．
>>>> 
>>>> はい、データベースはMySQLを使っており、common.propertiesは、
>>>> -----
>>>>  storageType=database
>>>>  databaseConfig=/usr/local/uApprove/conf/database.properties
>>>> -----
>>>> /usr/local/uApprove/conf/database.propertiesは、
>>>> -----
>>>>  sqlCommands=/usr/local/uApprove/conf/mysql.commands
>>>>  driver=com.mysql.jdbc.Driver
>>>>  url=jdbc:mysql://localhost:3306/uApprove
>>>>  user=uApprove
>>>>  password=**********
>>>> -----
>>>> となっており、作成したテーブルにはそれらしいエントリが登録されている所まで
>>>> は確認しておりました。
>>>> 
>>>> ところが、ArpUserテーブルをよくよく確認すると、auUserNameが重複したレコード
>>>> が複数登録されており、そのうちの1つだけに、AttrReleaseApprovalテーブルや
>>>> CheckAlwaysテーブル上に対応するレコードがある状態でした。そこで他のテーブル
>>>> に対応するレコードの無いArpUserテーブル上のレコードを削除した所、
>>>>>> ・同意画面や送信属性の確認画面で無限ループする
>>>>>> （確認画面で送信を押すと同意画面に戻ってしまう）
>>>> と
>>>>>> ・Internal Server Errorとなる
>>>> の２つの現象はいまのところ発生しなくなりました。mysql.commandsを見ますと
>>>> -----
>>>> selIdxUser = select idxArpUser as idxUser from ArpUser where auUserName = '?'
>>>> -----
>>>> となっておりますので、重複登録によりauUserNameからidxArpUserを取得する
>>>> 段階で値が不定になってしまっていたようです。これで一時しのぎはできまし
>>>> たが、そもそもの重複登録をどうにかしないといけないので、とりあえず
>>>>  ALTER TABLE ArpUser ADD UNIQUE (auUserName);
>>>> と、auUserNameをユニーク化してDB側でエラーになるようにして試した所、
>>>> ArpUserテーブルに既にレコードのあるアカウントでは特に問題ないのです
>>>> が、初めてログインする際に重複登録しようとしているようでした。こちら
>>>> は予想される処理の流れからしてDB処理が怪しいと踏んで、JDBCのドライ
>>>> バを5.1.27にバージョンアップしたところ、いまのところ症状は出ず、
>>>> auUserNameにユニーク属性を付けたままでも動くようになりました。
>>>> 
>>>> ここまででだいぶまともに動くようになってきたものの、
>>>>>> ・最初に「毎回確認する」とした設定が無視されて確認の無いままSPに
>>>>>> 飛んでしまう（あるいは逆に確認画面が表示されてしまう）
>>>> という現象はいまだ発生しています。
>>>> またIdPの認証画面で"Reset my attribute release approvals"チェック
>>>> ボックスを表示して設定を変更しようとすると、SPに飛ぶ前に属性の選択画
>>>> 面が２回表示されたり、ブラウザを再起動して再びログインしようとすると、
>>>> 変更した設定が反映されていなかったりといった現象も出ています。皆様の
>>>> IdPではこのリセット機能も問題なく動いていますでしょうか？
>>>> 
>>>> 引き続きなにかお気づきの点がありましたらコメントいただけますと幸いです。
>>>> 
>>>> よろしくお願いいたします。
>>>> 
>>>> (2013/12/16 12:33), TSUCHIYA Masatoshi wrote:
>>>>>>> On Fri, 13 Dec 2013 20:15:07 +0900
>>>>>>> xxxxxxx@xxxxxxxx (Hideki SAKAMOTO) said as follows:
>>>>> 
>>>>>> 現在uApprove.jp(2.2.1b)の動作確認をしており、基本的には動いたのですが、
>>>>>> テストを繰り返していると、
>>>>>> ・同意画面や送信属性の確認画面で無限ループする
>>>>>> （確認画面で送信を押すと同意画面に戻ってしまう）
>>>>>> ・最初に「毎回確認する」とした設定が無視されて確認の無いままSPに
>>>>>> 飛んでしまう（あるいは逆に確認画面が表示されてしまう）
>>>>>> ・Internal Server Errorとなる
>>>>>> 等の現象が発生してかなり不安定な状況です。Internal Server Errorが
>>>>>> 発生した際のTomcatのログを末尾に付けます。
>>>>> 
>>>>> 症状からすると，uApprove が確認結果などを格納するデータベースがうまく参照
>>>>> できていない可能性が疑わしいように思います．
>>>>> 
>>>>> common.properties の storageType と databaseConfig の設定，および
>>>>> storagetType=database の場合は database.properties の設定を確認されてはど
>>>>> うでしょうか．

-- 
西村健
国立情報学研究所 TEL:03-4212-2890