月別アーカイブ: 2014年4月

VMware vSphereにおけるFreeBSDのP2V(dump/restoreを使う方法)

前回紹介したFreeBSDのP2V方法は、手順はそれなりに簡単ですが、イメージの取得と貼り付けにddを使うため、パーティションの切り直しなどが不可能で、シンプロビジョニングも活用できないという欠点がありました。

これを解決する方法として、dump/restoreを用いてP2Vを行う方法があります。

手順概要

基本的な手順は前回と同じため、手順が重なる部分は省略して解説します。おおまかな前提は次のとおりです。

  • FreeBSDの物理サーバからvSphere上の仮想ゲストマシンにP2Vを行う
  • それぞれのマシンは直接通信できるネットワーク上にない(直接通信できる場合は、この手順より少し楽ができる)が、双方に対してsshでアクセスできる、物理サーバのディスクイメージを格納できる十分なディスクを持ったマシン(以後、仲介マシン)がある
  • 物理サーバには起動用のCD-ROMなどは必要ない
  • ディスクやパーティションのサイズを変更できる
  • シンプロビジョニングが活用できる

前回と異なる部分は後半3項目です。

ddの代わりにdump/restoreを用いるわけですが、FreeBSDのdumpはUFS2のスナップショット機能を利用してくれるので、DBサーバやWebサーバなど、テンポラリな不整合を発生しがちなプログラムさえ止めておけば、物理サーバを起動した状態で十分健全なdumpを取得できます(もちろん、Live CDブートして作業を行えばより安全です)。

また、dumpしたパーティションと異なるサイズにrestoreできるため、リッチに使っていた物理マシンのディスクを、必要最小限的に領域を確保した仮想マシンに縮めることが可能です。

さらに、restoreの書き込みはイメージ書き込みとは異なるため、シンプロビジョニングも活かすことが可能です。

いいことばかりのように思えますが、手順は幾分複雑になります。

  1. 物理サーバを掃除して、仮想マシンに必要なパーティションサイズ計画を検討する
  2. 物理サーバからssh経由のdumpで仲介マシン上に各パーティションのバックアップを取得
  3. 仮想ゲストマシンでP2Vしたい対象と同じFreeBSDのバージョンを、計画したパーティションサイズで最小インストールする
  4. 仮想ゲストマシンをLive CDで起動し、インストールしたファイルをすべて消す
  5. 仲介マシンから仮想ゲストマシンにdumpイメージをssh経由でrestoreする
  6. 仮想ゲストマシンに対応する設定を修正する
  7. VMware Toolsをインストールする

続きを読む

VMware vSphereにおけるFreeBSDのP2V(ddを使う方法)

VMware vCenter Converterを利用すれば、物理サーバを仮想化するいわゆるP2Vは比較的簡単に行うことができますが、対応しているOSは限られています。具体的には次のようなOSです。

  • Windows XP Professional SP3 (32-bit and 64-bit)
  • Windows Server 2003 SP2, R2 (32-bit and 64-bit)
  • Windows Vista SP2 (32-bit and 64-bit)
  • Windows Server 2008 SP2 (32-bit and 64-bit)
  • Windows Server 2008 R2 (64-bit)
  • Windows 7 (32-bit and 64-bit)
  • Red Hat Enterprise Linux 2.x (32-bit and 64-bit)
  • Red Hat Enterprise Linux 3.x (32-bit and 64-bit)
  • Red Hat Enterprise Linux 4.x (32-bit and 64-bit)
  • Red Hat Enterprise Linux 5.x (32-bit and 64-bit)
  • SUSE Linux Enterprise Server 8.x (32-bit and 64-bit)
  • SUSE Linux Enterprise Server 9.x (32-bit and 64-bit)
  • SUSE Linux Enterprise Server 10.x (32-bit and 64-bit)
  • SUSE Linux Enterprise Server 11.x (32-bit and 64-bit)
  • Ubuntu 8.x (32-bit and 64-bit)
  • Ubuntu 9.x (32-bit and 64-bit)
  • Ubuntu 10.x (32-bit and 64-bit)

要するにWindowsとLinuxの一部以外無理ということですね。まあ上記以外にももちろんCentOSとかはOKのようですが。

そうは言ってもFreeBSDのサーバとかも入れたい場合があるのです。特にもう再構築するのが果てしなく面倒くさいくらい作りこんだサーバなどが典型例でしょうか。というわけで、FreeBSDのサーバをP2Vする方法をまとめてみましょう。今回はddを使う方法です。

手順概要

