Solaris のシステム管理 (印刷)

付録 A インターネット印刷プロトコルの使用

この付録には、Oracle Solaris OS でインターネット印刷プロトコル (IPP) を使用するための情報が含まれています。IPP は、CUPS と Windows クライアントの相互運用性を提供します。Oracle Solaris OS では、IPP の PAPI 実装によって、サーバー側とクライアント側の両方の印刷サポートが提供されます。

この付録の内容は次のとおりです。

Open Printing の詳細については、http://sf.net/projects/openprinting を参照してください。

Oracle Solaris の IPP サポートの概要

IPP は、インターネットのツールやテクノロジの使用を通して分散印刷のために使用できる、アプリケーションレベルのネットワーク印刷プロトコルです。このプロトコルは、インターネットから文書を印刷するための汎用のソリューションを提供するために開始されました。IPP には、広範囲の標準的な要求を発行したり、印刷クライアントシステムから標準的な応答を受信したりするために必要なツールが含まれているため、このプロトコルはいくつかのシステムベンダーやプリンタベンダーによって使用されています。IPP では、バージョン管理、拡張性、セキュリティーのほか、ジョブやプリンタの状態を取得する場合の機能強化を含む拡張された機能が提供されます。

Oracle Solaris リリースでの IPP サポートは、クライアント側のサポートとサーバー側のサポートで構成されています。クライアント側のサポートとサーバー側のサポートはどちらも、いくつかの共通要素や、クライアントまたはサーバーのどちらかの操作に固有の要素を共有しています。IPP のクライアントとサーバーのサポートは、これらの共通コンポーネントの一部が実装されたベースコードを共有しています。IPP に対するサーバー側のサポートは、Solaris 10 3/05 リリースから使用可能です。クライアント側のサポートは、Solaris 10 5/08 リリースで導入されました。

次に、IPP を使用して行える作業を示します。

IPP には、実際の使用環境での印刷ソリューションのさまざまな側面を抽象化する、印刷のための簡略化されたモデルが含まれています。このモデルでは、オブジェクト、属性、およびこれらのオブジェクトに対して実行される操作のセットを使用します。IPP では、これらの抽象化を使用して、印刷サービスコンシューマ (つまり、顧客) と印刷サービスプロバイダの間で、詳細で、標準的な、セキュリティー保護された、さらには拡張可能な方法で情報を通信します。

IPP 待機サービスの概要

IPP 待機サービス (「リスナー」とも呼ばれる) は、印刷クライアントシステムにリスナーを実行しているシステム上の印刷サービスと対話するための手段を与える IPP ネットワークプロトコルサービスを提供します。このリスナーは、標準的な操作および属性のセットを含むサーバー側の IPP サポートを実装しています。リスナーは、Oracle Solaris 上に Apache モジュールとして、および IPP 操作とワイヤ通信をサポートする一連の共用ライブラリとして実装されます。IPP ソフトウェアスタックは、システムに Oracle Solaris OS をインストールしたときにインストールされます。IPP 待機サービスは、実行を印刷サービスに依存する SMF サービスです。その結果、最初の印刷待ち行列が追加されると、印刷サーバー上で IPP が自動的に有効化されます。また、最後の印刷待ち行列が削除されると、IPP は無効化されます。

フロントエンドでは、IPP サーバーのサポートは HTTP バージョン 1.1 の階層の上に置かれています。サーバーは、HTTP POST 要求を通して IPP 操作を受信します。サーバーは次に、要求された操作を実行し、HTTP を介してクライアントに応答を返します。これらの操作には、印刷ジョブの送信および取り消しや、プリンタ、印刷ジョブ、またはプリンタの待ち行列に入れられているすべての印刷ジョブの属性のクエリーなどが含まれますが、これらには限定されません。バックエンドでは、IPP リスナーは印刷スプーラと通信することによって操作を実行します。Oracle Solaris OS では、このスプーラは現在、lpsched デーモンです。

IPP 待機サービスの動作

