MOSA Multi-OS Software Artists

目次

• 「Wonderful Server Life」　　　　第93回　　　田畑 英和
• 小池邦人のCarbon視点でiPhone探求
• ターミナルの向こうから　　　　　　第48回　　海上 忍　

「Wonderful Server Life」　　第93回　　田畑 英和

〜「Deployment」編〜

　Mac OS XおよびMac OS X Serverのアップデートの最新版10.5.7がリリースされました。いつものように直前のバージョンからのデルタアップデートと、10.5.0からのコンボアップデートがそれぞれソフトウェア・アップデートで配布されています。

・Mac OS X 10.5.7 Updateについて
http://support.apple.com/kb/HT3397?viewlocale=ja_JP
・Mac OS X Server 10.5.7について
http://support.apple.com/kb/HT3398?viewlocale=ja_JP

　前回はNetBootのシステムイメージを作成するところまで解説しましたので、今回はその続きのNetBootサービスの設定について解説します。

◇関連サービス
　システムのイメージ作成が完了すれば、この後のサービスの設定はさほど難しくはありません。ほとんどデフォルトの設定だけでもNetBootを起動させることはできます。ただし注意が必要なのは、NetBootは他のサービスと連携して動作しますので、システム全体としての準備が適切に行われている必要があります。
　まずはNetBoot以外に必要となるサービスの確認をしておきましょう。まずDHCPが必要になります。これはNetBootクライアントがDHCPを使ってIPアドレスを取得するためです。ですので、NetBootが機能するにはDHCPによってIPアドレスが提供されている環境である必要があります。
　次にNetBootのシステムイメージを提供するために、NFSもしくはHTTPが必要になります。NFSのほうがパフォーマンスに優れていますので、通常はNFSを使用します。NFSですが、NFSの共有ポイントは自動的に作成され、サービスも自動的に開始します。
　あとはAFPが必要になる場合があります。これは設定によって状況が変わりますのでまた後ほど説明することにしましょう。というわけでNetBootを使用するには以下の関連するサービスが必要になります。

・NetBootで必要となる関連サービス
　　DHCP（必須）
　　NFS（またはHTTP）
　　AFP（必要に応じて）

◇NetBootサービスの設定
　さていよいよNetBootサービスの設定です。「サーバ管理」を使ってサーバに接続し、まずはNetBootサービスの「一般」の設定を行います。前回の設定ですでにイメージの保存場所は設定しました。あとはNetBootサービスを提供するポートの設定を行います。ここではEthernetを選択します。
　イメージの保存場所をすでに設定した方はもう気付いているかと思いますが、ポートをなにも選択しないでNetBootサービスを設定しようとすると警告が表示されます。デフォルトではなにもポートが選択されていませんので、ポートの設定を忘れないようにしましょう。

・ポートの設定
http://www.htabata.com/img/MXS105/netboot/nb_admin_01.png

　次に「イメージ」の設定です。「イメージ」の設定画面を表示すると「システムイメージユーティリティ」で作成したイメージがリストに表示されます。
1台のサーバで最大25個のイメージを管理できます。デフォルトで使用するイメージの「デフォルト」をチェックします。
　「ディスクレス」の設定がありますが、この設定はNetBootクライアントの挙動を理解しておく必要があります。NetBoot起動したクライアントはシステムを直接変更することはせず、なにかデータに変更があればシャドウファイルと呼ばれるファイルに保存します。イメージの設定でディスクレスを有効にした場合はこのシャドウファイルはサーバ上に保存されます。このときデータの転送にはAFPを使用しますので、ディスクレスでNetBootを運用する場合にはAFPサービスが必要になります。ディスクレスが無効な場合、シャドウファイルはクライアントのハードディスクに保存されます。

・イメージの設定
http://www.htabata.com/img/MXS105/netboot/nb_admin_02.png

　シャドウファイルですがクライアントを再起動するとその内容は破棄されます。ですのでNetBootでは再起動するたびにシステムが最初の状態に戻るようになっています。つまりシステムの内容を常に一定の状態に保つ事ができるわけです。
　イメージをNFSではなくHTTPで提供したい場合には「プトロコル」の設定を行います。