今回の作業手順の前提は次のようなものです。なお、最後の2項目であるディスク・パーティションサイズの変更やシンプロビジョニングへの対応に関しては、もう少し面倒な別の方法を後日紹介します

  • FreeBSDの物理サーバからvSphere上の仮想ゲストマシンにP2Vを行う
  • それぞれのマシンは直接通信できるネットワーク上にない(直接通信できる場合は、この手順より少し楽ができる)が、双方に対してsshでアクセスできる、物理サーバのディスクイメージを格納できる十分なディスクを持ったマシン(以後、仲介マシン)がある
  • 物理サーバには起動できるCD-ROMが付いている
  • ディスクやパーティションのサイズは変更しない
  • シックプロビジョニングになる(シンプロビジョニングにしても意味がない)

なお、仲介マシン上に置かれるディスクイメージはセキュリティ上重要な情報を含むため、容易に外からアクセスされるマシンや、持ち出されることのあるノートPCなどは適しません。ファイルを削除した後もデータは残るので、特に重要なデータの場合は、消去後に空き領域を/dev/randomで埋めるなど、データを慎重に消してください。仮想システム上に使い捨ての仲介マシンを構築するのが一番お勧めです。普段利用されているマシンを使う場合は、別途安全な場所に保管や、ランダム書き込み初期化、廃棄処分が可能な外付けUSBディスクなどを使うのも良い手でしょう。

続きを読む

プロビジョニングの道具としてのOpenLDAP back-sql

OpenLDAPのバックエンドのおすすめはBDBなのですが、多くの場所から認証データを収集し、適切な形に編集してLDAP形式で公開する、いわばアカウント・プロビジョニング的な用途には、SQLのバックエンド機能(back-sql)も魅力的に見えます。

巨大なデータをトランザクションで全件更新しつつ、パスワードの更新は可能な限りリアルタイムで別テーブルに収集し、より新しいパスワードをクライアントに渡す…ような仕組みは、(単なるイメージなのかもしれませんが)やはりSQL系のデータベースに一日の長があるのではないかと考えます。

そんな魅力的に見えるOpenLDAPのback-sqlですが、実際に試してみると次のような欠点があります。

  • パフォーマンスが悪い
  • 設定が複雑すぎてわけがわからない

まずは性能面です。小規模なデータの場合はそれほどでもないのですが、大規模なデータを食わせると途端に悲惨な性能になってしまいます。実際に数万件のデータを食わせたところ、1秒に5件ほどしか検索ができないという悲惨な状況になりました。これではいくらなんでも実用的ではありません。

設定が複雑なのは、LDAPのスキーマを、SQLのスキーマとデータ(メタデータと呼ぶ)の双方を使って表現するからです。テーブル構造は難しくありませんが、メタデータの方はたしかに難解です。その分、さまざまなカスタマイズも可能と言えますが、そのメリットがあるかどうかはケースによりますが微妙でしょう。

これら2つの論点について、軽く解説します。なお、ここで用いたバックエンドのSQLデータベースはPostgreSQLです。

OpenLDAP back-sqlの性能問題

大規模なデータを入れると悲惨な性能になると評判のback-sqlですが、実はサンプルなどを見てスキーマをこさえて、何も考えずに大量のデータを入れると性能が悪化するのは当たり前で、PostgreSQL用のサンプルもMySQL用のサンプルも、インデックスの定義が含まれていません。

続きを読む

Shibbolethで複数のIDを同一人物としてログインさせる

(こちらの内容は、学認メーリングリストで国立情報学研究所の西村様、京都大学の針木様から頂いたアドバイスの内容を含んでいます)

Shibbolethにおいては、認証システムにおける「ユーザ名」に相当する概念が、uid(ログイン名)、ePPN(フェデレーション内で一意なユーザ名)、ePTID(IdP:SPのペアで一意なユーザ名)の3つがあります。

この仕組を利用して、他のID体系からShibbolethにユーザアカウントのプロビジョニングを行うにあたって、学内に複数のID体系が存在して、同一ユーザが複数のIDを持っている場合に、次のようなID管理を実現可能です。

  • ユーザはどのID体系でもIdPにログインできる
  • ログイン後は、どのID体系でログインしてもSPからは同一人物として見える

複数uidで同一ePPNのLDAPを用意する

まず、パスワードはuidに紐付いています。LDAP上にuidの異なる複数のエントリを設けることで、その双方でログインすることは可能となります。Shibbolethのuidはフリーフォーマットですので、「@ドメイン名」などのスコープを付けた形でuidを定義するなどの方法で、複数ID体系の衝突を防ぐことは可能でしょう。

そして、ePPNは一番広いアカウント体系のuidを採用するか、Trusted DBにあるユーザ識別可能な何らかの属性から生成して、LDAP上で同一人物は同一のePPNを持つようにすることで、ePPNを要求するSPからはどのuidでログインしても同一人物に見えるようにすることができます。

ePTIDは基本的にePPNとSPのentityIDから生成されるようにすれば、これもSPから見ればどのuidでログインしても同一人物に見えるようにすることができます。