IPP 待機サービスの実装 (サーバー側のサポート) は、Apache Web サーバーの下に組み込まれています。Web サーバーは、HTTP POST 要求によって IPP 操作を受信します。この HTTP POST 要求は、受信されたあと、Apache IPP モジュール (mod_ipp.so) に渡されます。Apache Web サービスはまた、設定に基づいて、認証サービスを提供したり、印刷クライアントと印刷サーバーの間の暗号化のために使用したりすることもできます。待機サービスは、待機専用の Apache インスタンスとして実行されます。

このプロセスは次のとおりです。

  1. クライアントからサーバーに対して IPP 要求が発行されます。

  2. Apache Web サーバーが接続を受け付けます。

  3. Apache Web サーバーは次に、その接続を mod_ipp に渡します。

  4. mod_ipp は、その接続と設定データを libipp-listener に渡します。

  5. libipp-listener は、lipipp-core を使用して要求を読み取ります。

  6. libipp-listener は、その要求を lipipp-listener にある操作ハンドラに振り分けます。

  7. 操作ハンドラは、その要求を PAPI 呼び出しに変換してから呼び出しを実行します。

  8. この PAPI 呼び出しは、psm-lpsched を使用して印刷サービス固有の要求に変換されます。

  9. 印刷サービスが要求に応答します。

  10. psm-lpsched コマンドは、その応答を PAPI 結果に変換します。

  11. libpapi 操作により、libipp-listener 操作ハンドラに戻ります。

  12. libipp-listener 操作ハンドラは、結果をディスパッチャーに渡します。

  13. libipp-listener ディスパッチャーは、libipp-core ライブラリを使用して結果をクライアントに書き込みます。

  14. このディスパッチャーは戻り値として、mod_ipp のエントリポイントを戻します。

IPP コンポーネント

次の表は、Oracle Solaris OS での IPP サポートを構成しているコンポーネントを示しています。

表 A–1 IPP コンポーネント

コンポーネント 

機能 

httpd

Apache Web サーバー。tcp/631 の IANA 登録済み IPP ポート上で HTTP 要求を待機できる HTTP トランスポートリスナーを提供します。要求が受信されると、IPP Apache モジュールに渡されます。 

mod_ipp.so

Apache IPP モジュール。この Apache モジュールは、クライアントの HTTP 要求を調べて、その要求が IPP 要求 (application/ipp と HTTP POST 操作の MIME タイプ) であるかどうかを判断します。IPP 要求であると判断されると、IPP リスナーライブラリに渡されます。また、このモジュールは、IPP 固有の Apache 設定指令も導入して処理します。

libipp-listener.so

IPP リスナーライブラリ。このライブラリは、コア IPP マーシャリングライブラリを使用して IPP 要求をデコードし、それを IPP 操作実装機能のいずれかに振り分けます。これらの機能は、ローカル印刷サービスと対話するために IPP 要求を PAPI 呼び出しに変換します。呼び出しが終了すると、リスナーライブラリは結果をエンコードして、要求しているクライアントに戻します。 

libipp-core.so

IPP マーシャリングライブラリは、ワイヤ上での送受信のために IPP バイトストリームをデコードおよびエンコードします。 

libpapi.so

PAPI ライブラリは、IPP 待機サービスなどのアプリケーションに印刷サービスと対話するための手段を提供します。 

IPP ライブラリ

IPP 待機サービスライブラリ (libipp-listener) – 一連のプロトコル要求処理が発生する場所です。このライブラリは、コア IPP ライブラリ libipp-core.so を使用して要求の読み取りと検証を行います。要求が検証されると、その要求は一連のクライアント API 呼び出しに変換されます。次に、これらの呼び出しの結果が、コア IPP ライブラリを使用して適切な IPP 応答に変換されます。この応答は、Web サーバーによってクライアントシステムに返されます。待機サービスライブラリへのインタフェースは、IPP サーバー側の実装に固有のプロジェクト非公開インタフェースです。