　特定のクライアントのみNetBootしたい場合は「フィルタ」の設定を行います。フィルタの設定ではMACアドレスを指定することにより、特定のクライアントのみにNetBootサービスを許可することができます。逆に特定のクライアントへのNetBootサービスの提供を拒否するように設定することもできます。
　フィルタはイメージごとに設定することもでき、この場合はMACアドレスだけではなく機種別のフィルタも設定することができます。例えばイメージが特定の機種に依存しているような場合は、そのイメージで起動可能なクライアントを制限することができます。

　以上がNetBootサービスの設定になります。あとはサービスを開始しどこにも問題がなければクライアントをNetBoot起動できるようになります。それでは次回はクライアントのNetBoot起動について解説します。
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　次回へつづく

小池邦人のCarbon視点でiPhone探求（2009/05/22）

〜　ウィンドウの代役を用意する　〜

さて、取り込んだ画像をファイルへ保存し、そのパス名をモデルオブジェクトへ登録する準備が整いました。今回からは、UIViewController上に配置したUITableViewにそうした画像を一覧表示させる処理へと話を進めたいと思います。

ところで、アプリケーションの起動時と終了時に処理すべき事項として「環境設定」の読み込みと保存があります。これについては、実際に何らかの環境設定用パラメータが必要となった時点で解説したいと考えています。iPhone OSには、アプリケーションの環境設定をiPhoneの「設定」アプリで管理する方法もあるのですが、本アプリケーションではそちらの手法は使わない予定です。
後は、加速度センサー（アクセロメータ）やCore Location（GPSによるデバイス位置の確認）のデリゲートメソッドの実装等もアプリケーション起動時に行うと良いのですが、こちらはiPhone 3.0で何か面白い動きがあるかもしれませんので、その正式登場まで待ちたいと思います（笑）。

iPhone用アプリケーションの開発には、AppKitをUIKitに差し替えたCocoa Frameworkを利用します。そこで採用されているGUI（グラフィカル・ユーザインターフェース）については、ビュー（UIView）やそのサブクラスであるコントロール（UIControl）を活用するなど、Mac OS Xのそれと多くの共通点がありますが、メニューが存在しないなど異なる点も幾つか見受けられます。ま
た、UIKitにはAppKitには存在しない固有なクラスもあり、その有効活用こそがiPhoneアプリケーションの出来映えを左右すると言っても過言ではありません。そのしたクラスの代表選手が、UIViewControllerを始めとするビューコントローラです。

UIViewControllerは、その名の通りUIViewのコントローラとして働くためにUIKitに追加されています。UIViewControllerはUIResponderクラスを継承しており、自身が管理しているUIView上で発生した「マルチタッチ・イベント」を受け取り処理することが可能です。iPhoneアプリケーションでは、ある目的を実現するための作業単位を、ひとつのビューコントローラに結びつけて設計す
るのが普通です。ちなみに、Mac OS Xのアプリケーションにおける作業単位は、間違いなくウィンドウ（ダイアログやフローティングウィンドウも含む）です。

アプリケーションの目的を達成するには、新規ウィンドウをオープンし、そこにフォーカスを当てることでユーザの作業を促します。また、ウィンドウには目的に応じた色々なビューやコントロールが配置されることになります。
iPhoneアプリケーションの場合には、AppKitのNSWindowとNSWindowControllerの組み合わせが、UIKitのUIViewとUIViewControllerに相当すると考えればよいでしょう。ちなみに、iPhoneでもウィンドウ（UIWndow）は存在しますが、
こちらはUIViewのサブクラスであり（Mac OS Xの場合と異なる）スクリーン上にひとつだけ配置されます。こうした唯一のウィンドウはmakeKeyWindowメソッドでキーウィンドウ（Mac OS Xだとフロントウィンドウ）に指定され、ユーザからのタッチイベントを受け付け始めます。

まあ、複数のウィンドウを用意してもかまいませんが、通常のiPhoneアプリケーションでは代わりに複数のビューコントローラを用意します。
UIViewControllerには、それ自身が管理するUIViewがひとつだけ付属しています。このUIViewがUIWindowのサブビューとなりスクリーン全面に表示されるわけです。つまり、ウィンドウを切り替えるのではなく、UIViewControllerとUIViewのペアを切り替えることにより、ユーザを目的の機能にフォーカスさせます。UIKitには、UIViewControllerのサブクラスとして機能が拡張された
「UITableViewController」「UINavigationController」「UITabBarController」の3つのビューコントローラが用意されています。