これだけ読むと、LDAP上のデータを適切に用意することだけで実現できそうに思えるのですが、それほど簡単な話ではありません。

ePPNとePTIDをLDAPのePPN値ソースに変更する

まず、学認の標準テンプレートのattribute-resolver.xmlでは、ePPNをLDAPのePPNのエントリではなく、uidを流用するようになっています(2行目のsourceAttributeID=”uid”の部分)。

続きを読む

Shibboleth SPで学認独自属性にアクセスする

(2014年9月1日 追記) NIIの西村様から情報をいただき、これらの属性にアクセスするためのattribute-map.xmlは、https://meatwiki.nii.ac.jp/confluence/pages/viewpage.action?pageId=12158127#id-%E6%8A%80%E8%A1%93%E3%82%AC%E3%82%A4%E3%83%89-%E3%83%86%E3%83%B3%E3%83%97%E3%83%AC%E3%83%BC%E3%83%88 から取得できるということを教えていただきました。どうもありがとうございます。なお、以下の記事の内容は、そのまま掲載しておきます。

OSにShibboleth-SPをインストールした状態で、主なShibbolethの属性はアプリケーションから環境変数経由で読み出せるのですが、学認独自の属性に関しては、標準状態では読みだすことができません。

独自属性には、日本語の組織名(jaOrganizationName, jaOrganizationalUnitName)、氏名(jaSurName, jaGivenName, jaDisplayName)等の日本語データや、身分や学籍番号などを表すgakuninScopedPersonalUniqueCode等があります。

これらの属性にアクセスするには、Shibboleth SPの設定ファイルattribute-map.xmlの <Attribute>…</Attribute>内に、次のように追記することで実現可能です(環境変数経由でアクセスするときのパラメータ名は適当に短縮しています)。

なお、このファイル中にはたとえば

のように、OIDではなくパラメータの名前で定義されている行もありますが、これはShibboleth 1.3対応のものなので、Shibboleth2系でアプリケーションを構築するのであれば必要ありません。

OIDに関しては、学認サイトの属性リストページで調べられますので、上記に挙げられていないパラメータにアクセスしたい場合は、ここからOIDを調べてください。

学認用Shibbolethリバースプロキシの構築

学認で利用されている認証ソフトウェアであるShibbolethは、SP部分はC++で記述されているため、SPの動作にJava VMの必要などもなく、既存のシステムへの組み込みも比較的容易です(IdPはJava VMやtomcatが必須です)。一方で様々な理由で、認証リバースプロキシがあると、内製ではないWebアプリの対応が楽になる場合があります。

そのため、Shibbolethの認証リバースプロキシを構築してみました。作業環境にはFreeBSDを用いましたが、CentOS等の場合でもそれほど違いはないと思います。

まずは、shibboleth-spをインストールします。FreeBSDの場合、標準だとapache22がprefork MPMでインストールされてしまい、メモリを無駄遣いするので、このあたりの手順でworker MPM版をインストールするのがお勧めです。

そして、ApacheのSSLを適切に設定し、SPとしての設定も行います。リバースプロキシを使って実現するようなサービスはたいてい学内サービスでしょうから、学認のSPとしてグローバルに登録しない、ローカル的なSPとしての構築をしたい場合はこの辺りの手順を参考にしてください。

そして、ApacheのSSL設定部分(FreeBSDならば/usr/local/etc/apache22/extra/httpd-ssl.conf、CentOSならば/etc/httpd/conf.d/ssl.confあたり)の<VirtualHost _default_:443>…</VirtualHost>の中で、次のような設定を行います。ここで、プロキシ先は平文で、http://192.168.1.2/を仮定します。

この例では、ePPNとeduPersonAffiliationを属性として受け取り、Affiliationが教員か学生の場合のみにプロキシにアクセスを許可ています。そして背後のサーバに、HTTPのパラメータとしてX-Shib-EppnにePPNを、X-Shib-AffiliationにeduPersonAffiliationを渡しています。

続きを読む

学認のIdPを用いた学内サービス用SPを構築する

学認のIdPを構築することで、学認で利用可能な外部のSPを利用可能となりますし、学認の多くのユーザに使ってもらうSPを構築することも可能です。一方で、作成したいSPの中には、外部のユーザに公開することが適切ではないサービスもあります。

そのようなサービスでは単に外部のユーザには使用できないだけではなく、学認の公式メタデータにもリストアップされず、認証に用いるIdPの選択画面なども表示されないようにする必要があります。

学認公式サイトの技術ガイドではこの辺りの手順がよくわからないので、以下にまとめてみます。

IdP側の設定

まずは、SPのメタデータを生成します。学認申請システム(運用フェデレーション用テストフェデレーション用は別です)にログインし、「新規SP申請」から「SPメタデータ情報」のところに必要なデータを入力し、そこにある「以下の内容でエンティティメタデータをテスト生成」をクリックすることでメタデータを生成できます。