IPP コアライブラリ (libipp-core.so) – クライアントとサーバーの操作の間で共有されます。IPP コアライブラリには、プロトコル要求および応答の読み取りと書き込みを可能にするルーチンが含まれています。このライブラリは、IPP 要求および応答データを、標準のバイナリ表現と共通データ構造のセットの間で変換します。最終的には、この共通データ表現が、要求を印刷サービスに依存しない表現との間で変換するために使用され、汎用印刷インタフェース libpapi.so 間で渡されます。この機能は、クライアント側とサーバー側の両方の IPP サポートが実行する必要があるため、クライアントとサーバーで共有されます。

PAPI ライブラリ (libpapi.so) – アプリケーションに、印刷サービスまたはプロトコルと対話するための印刷サービスに依存しない手段を提供します。この場合は、Apache IPP 待機サービスに、ローカル LP サービスと対話するための手段を提供します。このライブラリは、対話する相手の印刷サービスを、printers.conf 構成データベースに格納されているクライアント側の待ち行列設定データに基づいて決定します。

IPP サポートモデル

以降の節では、IPP サポートモデルのさまざまな側面について説明します。

IPP オブジェクトモデル

IPP には、プリンタとジョブという 2 つの基本的なオブジェクトタイプ が含まれています。各オブジェクトタイプには、実際のプリンタまたは実際の印刷ジョブの特性が含まれています。各オブジェクトタイプは、その特定のオブジェクトタイプでサポートできる、可能性のある属性のセットとして定義されます。

