バージョン共通
CentOS等、yumコマンドによりインストールした環境では以下のコマンドで簡単に最新版にアップデートできます。
$ sudo yum update （もしくはsudo yum update shibboleth）
アップデート後、httpdおよびshibdが再起動されていることを確認し、再起動されていなければ手動で再起動してください。
$ sudo /sbin/service shibd restart $ sudo /sbin/service httpd restart
SP 2.4.x から SP 2.5.0 およびそれ以降へアップデートする場合の注意点
0. 事前準備
rpmパッケージで導入されている方は shibd という非rootユーザが新たに作られその権限で起動するようになるため、昔の学認の技術ガイドに沿って設定している場合に2点問題が生じます。技術ガイドは2011年11月に修正済みです。それ以前にSPを構築された方は以下の設定を確認してください。
まず、server.key のパーミッションの問題です。rootにしか読み取り権限を与えていない場合、2.5をインストールした時点で自動再起動がかかるため、shibdがエラーで停止してしまいます。
回避方法はいくつかありますが、下記のように sp-key.pem をシンボリックリンクにしておくと、2.5インストール時に自動的に server.key のownerが修正されます。
$ sudo mv -i /etc/shibboleth/sp-key.pem{,.dist} && sudo ln -s cert/server.key /etc/shibboleth/sp-key.pem
この回避策は当該秘密鍵がSPのみで使用されている場合で、slapdなど他のプロセスからも参照されている場合は注意が必要です。
具体的に言うと、アップデート前の時点で秘密鍵ファイルのowner/グループがroot:rootでない場合が該当します。上述のようにシンボリックリンクを作成すると、2.5へのアップデートによってこれがshibd:shibdに強制変更されます。ACLを含めたパーミッションは変更されないようですので、setfacl等でACLを設定しておけば回避できます。
2点目の問題は、メタデータのバックアップファイルを置くディレクトリのパーミッションです。/etc/shibboleth/metadata/ にバックアップを置くように設定されている場合、このディレクトリはshibdユーザの権限ではファイルが置けません。この場合以下のようなエラーがログに記録されます。（リモートのメタデータにアクセスできている限りにおいてSP停止などの実害はありません）
2011-10-17 18:30:07 DEBUG OpenSAML.MetadataProvider.XML [GakuNinMetadata]: committing backup file to permanent location (/etc/shibboleth/metadata/federation-metadata.xml) 2011-10-17 18:30:07 CRIT OpenSAML.MetadataProvider.XML [GakuNinMetadata]: unable to rename metadata backup file
回避方法は、shibboleth2.xmlで
backingFilePath="/etc/shibboleth/metadata/federation-metadata.xml"
のように絶対パスで指定している部分を
backingFilePath="federation-metadata.xml"
のように相対パスに変更します。このように変更しておけば、適切にownerが設定されるディレクトリ /var/cache/shibboleth/ を使うようになります。
1. SPアップデート後
事前準備の後始末
執筆中
shibd.conf
/etc/httpd/conf.d/shib.conf を修正して使っていた方は、shib.conf.rpmnew というファイルが新たに作成されていると思います。
2. その他の情報（*はセキュリティフィックス）:
- 2.5.0
- 2.5.1(*)
以前の情報
SPアップデート手順（*はセキュリティフィックス）
- 2.4.0 情報交換ML:00300 情報交換ML:00302 情報交換ML:00306
- 2.4.1 情報交換ML:00316
- 2.4.3(*) 情報交換ML:00356 情報交換ML:00367 情報交換ML:00460