この際、XMLファイル冒頭の<EntityDescriptor>のID属性は、適当に修正しましょう(他と同じでも特に問題はなさそうですが)。

これを適当なファイル名で、IdPの/opt/shibboleth-idp/metadata/に置きます(ここでは仮にtestsp.xmlというファイル名を仮定します)。そして、IdPのrelying-party.xmlの、/rp:RelyingPartyGroup/metadata:MetadataProviderの中にある

の前か後に、次のようにしてローカルメタデータへの参照を追加します。ここでも、id属性は適当に設定してください。複数のSPを登録したければこれを並べていけば問題ありません。

続きを読む

FreeBSDで作る学認用Shibboleth SP

学認などで利用されているShibboleth SPをFreeBSD上に構築してみました。環境としてはFreeBSD 10.0-RELEASEです。作業は非常に簡単です。

OSをインストールし終わったら、次のようにしてShibboleth SPをインストールします。

ただし、shibboleth-spのportはapache22に依存しているのですが、標準のapache22はprefork MPMのためにメモリを大量に消費します。できればこういうアプリのパッケージはapacheに依存性を付けないでもらえると嬉しいのですが、mod_shib22.soを入れる必要があるので必要なんでしょうね。

とりあえず、apache22を強制再インストールで問題はなさそうです。

ただし、/usr/local/etc/apache2/httpd.confのCGIモジュールの部分だけは、

から、

に修正しないと、worker MPMのApacheは起動しません。ちなみに、shibbolethのモジュールが

で正常に組み込まれていることも確認して下さい。もし入っていなければLoadModuleの行の最後にでも追加しましょう。

続きを読む

学認FPSP(Filter Per SP)の改良

(この内容は、学認メーリングリストで、オープンソース・ソリューション・テクノロジの相本様、辻口様からいただいたアドバイスやパッチを含んだ内容となっています)

学認FPSPとは

学認は認証インフラとしてShibbolethを利用しているのですが、Shibbolethは認証と認可をIdPとSPとに完全に分離しているため、属性によってユーザが利用できないSPを利用しようとすると、次のような行動パターンになってしまいます。

  1. SPのサイトで自IdPを選択
  2. IdPでユーザ名とパスワードを入力してログイン
  3. SPのサイトに戻ってそこで利用を断られる

認証と認可の分離という観点から言えばこれは正しいといえるのですが、通常の1サイトで完結したアプリケーションの利用者にとっては今ひとつわかりにくいのも事実です。

また、本来であればSP側でユーザ属性に基づいて認可を行ってほしいのに、ユーザ属性が何であっても受け入れてしまうSPもあります(なおかつ、そのまま利用するとソフトウェアライセンス違反になってしまうものもあります)。

このような問題を解決するには、IdP側である程度の認可情報を管理し、SPに移動する前に制御を行いたいと思うのですが、そのような目的に利用できるものとしてFPSP(Filter Per SP)というツールが提供されています。

FPSPの問題点

ところが実際のところ、このFPSPを利用してみると色々と問題があります。バグといえる問題点としては、

  • 一旦FPSPでログインを拒絶されると、その後シングルサインオン自体が無効となり、他のSPにもログインできなくなる(ブラウザを終了させるか、タイムアウトを待たないと他のSPが利用できない)
  • 実は、FPSPに設定されたサイトにアクセスしてIdPを選択すると、そこでログインしなくても他のSPにログインできなくなる

仕様上の問題といえる点としては、

  • SPが要求しない属性でフィルタできないため、先程述べたような、SPが必要な属性を要求せずに認めてしまっているサイトへの移動をフィルタできない

が挙げられます。

続きを読む

FreeBSD 10.0にWordPressをインストール

このサイトを立ち上げるにあたって、FreeBSD 10.0にWordPressをインストールしたメモです。FreeBSD 10からはpkgngがデフォルトのパッケージ管理システムになっているので、これを用いてインストールすることになりますが、色々問題があり、試行錯誤が必要でした。

普通に考えれば、

でインストールできるんじゃないか、と思うのですが、この状態だと次のような問題があります。

  • ja-wordpressの依存性でphp5がインストールされるが、このphp5にはmod_phpは入っていない
  • apache22のMPMがpreforkなので、mod_phpとか組み込んで色々やった日にはメモリをバカ食いする
  • apache22のMPMをworkerにするには、php5をスレッドセーフにしなければならないが、標準ではそうなっていない

そのようなわけで、結局次のような方法を取ることにしました。まずは上記の理想例同様に、ja-wordpressとmysql56-server、apache22-worker-mpmをインストールします。

そして、ja-wordpressとphp5関係をすべて削除します。

続きを読む