すべてのプリンタオブジェクトおよびジョブオブジェクトをあいまいなところがなく参照できるようにするために、これらのオブジェクトはすべて URI (Uniform Resource Identifier) で識別されます。識別子としての URI の概念と実装は、印刷サービス (IPP) と通信するための方法と、プリンタ待ち行列 (//server/printers/queue) またはジョブの個別のネットワーク識別子の両方を一意に識別するための手段が提供されるため、非常に有効です。

印刷要求が作成されたとき、生成される IPP プロトコルメッセージには、操作の実行対象となるプリンタオブジェクトの printer-uri が含まれている必要があります。printer-uri の取り得る値は、プリンタオブジェクトまたはネームサービスの printer-uri-supported 属性から取得できます。

IPP プリンタオブジェクト

プリンタオブジェクトは、IPP モデル内のメインのオブジェクトです。プリンタオブジェクトは、IPP に対するサーバー側のサポートを提供します。プリンタオブジェクトには、通常は物理的な出力デバイスに関連付けられた機能が含まれています。これらの機能には、印刷サーバーに関連付けられた複数のデバイスのスプール処理、スケジューリング、変換、および管理が含まれます。プリンタオブジェクトは、printer-uri によって一意に識別されます。プリンタオブジェクトは、名前、コンテキスト、プリンタの機能などのプリンタオブジェクトに関する静的な情報を検索する目的のために、ディレクトリ内のエントリとして登録できます。プリンタの待ち行列に入れられているジョブの数、エラー、警告などの動的な情報は、プリンタオブジェクト自体に関連付けられています。


注 –

デバイスのセマンティクスがプリンタオブジェクトのセマンティクスと整合性があるかぎり、プリンタオブジェクトを使用して実際のデバイスまたは仮想デバイスを表すことができます。


ユーザー、またはユーザーの代わりに実行されているプログラムが、印刷ジョブの送信や管理のためにプリンタオブジェクトにクエリーを実行する機能を持っている場合、IPP クライアントはプロトコルをクライアント側に実装します。IPP サーバーはプリンタオブジェクトの一部であり、印刷サービスのアプリケーションセマンティクスを実装します。プリンタオブジェクトは、出力デバイスに組み込むことも、または出力デバイスと通信するネットワークホスト上に実装することもできます。

ジョブがプリンタオブジェクトに送信されると、プリンタオブジェクトは要求内の属性を検証してから、ジョブオブジェクトを作成します。ジョブ状態のクエリーを実行したり、ジョブの進捗を監視したりする場合は、ジョブオブジェクトと対話します。印刷ジョブを取り消す場合は、ジョブオブジェクトのジョブ取り消し操作を使用します。ジョブオブジェクトの操作の詳細については、「IPP 操作キーワード」を参照してください。

IPP ジョブオブジェクト

ジョブオブジェクトは、印刷ジョブをモデル化するために使用されます。ジョブオブジェクトには文書が含まれています。ジョブオブジェクトを作成するために必要な情報は、IPP クライアントを通してプリンタオブジェクトへの印刷要求を開始したときに、作成要求の形式で印刷サーバーに送信されます。この作成要求はプリンタオブジェクトによって検証され、受け付けられた場合は、プリンタオブジェクトによって新しいジョブオブジェクトが作成されます。このオブジェクトは、printer-uri 属性と job-id 属性の組み合わせ、または job-uri 属性によって一意に識別されます。詳細は、「IPP 操作キーワード」を参照してください。

IPP サーバー側のサポート

IPP 待機サービスは IPP ネットワークプロトコルサービスを提供して、リスナーを実行しているシステム上の印刷サービスと対話する手段を印刷クライアントシステムに提供します。このリスナーは、標準的な操作および属性の幅広いセットを含むサーバー側の IPP プロトコルサポートを実装しています。このリスナーは、Oracle Solaris では Apache モジュールとして、および IPP 操作とワイヤサポートが含まれた一連の共用ライブラリとして実装されています。IPP ソフトウェアスタックは、システムに Oracle Solaris OS をインストールしたときにインストールされます。IPP 待機サービスは、実行を印刷サービスに依存する SMF サービスです。その結果、最初の印刷待ち行列が追加されると、印刷サーバー上で IPP が自動的に有効化されます。IPP は、最後の印刷待ち行列が削除されると無効になります。

IPP に対するサーバー側のサポートは、IPP モジュール mod_ipp で始まります。Oracle Solaris OS には Apache ソフトウェアが付属しているため、待機サービスは Apache Web サーバーを使用しています。Apache モジュールは、DSO (Dynamic Shared Object) インタフェースを使用して Web サーバーの下にプラグインします。DSO インタフェースを使用することにより、このモジュールには IPP 待機サービスのための構成サポート、および Web サーバーがリスナーに HTTP 接続を渡すためのエントリポイントが含まれています。このモジュール化されたアプローチによって、Apache で提供される暗号化や認証機構の IPP サポートでの再利用が可能になります。

図 A–1 IPP サーバー構成

IPP サーバー構成を構成しているコンポーネントの図まわりのテキストにさらに詳細な説明が含まれています。

IPP サーバー側のデータの設定

IPP 待機サービスの構成ファイル /etc/apache/httpd-standalone-ipp.conf は、通常の Apache 1.3 構成ファイルと似ています。構成ファイルは、使用する任意の Apache 1.3 設定指令を取り込みます。

デフォルト設定には次に示す機能が含まれています。

/printers/ で実行可能なデフォルト操作は、セキュリティーリスクが低い操作セットに限定されています。ただし、/admin/path (ipp://server/admin/) では、基本認証を必要とすることなく、すべての操作を有効にすることができます。

選択できる mod_ipp Apache 設定オプションを次の表に示します。

表 A–2 mod_ipp Apache モジュール設定オプション:

備考欄

ipp-conformance

プロトコルチェックのレベルを選択します。デフォルトは automatic であり、これによってクライアントとの対話が最大になります。

ipp-operation

1 つ以上の IPP 操作に対して IPP 操作サポートを選択的に有効または無効にすることができます。 

ipp-default-user

ローカル印刷サービスに接続するときに使用するユーザー名を選択します。デフォルトは lp 印刷ユーザーであり、これによってさらに多くの機能プロキシが可能になります。

ip-default-service

要求を送信する先のデフォルトの印刷サービスを選択します。デフォルトは lpsched デーモンであり、現在は lpsched に対するテストのみが行われています。

次の表は、Apache Web サーバー設定に対する適合性確認タイプを示しています。使用する構文は次のとおりです。


ipp-conformance value
表 A–3 Apache Web サーバーの適合性確認タイプ

意味

自動 

要求された操作がプロトコルリスナーでサポートされていることだけを確認します。(デフォルト) 

1.0 

要求が IPP/1.0 に準拠していることを確認します。 

1.1 

要求が IPP/1.1 に準拠していることを確認します。 

apache 設定ファイルのコメント付きの例を次に示します。

if mod_ipp is loaded User lp run as "lp"
URI: ipp://{host]/printers/{queue}
SetHandler application/ipp use mod_ipp for this location
ipp-conformance strict enable strict protocol checking (default)
ipp-operation all enable enable all supported operations

IPP 操作キーワード

IPP オブジェクトは操作をサポートしています。操作は、要求と応答で構成されています。印刷クライアントが IPP オブジェクトと通信する場合、クライアントはそのオブジェクトの URI に操作要求を発行します。操作要求と応答には、その操作を識別するパラメータが含まれています。また、操作には、その操作の実行時の特性に影響を与える属性も含まれています。これらの操作固有の属性は、操作属性として定義されます。印刷要求には、操作属性、オブジェクト属性、および特定の操作を実行するために必要な文書データが含まれています。各要求には、オブジェクトからの応答が必要です。各応答は、操作の成功または失敗を、応答パラメータとしての対応する状態コードとともに示しています。応答には、操作属性、オブジェクト属性、および操作要求中に生成された状態メッセージが含まれています。

次の表は、Apache Web サーバー設定の IPP 操作キーワードを示しています。

表 A–4 IPP 操作キーワード

意味

All

このキーワードは、操作の代わりに使用されます。このキーワードは、mod_ipp でサポートされるすべての操作が選択されていることを示すことを目的にしています。

Required

このキーワードは、操作の代わりに使用されます。このキーワードは、次の操作を含む、RFC-2911 で定義された必要なすべての操作が選択されていることを示すことを目的にしています。 print-jobcancel-jobget-job-attributesget-jobs、および get-printer-attributes

Print-job

クライアントが 1 つの文書だけを含む印刷ジョブを送信しようとしています。文書データは、要求とともに送信されます。 

Print-uri

サポートされていません。 

Validate-job

クライアントが、印刷ジョブを送信する前に、スケジューラで印刷ジョブを処理できることを検証しようとしています。 

Create-job

クライアントが複数の文書を含む印刷ジョブを送信しようとしています。文書は、send-document および send-uri 操作とともに送信されます。

Send-document

クライアントが、print-job 操作で作成された印刷ジョブに文書を追加しようとしています。文書データは、要求とともに送信されます。

Send-uri

サポートされていません。 

Cancel-job

クライアントが印刷ジョブを取り消そうとしています。 

Get-job-attributes

クライアントが印刷ジョブに関する情報を収集しようとしています。 

Get-jobs

クライアントが特定の印刷待ち行列内の印刷ジョブのリストを収集しようとしています。 

Get-printer-attributes

クライアントが特定の印刷待ち行列に関する情報を収集しようとしています。 

Hold-job

クライアントが特定の印刷ジョブを保持しようとしています。 

Release-job

クライアントが特定の印刷ジョブを解放しようとしています。 

Restart-job

クライアントが特定の印刷を再開しようとしています。 

Pause-printer

クライアントが特定の印刷待ち行列を一時停止 (無効に) しようとしています。この操作によって、待ち行列内の印刷要求の処理が停止されます。この操作を行なっても、待ち行列でのジョブの受け付けは停止されません。 

Resume-printer

クライアントが特定の印刷待ち行列内のジョブの処理を再開 (有効に) しようとしています。 

Purge-jobs

クライアントが特定の印刷待ち行列からすべてのジョブを削除しようとしています。 

Set-printer-attributes

プリンタの属性を作成または変更します。 

Set-job-attributes

既存の印刷ジョブの属性を変更します。 

Enable-printer

印刷ジョブのキューイングを再開、または受け付けます。 

Disable-printer

印刷ジョブのキューイングを無効にする、または拒否します。 

cups-get-default

印刷サービスのデフォルトの出力先を取得します。 

cups-get-printers

印刷サービスから使用可能なすべてのプリンタを列挙します。 

cups-get-classes

印刷サービスから使用可能なすべてのクラスを列挙します。 

cups-accept-jobs

CUPS 固有の Enable-printer と同等の操作。 

cups-reject-jobs

CUPS 固有の Disable-printer と同等の操作。 

cups-move-jobs

同じ印刷サービス内の待ち行列間でジョブを移動します。 

IPP クライアント側のサポート

Oracle Solaris での IPP クライアント側のサポートは、PAPI の下に実装されます。このサポートによって、PAPI を使用している任意のアプリケーションが IPP だけでなく、その他の印刷サービスやプロトコルを使用できるようになります。

アプリケーションには、次のものが含まれます。

アプリケーションに対する IPP クライアント側のサポートは、操作対象のプリンタまたはジョブの printer-uri に基づいて実行時にロードされる、ロード可能なモジュール psm-ipp.so を通して提供されます。

IPP は HTTP トランスポートの階層の上に置かれているため、クライアント側とサーバー側のどちらのサポートにも、HTTP プロトコルの読み取りと書き込みの機能が必要です。サーバー側では、このサポートは Apache Web サーバーによって提供されます。クライアント側では、このサポートは HTTP ライブラリ libhttp-core.so によって提供されます。

lpsched のサポート

psm-lpsched は、PAPI の印刷サービスに依存しない表現と、LP 印刷スプーラ (lpsched) の間の変換を提供します。さまざまな PAPI 機能に渡された PAPI 属性を受け付け、それをデータの内部の lpsched 表現に変換します。次に、lpsched に接続して、要求された操作を実行します。実行が完了すると、結果を元の印刷サービスに依存しない PAPI 表現に変換して、呼び出し元に返します。

LP 印刷スプーラ (lpsched) は、スプール処理サービス、ジョブデータのプリンタですぐに使用できる形式への変換、およびジョブデータの物理的なプリンタへの送信を提供します。

IPP 属性

オブジェクトインスタンスごとに、そのオブジェクトの特定の実装を記述した、サポートされている属性および値のセットが存在します。

オブジェクトの属性および値には、そのオブジェクトに関する次の情報が含まれます。

オブジェクトを定義する各属性は、1 つのセットに含まれています。特定のオブジェクトのこの属性セットには、そのオブジェクトが潜在的にサポートするすべての属性が含まれています。REQUIRED というラベルの付いた属性の場合は、各オブジェクトがその属性をサポートする必要があります。属性に OPTIONAL というラベルが付いている場合、各オブジェクトはその属性をサポートしている可能性があります。

プリンタの属性は、次の 2 つのグループに分けられます。

job-template

これらの属性は、サポートされているジョブ処理機能と、プリンタオブジェクトのデフォルト値を記述します。

printer-description

これらの属性には、ID、状態、場所、およびプリンタオブジェクトに関するその他の情報源への参照が含まれます。

プリンタオブジェクトをサポートする設定の例には、次のものがあります。

また、ジョブオブジェクトの特性は、その属性によっても記述されます。

ジョブの属性は、次の 2 つのグループにグループ化されます。

これらの属性の一部は印刷クライアントによって指定され、その他の属性はプリンタオブジェクトによって生成されます。実装は、ジョブオブジェクトあたり複数の文書をサポートできますが、少なくともジョブオブジェクトあたり 1 つの文書をサポートする必要があります。


注 –

IPP バージョン 1.0 およびバージョン 1.1 では、文書が IPP オブジェクトとしてモデル化されません。そのため、文書にはオブジェクト識別子や関連付けられた属性がありません。すべてのジョブ処理指示がジョブオブジェクト属性としてモデル化されます。これらの属性は、ジョブテンプレート属性と呼ばれます。これらの属性は、ジョブオブジェクト内のすべての文書に均一に適用されます。


IPP オブジェクトには、オブジェクト属性の持続的記憶領域とともに永続的に保持される関係があります。

作業関連の情報については、「インターネット印刷プロトコルの構成」を参照してください。