・UIViewControllerとUITableViewController

UIViewControllerは一般的に使われるビューコントローラです。Xcodeの「View-Based Application」テンプレート（雛形）でプロジェクトを作成すると、MainWindow.xibにUIViewControllerのサブクラスが登録され、その機能を実装するためのソースコードが用意されています。UIViewControllerで使われるUIViewは、別のnibファイルに保存されており、それがアプリケーション起
動時にスクリーン全体に表示されることになります。もう片方のUITableViewControllerは、リスト表示のためのUITableView（UIViewのサブクラス）をうまく管理できるよう機能拡張されています。

・UINavigationController

UINavigationControllerは、複数のビューコントローラを管理するためのスタックを保持しています。スタックに対しビューコントローラをプッシュやポップすることで、複数のUIViewControllerやUITableViewControllerを効率よく切り替えて使えます。Mac OS Xで言うなら、階層化されたウィンドウを目的に応じて切り替えながら作業を進めるタイプのアプリケーションと似ていま
す。

UINavigationController   |--- UITableViewController 
                        |--- UITableViewController
                        |--- UIViewController
                        |--- UIViewController

Xcodeの「Navigation-Based Application」テンプレートのMainWindow.xibには、ひとつのUINavigationControllerが登録されています。
UINavigationControllerの管理対象としてUIViewControllerのサブクラスであるRootViewControllerがひとつだけ用意されています。RootViewControllerはRootViewController.xibに用意されており、そのクラス自体はソースコードで実装されています。 ビューコントローラを追加することで、どんどん機能を拡張することが可能です。

・UITabBarController

UITabBarControllerを使うと、複数のUIViewControllerやUITableViewControllerを並列で管理できます。タブ切り替えで目的の機能を使えるようにするわけです。Mac OS Xであれば、NSTabViewで対象ビューを切り替えるのと似ていますが、それよりもどちらかと言えば、多数のウィンドウを作業毎に切り替えて使う感じに近いかもしれません。

UITabBarController   |--- UITableViewController 
                    |--- UIViewController
                    |--- UINavigationController  |--- UITableViewController
                                                 |--- UITableViewController
                                                 |--- UIViewController

Xcodeの「Tab Bar Application」テンプレートのMainWindow.xibには、タブ数が2に設定されたUITabBarControllerが登録されています。ひとつ目のタブをタップして表示される内容は、FirstViewControllerクラスとしてソースコードで実装されており、ふたつ目のタブで表示されるUIViewControllerの方は、SecondView.xibの方に用意されています。ユーザがタップ可能なタブ数を増や
していけば、さらに多くのビューコントローラを管理することが可能となります。

以前にも解説しましたが、Xcodeのプロジェクトをテンプレートから作る場合、適切なビューコントローラを活用するためには、目的に応じて「View-Based Application」か「Navigation-Based Application」か「Tab Bar Application」のどれかを選びます。どれを選択するかについては色々な要因があると思いますが、上記ビューコントローラの相関図を見ると、最も注目すべき要因はアプリケーションの規模（機能の複雑さ）なのかもしれません。

本アプリケーションは「Navigation-Based Application」テンプレートを使用しています。次回は、このテンプレートの内容を解説してから、UINavigationControllerが管理する（アプリでUIViewが最初に表示される）UITableViewControllerのサブクラス実装の話へと移りましょう。

ターミナルの向こうから　　　　　　第48回　　海上 忍

〜 リモートでシェルを使う（3） 〜

・SSHの「鍵ペア」とは

　SSHでは、あらかじめ「鍵ペア」を作成してサーバ／クライアント双方に登録しておくと、パスワードの入力を省くことができます。鍵ペアを登録しないかぎり、セッションの都度パスワードを入力しなければならないため、特にscpコマンドでファイルコピーを行う場合には作業が繁雑になります。
　鍵ペアは、「秘密鍵」と「公開鍵」の一対で構成されます。公開鍵はデータストリームを暗号化処理するときに利用され、その公開鍵と対をなす秘密鍵でのみ暗号を解く（復号化）ことができます。公開鍵は暗号化処理する目的のみ、秘密鍵は対をなす公開鍵で暗号化されたデータストリームを復号化する目的のみで利用されます。ペアで利用しないかぎり意味がない鍵、というわけです。
　この鍵ペアには、高度な暗号化処理が施されます。Leopard（Mac OS X 10.5.7）の場合、SSH2に対応したOpenSSH_5.1p1が収録されているので、暗号化形式としてRSAとDSAを選択できます。現在利用されているSSHのバージョンと暗号化形式の組み合わせは、SSH1とRSA、SSH2とDSA、SSH2とRSAの3通りが存在しますが、DSA鍵のほうがは署名を偽造しやすい（実際には気が遠くなるほどの計算量が必要なはずですが）といわれることから、ここではSSH2とRSAの組み合わせを前提に、解説を進めることにします。

・鍵ペアを作成する
　鍵ペアの作成には、「ssh-keygen」コマンドを実行します。RSA形式の鍵ペアを作成する場合、ターミナルから以下のとおりコマンドを実行します。なお、OpenSSH_5.1p1の初期値では、鍵の長さは2,048ビットに設定されています。

- - - - -
$ ssh-keygen -t rsa
- - - - -

　すると、鍵ペアを保存するディレクトリの確認が行われます。デフォルト（~/.ssh）で問題なければ、そのまま「enter」を押します。

- - - - -
Generating public/private rsa key pair.
Enter file in which to save the key (/Users/shinobu/.ssh/id_rsa):
- - - - -

　続いて、パスフレーズを入力します。パスフレーズにはスペースやタブを利用できるので、一般的なパスワードよりも長い、他人に知られる可能性は低いが意味のある（記憶に残りやすい）文を使うことが推奨されています。同じパスフレーズを2度入力すれば、秘密鍵（id_rsa）と公開鍵（id_rsa.pub）の2つのファイルが、ホームフォルダ直下の「.ssh」フォルダ（Finderには非表示）に作成されます。

- - - - -
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /Users/shinobu/.ssh/id_rsa.
Your public key has been saved in /Users/shinobu/.ssh/id_rsa.pub.
- - - - -

　このとき、フィンガープリントも表示されますが、とりあえずは必要ありません。コマンド「ssh-keygen -l」を実行して公開鍵の保存場所を示せば、後日確認することもできるため、メモを取らずに先へ進んでもかまいません。

・公開鍵をサーバへコピーする

　作成した鍵ペアのうち秘密鍵は手元のマシン（Mac）に、公開鍵はファイルコピーなどの方法で接続先（リモートサーバ）に転送して利用します。ここでは、仮にホームディレクトリにそのままのファイル名（id_rsa.pub）でコピーします。なお、入力するパスワードはサーバ側のもの（先ほどのパスフレーズは無関係）です。

- - - - -
$ scp ~/.ssh/id_rsa.pub yourname@dokka.com:~/
yourname@dokka.com's password:
- - - - -

　最後に、sshでサーバへログインし、コピーした公開鍵を所定のディレクトリへコピーしたあと、以下のコマンドラインを実行して適切なファイルパーミッションを設定します。これで一般的なUNIX系OSならば作業は完了ですが、Mac OS X Leopardの場合には、もうひと手間が必要です。

- - - - -
$ ssh yourname@dokka.com
Password:
yourname@dokka:~> mkdir .ssh
yourname@dokka:~> chmod 700 .ssh
yourname@dokka:~> cat id_rsa.pub >> .ssh/authorized_keys
yourname@dokka:~> cat id_rsa.pub >> .ssh/authorized_keys2
yourname@dokka:~> chmod 600 .ssh/*
- - - - -

・最後におまじない

　Mac OS Xに収録のOpenSSHには、キーチェーンと連動するための機能が追加されています。通常は、前述の作業だけでパスワードなしにSSHを利用できるようになりますが、Leopardは以下のコマンドを実行しないかぎり、キーチェーンへの登録をうながすダイアログが表示され続けます。コマンド実行後、「ssh yourname@servername」とコマンドを実行してパスワードを求められなければ、すべての作業は完了です。同様に、scpコマンドがパスワードなしで通ることも確認しておきましょう。

- - - - -
$ ssh-add -K
Enter passphrase for /Users/shinobu/.ssh/id_rsa:
Passphrase stored in keychain: /Users/shinobu/.ssh/id_rsa
Identity added: /Users/shinobu/.ssh/id_rsa (/Users/shinobu/.ssh/id_rsa)
- - - - -

◇MOSAからのお知らせと編集後記は割愛します◇