ルータ : Cisco Application Extension Platform

Cisco Application eXtension Platform Developer ガイド

Cisco Application eXtension Platform Developer ガイド
発行日;2012/01/21 | 英語版ドキュメント(2010/10/12 版) | ドキュメントご利用ガイド | ダウンロード ; この章pdf | フィードバック

目次

Cisco Application eXtension Platform Developer ガイド

目次

Cisco Application eXtension Platform の概要

Cisco AXP の機能

ホスティング インフラストラクチャ

仮想化

Cisco AXP における仮想化の利点

仮想インスタンス

専用のアプリケーション リソース

CPU リソース

メモリ リソース

アプリケーションのパッケージ化

Cisco AXP の証明書

ゲスト OS 上でのアプリケーションの実行

アプリケーションの起動

アプリケーションのコンソール アクセス権の取得

アプリケーション ステータス

アプリケーション ステータスの監視

CLI サービス API

ロギング サポート

SNMP

インフラストラクチャ アドオン パッケージ

OSGi

Tomcat

アプリケーション SSH

アプリケーション開発パッケージ

CLI プラグイン ディストリビューション サービス

Cisco IOS サービス API

Embedded Event Manager API

リモート シリアル デバイス

Perl

開発システムの要件

前提条件

開発フロー

Cisco AXP SDK

パッケージ化およびバンドリング用のツール

Library Dependency Checker

Package Information

RPM ファイルの抽出

CLI プラグイン ユーティリティ ツールおよび API

付加価値サービス API

SDK のインストール

アプリケーションの開発

アプリケーションの作成

自動または手動によるアプリケーションの起動

自動起動

手動起動

アプリケーションのパッケージ化

共通ルート ディレクトリの作成

ファイルのコピー

保護ファイルのファイル作成

証明書の作成

プロジェクト用パッケージ ディレクトリの作成

パッケージ ツールの実行

Hello World アプリケーションのパッケージ化:例

アプリケーションのインストール、アンインストール、およびアップグレード

アプリケーションのインストール

インストール コマンド

アプリケーションのアンインストール

アプリケーションのアップグレード

アプリケーションのインストールおよび動作の確認

CLI プラグイン アプリケーション

CLI プラグイン ディストリビューション サービス

CLI プラグイン アプリケーションのコンポーネント

CLI プラグイン アプリケーションのパッケージ化

CLI プラグイン アプリケーションのインストール

CLI プラグイン アプリケーションのアクティベーション

XML DTD ファイル

DTD の概要

CLI DTD

XML DTD 定義

type regex

CLI プラグインの呼び出し

CLI プラグイン アクション API

no

CLI プラグイン ディストリビューション リスナー API

CLI プラグイン エラー

アクション呼び出しの割り込み

CLI プラグインの同時呼び出し

CLI プラグインのプレパッケージ

CLI プラグイン アプリケーション:例

ヘルス ステータス

パッケージ名

show time アプリケーション:例

トラブルシューティングおよびロギング

アプリケーションのトラブルシューティング

デバッグ手順

vi エディタのトラブルシューティング

ロギング

ログ ファイルの循環

ログ レベル

ロギングの使用

Syslog サーバでのロギング

C:Syslog サーバ

Java:Syslog サーバ

バンドリングおよびパッケージ化

バンドリング

Cisco AXP ホスト OS を含むバンドリング

Cisco AXP ホスト OS を含まないバンドリング

パッケージ ツール

パッケージ ツール コマンド:例

バンドリング ツール

バンドリング ツール:例

パケット分析

RITE トラフィック フィルタリングおよびサンプリング

RITE の設定

パケット モニタリングおよび分析

混合モード Packet API

デバッグ ツール

SSH トンネリング

SSH トンネリングの例

rsync

システム ライブラリのアップデート

GDB のデバッグ

GetRouterIP API:例

net-snmp:例

リモート シリアル デバイス:例

RPM File Extractor ツール

RPM File Extractor ツールの実行

RPM File Extractor ツールの引数

RPM のトラブルシューティング

付録 A:Fedora Core 6 からのアプリケーションのポーティング:例

セットアップ

例 1:簡易な C++ アプリケーション

例 2:既存アプリケーションのポーティング

Cisco AXP パッケージ コンテンツの特定

ライブラリ

アプリケーションでのライブラリのバンドリング

バンドルするライブラリの特定

libc ファイル

ライブラリの検索および LD_LIBRARY_PATH

付録 B:ゲスト OS のコマンド

付録 C:ゲスト OS のライブラリ

通告

OpenSSL/Open SSL Project

License Issues

Cisco Application eXtension Platform Developer ガイド

 

【注意】シスコ製品をご使用になる前に、安全上の注意
www.cisco.com/jp/go/safety_warning/ )をご確認ください。
 
本書は、米国シスコシステムズ発行ドキュメントの参考和訳です。
米国サイト掲載ドキュメントとの差異が生じる場合があるため、正式な内容については米国サイトのドキュメントを参照ください。
また、契約等の記述については、弊社販売パートナー、または、弊社担当者にご確認ください。

4/14/08, OL-14813-01-J

このマニュアルでは、Cisco Application eXtension Platform(Cisco AXP)上でアプリケーションを作成する方法、パッケージ化する方法、インストールする方法について説明します。

目次

このマニュアルの内容は、次のとおりです。

「Cisco Application eXtension Platform の概要」

「Cisco AXP の機能」

「開発システムの要件」

「前提条件」

「開発フロー」

「Cisco AXP SDK」

「アプリケーションの開発」

「アプリケーションのインストール、アンインストール、およびアップグレード」

「CLI プラグイン アプリケーション」

「トラブルシューティングおよびロギング」

「バンドリングおよびパッケージ化」

「パケット分析」

「デバッグ ツール」

「例」

「RPM File Extractor ツール」

「付録 A:Fedora Core 6 からのアプリケーションのポーティング:例」

「付録 B:ゲスト OS のコマンド」

「付録 C:ゲスト OS のライブラリ」

「通告」

次のトピックの詳細については、『 Cisco AXP User Guide 』を参照してください。

Cisco AXP ハードウェア要件

Cisco IOS イメージ要件

Cisco AXP イメージのアップデート

Cisco AXP Application Service Module の設定

アプリケーション環境の設定

Cisco Application eXtension Platform の概要

Cisco Integrated Services Router(Cisco ISR; Cisco サービス統合型ルータ)は、単一シャーシ内に統合されたシステムです。Cisco ISR は、音声、レイヤ 2 スイッチング、セキュリティ、アプリケーション アクセラレーションなど、複数の付加価値サービスを結合して実行します。さらに、ルータの Cisco IOS ソフトウェア内部で統合サービスをホスティングできます。またはサービスをデカップリングして、モジュラ 型のアプリケーション サービス モジュール上でホスティングできます。

Cisco ISR では、ブレード ハードウェア プラグイン モジュールを使用できます。これらのアプリケーション サービス モジュールは、ルータの機能、インテリジェンス、および柔軟性を向上させます。Cisco AXP は、この機能セットの次世代に相当します。

Cisco AXP を使用すると、システム インテグレータ、管理対象のサービス プロバイダー、大企業カスタマーなどのサードパーティは、独自の付加価値統合サービスを提供することによって、Cisco ISR の機能を拡張できます。サービス モジュール上で、Cisco AXP は専用リソースを使用して独立したランタイム環境でアプリケーションをホスティングします。さらに、Cisco AXP はパケット分析、イベント通知、ネットワーク管理などの機能をホステッド アプリケーションで使用できるように、Application Programming Interfaces (API; アプリケーション プログラミング インターフェイス)を提供します。

Cisco AXP には、アプリケーションをホスティングするファシリティおよびフレームワーク、アプリケーションをネットワークに統合するためのサービス API があります。Cisco AXP が提供する機能は、次のとおりです。

予測可能な固定のアプリケーション リソース セット。

これらのリソース(CPU、メモリ、ディスク、ネットワーク入出力を含む)はセグメント化されます。したがって、アプリケーションおよびルータ機能がそれぞれ独立して動作し、干渉を受けることがありません。

不正アプリケーションからのルータおよびアプリケーションの保護。

アプリケーションがクラッシュしても、他のアプリケーションは影響を受けません。ルータも引き続き、正常に動作します。これは、インストールしたアプリケーションをそれぞれ専用の仮想インスタンスに配置することによって実現します。

次のプログラミング言語で作成されたアプリケーションを実行できる、組み込み Linux 環境。Java、C(ネイティブ)、Perl(解釈型)、Python(解釈型)、および Bash(解釈型)です。

その他のプログラミング言語で作成されたネイティブおよび解釈型アプリケーションは、サードパーティのアプリケーションで追加のサポート ライブラリおよびインタープリタを使用する場合に、サードパーティによる統合が可能です。

不正ソフトウェアの実行に対する保護。

Cisco AXP にソフトウェアをインストールできるのは、シスコが認定したサードパーティだけです。

強化デバッグおよびトラブルシューティング ファシリティ。

Cisco IOS コンフィギュレーションを変更し、用意された API を使用して Cisco IOS 機能のステータスを取得する能力。

イベント通知のサポート。

アプリケーションは Cisco ISR のステータスを得て、適切な処理を実行できます。

仮想デバイスの統合。

Cisco IOS 補助シリアル ポートを仮想化し、Cisco AXP OS でローカル デバイスとして表示できます。アプリケーションはルータの補助シリアル ポートに接続された外部周辺装置を制御します。デバイスの位置を特に認識する必要はありません。

ファイアウォール サポート。

Cisco AXP ネットワーク インターフェイスは、セキュリティを確保するためにファイアウォールによって保護されます。ポートを開くには「CLI サービス API」を使用します。

図1 に、Cisco ISR における Application Service Module のアプリケーションと Cisco IOS 間の関係を示します。

図1 Cisco ISR と Cisco AXP Service Module インターフェイス

 

Cisco AXP の機能

Cisco AXP は、ほとんどのアプリケーション開発者が精通している Linux ベースのホスティング インフラストラクチャを提供します。Linux ベースにすることによって、オープン ソースのソフトウェアを開発用に使用できます。ホスティング インフラストラクチャでは、Linux-VServer テクノロジーに基づいて、別々のセキュリティ コンテキストにアプリケーションをインストールして実行します。これらのセキュリティ コンテキストは必ず、共通の Linux カーネルを使用しますが、独立した専用リソースが与えられます。ライブラリは、各セキュリティ コンテキスト内で独立させることができます。ネットワーク インフラストラクチャは、シスコ認定パートナーが開発したソフトウェアだけをサービス モジュールにインストールして実行できるようにするので、セキュリティが強化されます。

Cisco AXP の主要な機能は、次のとおりです。

「ホスティング インフラストラクチャ」

「仮想化」

「専用のアプリケーション リソース」

「アプリケーションのパッケージ化」

「ゲスト OS 上でのアプリケーションの実行」

「インフラストラクチャ アドオン パッケージ」


) 目次に戻るには、ここをクリックしてください。


ホスティング インフラストラクチャ

Cisco AXP の Linux ベース機能によって、アプリケーションは Cisco IOS ソフトウェアと対話できます。Cisco AXP のプログラム インターフェイスにより、アプリケーションは Cisco IOS ソフトウェア コンフィギュレーションを変更したり、Cisco IOS ソフトウェアからイベント通知を受信したり、Cisco ISR に接続された周辺装置にアクセスすることができます。

アプリケーションは Cisco ISR と緊密に統合できます。これは、他のサーバベース ソリューションを使用する場合に比べ、ホスティングに Cisco AXP を使用する際の大きな利点です。Cisco AXP は仮想化環境でオペレーティング システムをホスティングし、実行します。

実行環境では、アプリケーション スペースがルータ スペースから切り離され、アプリケーションのホスティングに適した拡張性と柔軟性のあるプラットフォームが用意されます。

図2 Cisco ISR 上の Cisco Application eXtension Platform

 

Cisco AXP では OSGi フレームワークを通じて Java アプリケーションを柔軟に管理できます。

OSGi フレームワークは、ネットワーク型サービスに対応する、標準化されたコンポーネント指向のコンピューティング環境を定義し、Java アプリケーションのライフサイクルをリモートで安全に管理できるようにします。OSGi 仕様の詳細については、 www.osgi.org にアクセスして、OSGi の Web サイトを参照してください。

Cisco AXP は以下をサポートします。

ネイティブ C/C++ で作成されたアプリケーションのホスティング

アプリケーションを起動、停止、監視する基本的なウォッチドッグ機能

x86 ベースの Linux 環境でアプリケーションをコンパイルするためのツール

Cisco AXP がサポートするプログラミング言語およびスクリプト言語は、次のとおりです。

Java

C/C++

Perl

Python

Bash

仮想化

Cisco AXP はオペレーティング システム レベルで仮想化を使用し、複数のアプリケーションを独立型コンポーネントとして実行するための環境を作成します。

仮想化はリソースを分割し、複数の仮想マシン/仮想インスタンスでアプリケーションを同時に実行できるようにすることで現されます。

Cisco AXP における仮想化の利点

Cisco AXP における仮想化の利点は、次のとおりです。

セキュリティの強化

プロセスの分離によるセキュリティの強化

ライブラリの独立性

Cisco AXP 上で実行するために移植されたソフトウェアは、Cisco AXP が提供するライブラリと互換性のない Linux ライブラリに依存している可能性があります。このような Linux ライブラリにアクセスできるようにするには、アプリケーションで専用のゲスト オペレーティング システム(ゲスト OS)環境をロードすることによって、Cisco AXP のゲスト OS からアプリケーションをデカップリングします。さまざまな Linux ディストリビューションのコンポーネントを同じ物理サーバにインストールし、別々の仮想インスタンスで実行できます。各プリケーションに専用の Linux オペレーティング システム、ユーティリティ、およびライブラリを与えます。各アプリケーションには、専用の仮想インスタンス内で管理者アクセス権(root アクセス権)が与えられます。

リソースの分離

アプリケーションごとに専用の CPU セット、メモリ、およびディスク リソース限度を与えます。ある仮想インスタンスで実行しているアプリケーションが、そのインスタンスに割り当てられている以上のリソースを使用することはできません。この制限によって、複数のインスタンスで実行しているすべてのアプリケーションの安定性が向上します。仮想インスタンスは通常、ホスト OS とディスク スペースを共有するので、ディスク スペースを事前に割り当てる必要はありません。

ロー メモリ オーバーヘッド

仮想化を使用するシステムは、ロー メモリ オーバーヘッドによって、パフォーマンスが向上します。


) アプリケーションは Cisco AXP API コールを使用することによって、ホスト OS にのみアクセスできます。


仮想インスタンス

Cisco AXP において、仮想インスタンスは仮想サーバ内のコンテナです。プロセスの分離によってセキュリティが得られ、ある仮想インターフェイスで動作しているプロセスの結果から、別のインスタンスで動作しているプロセスを見ることができなくなります。このテクノロジーでは、ルート変更バリアが適用されます。 /home/app1 の下にアプリケーション ソフトウェアがインストールされていて、アプリケーション プロセスが開始されると、ディレクトリ / home/app1 がそのアプリケーション プロセスのルート ディレクトリになります。プロセスがアクセスできるのは、このルート ディレクトリ下にあるディレクトリだけであり、 /home/app1 からのがれる権限はありません。

ユーザ レベルのプロセスが仮想化され、1 つの Linux カーネルがシステム全体で使用されます。その Linux カーネルが使用するメモリ量とスケジューリングのオーバーヘッドは微小ですが、高速の入出力アクセスが可能です。システムはネイティブ OS に近似したパフォーマンスを提供します。

アプリケーション ソフトウェア(複数のプロセスと機能を組み込むことが可能)は、Cisco AXP パッケージ ツールを使用して、Super Lightweight Installer Mechanism(SLIM)フォーマットでパッケージ化します。パッケージは、仮想インスタンスのルート ディレクトリにインストールされ、1 つの仮想インスタンス内で動作します。

仮想インスタンス内部で動作しているアプリケーションには、ゲスト OS という専用のオペレーティング システム環境が用意されます。ホスト OS がすべてのゲスト OS を管理します。アプリケーションはゲスト OS 内でルートとして実行できます。

サードパーティから提供されたファイルを仮想インスタンス間で共有することはできません。Cisco AXP では、異なる仮想インスタンスでの、アプリケーションによる共有エリアにあるファイルの読み取り、または書き込みのアクセスをサポートしません。

セキュリティをさらに強化するために、ホスト OS のシェル環境はデフォルトで使用不可です。オペレーティング環境を管理するために提供されるのは、ゲスト OS 内部の CLI だけです。ゲスト OS に対するシェル アクセスは、アプリケーション開発者が制御します。

デバイスは仮想化されず、すべての仮想インスタンス間で共有されます。したがって、入出力動作によってオーバーヘッドが増えることはありません。

ネットワーク インターフェイスは、Linux-Vserver の制約があるので、仮想化できません。しかし、「ループバック インターフェイス」で説明するように、「仮想化ループバック インターフェイス」というメカニズムがあります。

インターフェイスの隠蔽は仮想インスタンスで行われます。ネットワーク ルーティング テーブルは仮想化されませんが、Cisco AXP で複数のルーティング テーブルを設定できます。

図3 Cisco AXP の仮想化

 

仮想化はカーネルレベルの分離によって達成され、複数の仮想インスタンスを同時に実行できるようになります。仮想インスタンスは共有カーネルによって分離され、各インスタンスが共通のシステム リソースを利用します。


) Cisco AXP の仮想インスタンス モデルでは、サードパーティが独自にカーネル モジュールまたはデバイス ドライバをインストールすることはできません。


ループバック インターフェイス

Linux-Vserver の制限があるので、ネットワーク インターフェイスは仮想化できません。

アプリケーションはループバックを使用し、内部で通信できます。他の仮想インスタンスまたはホストがインターフェイスを使用しているかどうかを考慮する必要はありません。

Cisco AXP では、各インスタンスのループバック インターフェイスを仮想化できます。

たとえば、ループバックの仮想インターフェイス(lo:2、lo:3)および対応するアドレス(127.0.0.2、127.0.0.3)を仮想インスタンスに提供します。

デフォルトのループバック(127.0.0.1 および lo)は Cisco AXP ホストのループバック インターフェイス用に用意されています。また、各仮想インスタンスでもアクセスできます。

各仮想インスタンスの /etc/host ファイルには、仮想化されたループバック インターフェイスと Cisco AXP ホストのループバック インターフェイスが入力されます。たとえば、アプリケーションを Cisco AXP にインストールした場合、対応する /etc/host ファイルは次のようになります。

127.0.0.x localhost.localdomain localhost
127.0.0.1 apprehost
 

仮想インスタンスでコマンド netstat を実行すると、「lo」が「127.0.0.1」と、「lo:x」が「127.0.0.x」と関連付けられていることが示されます。

x は、仮想インスタンス数に応じて、2 以上の値です。

この値はダイナミックに割り当てられるので、アプリケーションでは x が固定であると想定しないようにします。

たとえば、新しいアプリケーションをインストールした場合、新しいアプリケーションに x を割り当て、元のアプリケーションに x+1 を割り当てることができます。アプリケーションでは、「localhost」が専用の仮想化ループバック インターフェイスであると想定すべきです。

127.0.0.1 は「apprehost」に割り当てられ、127.0.0.x は「localhost」にダイナミックに割り当てられます。

各自のアプリケーションでループバック インターフェイスを扱う場合は、この点に留意する必要があります。


) セキュリティ上の潜在的な問題として、各仮想インスタンスの仮想化ループバック インターフェイスに、他の仮想インスタンスからアクセスが可能です。


専用のアプリケーション リソース

Cisco AXP は CPU、メモリ、ディスク スペースなど、予測可能で一定のリソース セットを提供します。これらのリソースはセグメント化され、他のルータ機能のパフォーマンスに影響を与えることなく、Cisco AXP サービス モジュール上でアプリケーションを実行できます。

管理者の権限で CLI を使用することによって、CPU、メモリ、およびディスク スペースの限度(MB で指定)を指定できます。

次に、Cisco AXP による CPU とメモリの管理について簡単に説明します。

「CPU リソース」

「メモリ リソース」


) 目次に戻るには、ここをクリックしてください。


CPU リソース

サービス モジュールには、使用可能な CPU リソースが CPU インデックスとして指定されて与えられます。サービス モジュールの CPU インデックスは、次の構成に割り当てられた基本値 10000 に対する相対値です。構成は NME_APPRE_302-K9 サービス モジュールのアプリケーション ランタイム エンジン上の 1.0 GHz Celeron M CPU です。

たとえば、サービス モジュール AIM_APPRE 102(ブレード)の CPU インデックスは 3000 です。

アプリケーション パッケージをインストールすると、NME または AIM サービス モジュール上でほぼ同じ容量の CPU リソースが使用されます。 表1 に、各サービス モジュールの CPU インデックスを示します。

 

表1 サービス モジュールの CPU インデックス

サービス モジュール
CPU インデックス
ホスト OS に必要な CPU リソース
残りの CPU リソース

AIM APPRE 102

3000

300

2700

NME APPRE 302

10000

300

9700

NME APPRE 522

14000

300

13700

メモリ リソース

Cisco AXP は仮想メモリにディスク スワッピングを使用しません。したがって、アプリケーションが使用できるメモリ容量は、システムの物理メモリによって制限されます。

仮想インスタンスのコンテキストでは、メモリ限度で各仮想インスタンスが使用できる最大メモリを指定します。メモリのオーバーコミットがイネーブルのときに、仮想インスタンス内の総メモリ使用料がメモリ限度(MB で指定)を超えると、仮想インスタンス内のプロセスが停止されます。

アプリケーションのパッケージ化

アプリケーションのタイプ

Cisco AXP は、Java、C、および Bash スクリプトで作成されたアプリケーションを含め、多様なプログラミング言語をサポートします。Cisco AXP の仮想環境には、アドオン ライブラリおよびパッケージつきの組み込み Cisco Linux ディストリビューションが提供されています。

パッケージ化

アプリケーションを仮想インスタンスにインストールするには、アプリケーションをパッケージ化する必要があります。

パッケージ ツールによって、サードパーティは各自のアプリケーション パッケージをパッケージ化し、バンドルして署名できます。パッケージ ツールを使用するには、サードパーティにアプリケーション開発を承認する、開発者としての証明書がシスコにより、サードパーティに付与される必要があります。サードパーティは、パッケージに署名するときに使用する秘密鍵を所有します。

システムおよびアプリケーション パッケージに含まれるものは、次のとおりです。

コア システム パッケージ

コア システム パッケージは、すべての Cisco AXP サービス モジュールにインストール済みであり、アプリケーションおよび仮想化をサポートするために必要です。

Cisco AXP オペレーティング システムには、仮想化サポート、カーネル、および Linux コマンド、Router Blade Communication Protocol(RBCP)、CLI サーバなどのシステム ユーティリティが組み込まれています。

ホスト オペレーティング システム(ホスト OS)は、サービス モジュール上で動作しているすべての仮想インスタンスによって共有される、コア システム パッケージのカーネルで構成されます。

ゲスト オペレーティング システム(ゲスト OS)はホステッド オペレーティング システムとも呼ばれ、ホスト OS のカーネルを共有する組み込み Linux OS です。

ゲスト OS には、仮想環境セットアップおよび管理ユーティリティとともに、アプリケーションのインストールをサポートするために必要なソフトウェアが組み込まれています。ゲスト OS は、ホスト OS のコア システム パッケージの Linux カーネルを共有します。

ゲスト OS で使用できるコマンドの一覧については、「付録 B:ゲスト OS のコマンド」を参照してください。

パッケージは次の 2 種類に分けられます。

インフラストラクチャ アドオン パッケージ

インフラストラクチャ アドオン パッケージは、ゲスト OS の機能を拡張します(上記のコア システム パッケージを参照)。このパッケージには、シスコが開発したコンポーネントとオープン ソースのソフトウェア コンポーネントの両方が含まれていることがあります。インフラストラクチャ アドオン パッケージは、シスコが作成して署名します。サードパーティの開発者が変更することはできません。アプリケーション ソフトウェアをパッケージ化するときに、インフラストラクチャ アドオン パッケージを選択してアプリケーション ソフトウェアに組み込むことができます。

Cisco AXP は、多様なアプリケーション ホスティング環境をサポートします。パッケージは用途別のアプリケーションに基づいて分かれます。たとえば、OSGi 開発用のパッケージには、OSGi インフラストラクチャ アドオン パッケージが必要ですが、Tomcat パッケージを組み込む必要はありません。

インフラストラクチャ アドオン パッケージに含まれるファイルは、複数の仮想インスタンス間で、読み取り専用として共有されます。

インフラストラクチャ アドオン パッケージの例

Cisco IOS にアクセスするための Cisco IOS サービス API

OSGi 環境およびサポート ライブラリ

Perl インタープリタをサポートする Perl スクリプト言語

デバッグ パッケージ

ホステッド アプリケーション パッケージ

ホステッド アプリケーション パッケージは、サードパーティの開発者が作成してパッケージ化します。これらのパッケージにはバイナリ、サポート ライブラリ、およびサードパーティのソフトウェア アプリケーションを実行するために必要なデータ ファイルが含まれます。各アプリケーション パッケージは、開発者の秘密鍵を使用して署名し、個々の開発者の証明書を使用して確認します。

これらのパッケージのバイナリをホスティングできるのは、Cisco AXP システムの仮想インスタンス内に限られます。

図4 Cisco AXP のアドオン パッケージ

 

Cisco AXP には、複数の仮想インスタンスをサポートするシスコのオペレーティング システムがすでにロードされています。シスコが作成して署名したファイル システムに、インフラストラクチャ アドオン パッケージのコピーが 1 部格納されています。インフラストラクチャ アドオン パッケージの 1 例は、Apache Tomcat です。

インフラストラクチャ アドオン パッケージのコピーは、ポストインストレーション時に仮想インスタンスでインスタンス化されます。インフラストラクチャ アドオン パッケージはファイル システムにありますが、仮想インスタンス間で共有されます。これに対して、サードパーティのアドオン パッケージは、1 つの仮想インスタンス内にサードパーティのアプリケーションが含まれているパッケージです。各サードパーティ アプリケーションに、仮想インスタンスが 1 つだけ存在します。SDK には、複数のパッケージをコンパイルして 1 つのバンドルにする、バンドル ツールも用意されています。

Cisco AXP の証明書

Cisco AXP では、暗号シグニチャを使用してシスコが署名したパッケージを確認し、不正なソフトウェアがオペレーティング システムにロードされないようにします。

この機能は、サードパーティが開発してパッケージ化したアプリケーションまで拡張されます。ただし、サードパーティがシスコの秘密鍵にアクセスしてパッケージに署名することはできません。各自で専用の公開鍵または秘密鍵のペアを管理する必要があります。

図5 Cisco AXP アプリケーションのパッケージ化

 

シスコは、Cisco AXP へのソフトウェア インストールに関連するあらゆる権限を管理します。アプリケーション サードパーティ ソフトウェアをインストールする権限は、アプリケーション サードパーティにそのサードパーティの X.509 証明書のチェックサムを提供することにより、付与されます。図6 を参照して、権限を取得するまでのイベントの流れを確認してください。

図6 Cisco AXP の証明書

 

 

表2 開発許可プロセスのステップ

ステップ
説明
1

サードパーティが証明書要求を生成します(秘密鍵/公開鍵)。

2

サードパーティが認証局に署名入り証明書を要求します。

3

認証局が署名入り X.509 証明書を提供することによって、サードパーティの要求に応じます。1

4

サードパーティはシスコに、ソフトウェア開発許可を要求します(認証局からの署名入り証明書を含む)。

5

シスコが署名入り証明書を認可します。

6

シスコがソフトウェア開発許可の証明書で応答します。2

1. サードパーティはシスコに、署名入り X.509 証明書を提供する義務があります。(ステップ 3)

2.ソフトウェア開発許可の証明書は、Cisco AXP へのソフトウェア インストールをサードパーティに許可する、暗号チェックサムが含まれたファイルです。許可証明書が適用されるのは、認証局が署名した X.509 証明書だけです(表2 のステップ 3)。

許可プロセスのステップに関する注釈

アプリケーションをパッケージ化するときに、サードパーティは次の項目をパッケージに含めます。シスコの許可証明書、サードパーティの証明書、サードパーティの秘密鍵、およびサードパーティのアプリケーションです。

許可証明書のチェックサムを確認したあとで、許可証明書の公開鍵を使用してアプリケーションが検証されます。証明書を使用すると、アプリケーション パッケージとともにアプリケーション ファイルがインストールされているかどうかを確認できます。許可証明書はアプリケーションのマニフェスト ファイルに含まれ、ホスト OS の仮想環境の外部に保管されます。

ターゲット ハードウェアに暗号鍵または証明書を安全に保管できるデバイスが組み込まれている場合、Cisco AXP がサードパーティの鍵を使用してソフトウェアの整合性を確認することはありません。インストールしたソフトウェアは、ハードウェアに結合された秘密鍵を使用して再署名され、対応する公開鍵を使用して検証されます。

Cisco AXP SDK(ソフトウェア開発キット)はサードパーティに、各自のアプリケーション ファイルをパッケージ化して署名し、アプリケーション バンドルに証明書を添付するためのツールを提供します。

ゲスト OS 上でのアプリケーションの実行

組み込み Linux ゲスト OS は、アプリケーション ソフトウェアの依存関係リストに自動的に含まれます。ゲスト OS には、一連の基本的な Linux バイナリおよびライブラリが含まれます。ライブラリの一覧については、付録 C:ゲスト OS のライブラリを参照してください。ゲスト OS はホスト OS とカーネルを共有し、Linux Standard Base の仕様に準拠します。サービス モジュールにインストールすると、各アプリケーション インスタンスがそれぞれ専用のゲスト OS にアクセスし、コンポーネントの追加と変更が可能です。

アプリケーションの起動については、アプリケーションの起動を参照してください。アプリケーションのステータス監視については、アプリケーション ステータスの監視を参照してください。

ゲスト OS の詳細については、下記を参照してください。

「アプリケーションの起動」

「アプリケーションのコンソール アクセス権の取得」

「アプリケーション ステータス」

「アプリケーション ステータスの監視」

「CLI サービス API」

「ロギング サポート」

「SNMP」

ゲスト OS で使用できるライブラリおよびコマンドについては、「付録 C:ゲスト OS のライブラリ」および付録 B:ゲスト OS のコマンドを参照してください。


) 目次に戻るには、ここをクリックしてください。


アプリケーションの起動

アプリケーションの起動は自動方式または手動方式のどちらかで行います。

「自動起動」

「手動起動」

自動起動

自動起動の手順は、次のとおりです。


ステップ 1 ディレクトリ /etc/rc.d/init.d で起動スクリプトを作成します。

ステップ 2 ディレクトリ /etc/rc.d/rc3.d で、startup ソフトリンクを使用して起動スクリプトを参照します。

S<priority><app-name>
 

priority は 0 ~ 99 です。app-name はディレクトリ /etc/rc.d/init.d の起動スクリプトの名前です。

ステップ 3 ディレクトリ /etc/rc.d/rc6.d で、kill ソフトリンクを使用して起動スクリプトを参照します。

K<priority><app-name>
 

priority は 0 ~ 99 です。app-name はディレクトリ /etc/rc.d/init.d の起動スクリプトの名前です。

アプリケーションが起動します。


 

手動起動


) 手動で起動する場合は、最初にゲスト OS シェルへのアクセス権を取得します。
linux shell を使用できるようにするために、先に 「デバッグ パッケージを依存関係として使用するコンソール アクセス」に記載されている手順を実行します。
connect console を使用できるようにするために、先に「ポストインストール スクリプトを使用するコンソール アクセス」に記載されている手順を実行します。


手動起動の手順は、次のとおりです。


ステップ 1 app-service <name>

<name> はアプリケーションの名前です。

ステップ 2 表示されたコマンドに応じて、次のコマンドのうちの 1 つを入力します。

linux shell

connect console

ゲスト OS シェル内に移動するので、そこからアプリケーションを起動できます。


 

アプリケーションのコンソール アクセス権の取得

アプリケーションのコンソール アクセス権を取得するには、次の手順のうちの 1 つを選択します。

「デバッグ パッケージを依存関係として使用するコンソール アクセス」

「ポストインストール スクリプトを使用するコンソール アクセス」

デバッグ パッケージを依存関係として使用するコンソール アクセス

デバッグ パッケージを依存関係として使用してコンソール アクセス権を取得する手順は、次のとおりです。


ステップ 1 アプリケーション開発パッケージ、axp-app-dev.<platform>.<version>.pkg が使用可能であることを確認します。アプリケーションをパッケージ化する場合は、アプリケーション開発パッケージを依存関係として指定します。

ステップ 2 Cisco AXP にアプリケーションをインストールします。

アプリケーションはコマンド linux shell を使用することによって、ゲスト OS シェルにコンソール アクセスできるようになります。


 

ポストインストール スクリプトを使用するコンソール アクセス

コンソール アクセス権を取得するには、アプリケーションをインストールする前に、スクリプトを 2 つ作成します。最初のスクリプトはログイン スクリプトであり、2 番めのスクリプトであるポストインストール スクリプトを使用して /bin/console に接続します。

ポストインストール スクリプトを使用してコンソール アクセス権を取得する手順は、次のとおりです。


ステップ 1 ログイン スクリプトを作成します。たとえば、ファイル /source/bin/login.sh を作成します。/source はビルド ディレクトリです。

ログイン スクリプト:例

#! /bin/sh
/bin/bash --login
 

ステップ 2 ポストインストール スクリプトを作成します。たとえば、スクリプト /source/bin/postinstall.sh を作成します。/source はビルド ディレクトリです。

ポストインストール スクリプト:例

#! /bin/sh
ln -s /bin/login.sh /bin/console
 

アプリケーションをパッケージ化する場合は、ポストインストール スクリプトを参照します。ポストインストール スクリプトの非所有者ユーザのアクセス権を read-execute に変更します。

chmod 755 /opt/tcptrace/postscripts/postinstall.sh
 

ポストインストール スクリプトを使用すると、コマンド connect console により、アプリケーションからゲスト OS シェルにコンソール アクセスができるようになります。


 

アプリケーション ステータス

アプリケーションは、ステータスを伝える通知コマンドを呼び出す必要があります。「通知」を参照してください。たとえば、コンフィギュレーション CLI コマンドでアプリケーションが使用可能かどうかを検出するのに必要です。

アプリケーションがアップであり、実行中であることを示すステータス コードを送信するアプリケーションは、常時コンフィギュレーション コマンドの受信を想定します。 表3 に発生するステータス コードを示します。

 

表3 ステータス コード

ステータス コード
説明

INITIALIZING

アプリケーションの起動中

ALIVE

アプリケーションを実行中

DOWN

アプリケーションがダウン

通知

通知コマンドの保管場所は /bin/app_status_notifier です。

アプリケーション名およびステータス コードは、パラメータまたは引数として通知コマンドに伝達されます。

通知:例

 
#/bin/app_status_notifier myapp ALIVE
 

アプリケーションの状態表示

アプリケーションの状態を表示する手順は、次のとおりです。


ステップ 1 app-service <name>

<name> はアプリケーション名です。

ステップ 2 show state

詳細については、『 Cisco AXP User Guide 』の「Viewing the Application State」を参照してください。


 

アプリケーション ステータスの監視

アプリケーションは、Cisco AXP アプリケーション モニタリング機能を使用する、1 つまたは複数のウォッチドッグ スクリプトまたは実行可能ファイルをパッケージにバンドルして提供する必要があります。

次に、アプリケーションをモニタリングする 2 種類の方式について説明します。

「ウォッチドッグ スクリプト」

「ステータス モニタ」

ウォッチドッグ スクリプト

アプリケーションのステートが「オンライン」で、アプリケーションの状態が「ダウン」ではない場合、アプリケーションの監視はアプリケーション ステータス モニタで行います。

アプリケーションは 1 つまたは複数の ウォッチドッグ スクリプト (別名、ヘルス チェック スクリプトまたはヘルス チェック実行可能ファイル)を提供する必要があります。シェル スクリプトおよび C 実行可能ファイルがサポートされます。スクリプト数はアプリケーションによって異なります。

ウォッチドッグ スクリプトはアプリケーション パッケージにバンドルします。

アプリケーションは独自の方法で、別のアプリケーションが実行中かどうかを判別します。たとえば、アプリケーションはプロセス ID(PID)をチェックしたり、「ping」への応答をチェックできます。

ウォッチドッグ スクリプトは、前もって定義されているディレクトリ /opt/app_status_monitor/watchdogs/ に配置する必要があります。

ウォッチドッグ スクリプトのディレクトリはアプリケーションの vserver ディレクトリ内であり、実行可能ファイルへのアクセス権が必要となります。ディレクトリ内のすべてのウォッチドッグ スクリプトが呼び出されます。スクリプトが正しい順序で呼び出されるようにするには、次のテンプレートに従ってウォッチドッグ スクリプト名を指定します。

W**<name>.sh
 

** は 2 桁の数字です。たとえば、W01myapp.sh というウォッチドッグ スクリプトを使用できます。

アプリケーション ステータス モニタのハートビートは 5 秒です。5 秒は 1 インターバルに相当します。5 秒は、アプリケーション ステータス モニタがモニタリングに要する最小インターバルです。

ウォッチドッグ スクリプトの 1 つからゼロ以外のステータス コードが戻ると、その失敗したウォッチドッグの情報が記録されます。含まれる情報は、ウォッチドッグ名、戻りステータス、および障害発生時刻です。回復カウンタが障害の発生回数をカウントし、処置を行うまでにかかる時間として機能します。回復カウンタが 3 の場合、アプリケーション モニタは監視を 3 回反復しし、いずれかが非ゼロの戻りステータスを得たか、またはウォッチドッグが 3 回のモニタ インターバルにわたって実行中であり、戻っていないことを意味します。設定可能な回復しきい値によって、次の処置を実行するまでに回復カウンタの値が増える回数が決まります。回復しきい値に達した場合は、仮想インスタンスが再起動します。仮想インスタンスの再起動後、アプリケーション ステータス モニタリングが続けられ、上記のモニタリング ステップが続行されます。仮想インスタンスの再起動回数に制限はありません。

モニタ インターバルの設定については、「ステータス モニタ」を参照してください。『 Cisco AXP User Guide 』も参照してください。各スクリプトまたは実行可能ファイルは、ステータス コードを戻す必要があります。

ステータス コードがゼロ(0)の場合、アプリケーションは正常であり、アクティブです。

ステータス コードが非ゼロ値の場合、アプリケーションは機能していません。アプリケーションがクラッシュした場合などです。

ウォッチドッグ スクリプト:例

#!/bin/bash
APP=test.sh
APPNAME_NO_EXT=test
PID_FILE=/var/run/${APPNAME_NO_EXT}.pid
if [ ! -e $PID_FILE ]; then
exit 1;
fi
PID_FROM_FILE=`cat ${PID_FILE}`
for x in `ps -ef|grep $APP |awk '{print $2}'`
do
if [ $x == "${PID_FROM_FILE}" ]; then
exit 0
else
exit 1
fi
done
 

このウォッチドッグ スクリプト例では、起動スクリプトが現在実行中のアプリケーションの PID を /var/run/<app>.pid ファイルに入力していなければなりません。起動スクリプトは、次のようなシナリオについても説明する必要があります。

実行するアプリケーション インスタンスを 1 つに限定する

シャットダウン時に /var/run/<app name>.pid ファイルを削除する

ウォッチドッグ スクリプトからゼロ以外のステータス コードが戻ると、ウォッチドッグ名、戻りステータス、障害発生時刻などの情報が記録されます。回復カウンタは、障害の発生回数を数えます。3 という回復カウンタ値は、次の 2 つの条件のいずれかを示します。

アプリケーション ステータス モニタが 3 回実行され、非ゼロのステータス コードを受け取った。

ウォッチドッグが 3 回のモニタ インターバルで実行したが、非ゼロのステータス コードが戻らなかった。

回復カウンタがどの値に達したら、次の処置を実行するかを決定する、設定可能な回復しきい値があります。回復しきい値に達した場合は、仮想インスタンスが再起動します。

仮想インスタンスの再起動後、アプリケーション ステータス モニタの実行が続行され、上記の 2 つの条件が再度テストされます。仮想インスタンスの再起動回数に制限はありません。

ステータス モニタ

次のコマンド例には、 show status-monitor コマンドのほかに、モニター インターバルおよび回復しきい値を設定するコマンドが含まれています。詳細については、『 Cisco AXP User Guide 』の「The Status Monitor」を参照してください。

ステータス モニタの表示

blade# app-service myapp
(myapp)# show status-monitor
Application: myapp1
Monitor status: PASSED
Monitor in progress: No
Last executed watchdog: W01myapp1_test.sh
Last executed date: Tue Jul 10 10:22:06 PDT 2007
Last failed watchdog: W01myapp1_test.sh
Last failed return code: 4
Last failed date: Mon Jul 9 12:34:18 PDT 2007
Last restarted date: Mon Jul 9 12:33:32 PDT 2007
Recovery threshold: 6
Monitor interval: 2
 

モニタ インターバルおよび回復しきい値の変更

blade# config terminal
(config)# app-service myapp
(config-myapp)# status-monitor monitor_interval 24 recovery_threshold 10
(config-myapp)# end
 


 

コンフィギュレーション ファイル

さらに、アプリケーションとともにパッケージ化したコンフィギュレーション(config)ファイルを使用することによって、デフォルトのコンフィギュレーションを提供できます。

コンフィギュレーション ファイルの名前およびパスは、次のとおりです。

/opt/app_status_monitor/config/config
 

コンフィギュレーション ファイルにおける各レコードのフォーマットは、次のとおりです。

[monitor_interval | recovery_threshold] [1-99]
 

monitor_interval のデフォルト値は 12 です。12 のハートビートごとに、アプリケーションがモニタリングされます。モニタ インターバルが 12 の場合、各仮想インスタンス上で 1 分ごとにモニタがアクティブになります。

recovery_threshold のデフォルト値は 5 です。


) コンフィギュレーション ファイルには、monitor_interval と recovery_threshold の両方が必要です。


コンフィギュレーション ファイル:例

monitor_interval 50
recovery_threshold 10
 

設定値(モニタ インターバルおよび回復しきい値の変更例で設定した 24 および 10 の値など)は、コンフィギュレーション ファイルの値より優先されます。コンフィギュレーション ファイルは、アプリケーションのインストール時にデフォルト値のソースとして提供されるだけです。

CLI サービス API

CLI サービス API によって、アプリケーションがホスト上の基本 CLI サーバと対話できるようになります。

たとえば、Java アプリケーション コードは EXEC モード コマンドまたはコンフィギュレーション モード CLI コマンドを発行できます。

特定のモードに適したコマンドを発行するように、注意する必要があります。たとえば、 show run は EXEC モードで発行します。他のモードで発行すると、エラーが発生します。サポート対象の主要プログラミング/スクリプト言語は C、C++、Java、Python、および Perl です。次に、各言語に対応する CLI サービス API を示します。

CLI コマンドは、1 つのインスタンス内でアプリケーションから一括して送信できます。これはイメージのリフレッシュ後に再設定する場合など、反復作業の自動化に有効です。

Cisco AXP SDK には、CLI サービス EXEC モード コマンドまたはコンフィギュレーション モード コマンドを作成するために必要なライブラリおよびモジュールが含まれます。 表4 に、SDK でサポートされる言語および関連ライブラリ/モジュールを示します。

 

表4 CLI サービス API 用のファイル

言語
ライブラリ/モジュール/ヘッダー ファイル

C/C++

/include/appreapi.h
/lib/libappreapi.so

Java

/jar/appreapi.jar

Python

/python2.3/AppreAPI.py

Perl

/perl/AppreAPI.pm

CLI サービス API

Java API

public int exec (AppreMessage msg);
public int config (AppreMessage msg);
 

Java bean オブジェクト AppreMessage には、要求ストリングと応答ストリングの両方が格納されます。

コードの実行後に戻るステータス コードが、完了または失敗を示します。ステータス コード値については、 表5 を参照してください。

public class AppreMessage{
private String _response;
private String _request;
 
public void AppreMessage(){
this._response = "";
this._request = "";
}
public String getRequest(){
return this._request;
}
public void setRequest(String request){
this._request = request;
}
public String getResponse(){
return this._response;
}
public void setResponse(String response){
this._response = response;

C/C++ API


) は、コール プログラムは割り当てられたメモリの解放を受け持ちます。コール プログラムで char* をNULL に設定した場合、システムが必要なメモリを割り当てますが、メモリの解放はコール プログラムで行う必要があります。


int appreapi_exec(AppreMessage_t* msg);
int appreapi_conf(AppreMessage_t* msg);
 
free (msg.response);
 

AppreMessage_t は、要求ストリングおよび応答ストリングが格納される構造体です。

コードの実行後に戻るステータス コードが、完了または失敗を示します。ステータス コード値については、 表5 を参照してください。

typedef struct AppreMessage_t{
char* request;
char* response;
int size;
} AppreMessage_t;
 

Perl API

sub exec (request)
sub config (request)
 

要求ストリングが入力、ステータス コード値が出力です。ステータス コード値については、 表5 を参照してください。

Python API

sub exec (request)
sub config (request)
 

要求ストリングが入力、ステータス コード値が出力です。ステータス コード値については、 表5 を参照してください。

Bash API

appreapi [--mode name] [[--file filename] | [cmdlist]]
 

要求ストリングが入力、ステータス コード値が出力です。ステータス コード値については、 表5 を参照してください。

 

表5 CLI サービスの戻りステータス コード

ステータス コード(C/C++)
ステータス コード(Java)
説明

APPRE_OK

AppreAPI.OK

0

要求は正常に処理されました。

APPRE_FAIL

AppreAPI.FAIL

1

エラーが原因で要求が打ち切られました。応答ストリングが戻った場合(Java/C)、エラーの説明が含まれています。

APPRE_FILE

AppreAPI.FILE

2

要求は処理されました。応答ストリングが戻った場合(Java/C)、ファイル名およびパスが含まれており、ファイルに書き込まれます。

CLI サービス API の例

次の例では、 request (C)、 setRequest (Java)などの関数またはメソッドにストリングを渡すことによって、コマンドが発行されます。コマンドをカンマで区切ると、一度に複数のコマンドを渡すことができます。setRequest( ) を使用して 2 つ以上のシステム コマンドをコールする例を示します。

msg.setRequest(cmd)
 

cmd は、カンマで区切ったコマンド シーケンスを含むストリングです。

例を示します。

String cmd = "show run,show trace”
 

次に、主要なプログラミング/スクリプト言語である C/C++、Java、Perl、および Python で AppreMessage を実装するコードの部分を示します。

「C/C++:例」

「Java:例」

「Perl:例」

「Python:例」

C/C++:例

#include "appreapi.h"
 
int main(int argc, char** argv){
char buf[] = "show run";
AppreMessage_t msg;
msg.size = 0;
msg.response = NULL;
msg.request = buf;
int status = APPRE_FAIL;
status = appreapi_conf(&msg);
status = appreapi_exec(&msg);
return status;
}
 

Java:例

import com.cisco.aesop.apphosting.appreapi.*;
 
public static void main (String[] args){
int status = 0;
CommonServiceImpl apiCall = new CommonServiceImpl();
AppreMessage msg = new AppreMessage();
 
msg.setRequest("show run");
 
status = apiCall.exec(msg);
status = apiCall.config(msg);
}
 

上の例では、Java クラス CommonServiceImpl が API アクセス サービスを実装します。

このクラスには EXEC モードとコンフィギュレーション モードに対応する 2 つのメソッドがあります。

public int exec (AppreMessage msg)
 
public int config (AppreMessage msg)
 

Perl:例

use AppreAPI;
 
$api = new AppreAPI::AppreAPI();
$req = "show run";
($val, $res) = $api->exec($req);
($val, $res) = $api->config($req);
 

Python:例

from AppreAPI import *
 
api=AppreAPI()
status, response = api.exec(request)
status, response = api.config(request)

ロギング サポート

Cisco AXP は、アプリケーションのロギングをサポートします。syslog または log4j ロギング ファシリティ、ロギング ファイルのファイル ローテーションが含まれます。さまざまなロギング レベルを設定できます。ロギング レベルより下のレベルでエラーが発生した場合、そのエラーはログ ファイルでは報告されません。ロギング エラーの詳細については、「ロギング」を参照してください。

SNMP

アプリケーションで SNMP を使用するには、net-snmp コードを使用します。net-snmp コードの保管場所は、2 箇所あります。

ゲスト OS の C ライブラリ /lib/libsnmplib.so

ディレクトリ ~/include/net-snmp にある Cisco AXP SDK のヘッダー ファイル。net-snmp ライブラリは、インターネット アクセスにソケットを使用します。

net-snmp API については、 http://net-snmp.sourceforge.net/docs/man/ を参照してください。

net-snmp のチュートリアルおよびサンプル コードのリンク

net-snmp のチュートリアルおよびサンプル アプリケーションについては、
http://net-snmp.sourceforge.net/ を参照してください。

net-snmp API コールを使用するコードの例については、「net-snmp:例」を参照してください。

インフラストラクチャ アドオン パッケージ

使用可能な付加価値サービス API またはアドオン パッケージの詳細については、 インフラストラクチャ アドオン パッケージ リスト を参照してください。

パッケージ名

パッケージ名のフォーマットは、<パッケージ>.<プラットフォーム>.<バージョン>.pkg です。

たとえば、axp-tomcat5.nme.1.0.1.pkg というパッケージの場合、パッケージは tomcat、プラットフォームは nme、バージョンは 1.0.1 です。

この例のバージョン番号は、メインの Cisco AXP パッケージ(axp-k9.<platform>.<version>.pkg)のバージョン番号と同じです。

各インフラストラクチャ アドオン パッケージのペイロード ファイルをダウンロードに使用できます。サフィックスは ".prt1" です。

インフラストラクチャ アドオン パッケージのダウンロード

インフラストラクチャ アドオン パッケージを使用するには、www.cisco.com からパッケージをダウンロードし、各自のアプリケーションにバンドルしてから、サービス モジュールに各自のアプリケーションをインストールします。

インフラストラクチャ アドオン パッケージ リスト

Cisco AXP に用意されているインフラストラクチャ アドオン パッケージは、次のとおりです。

「OSGi」

「Tomcat」

「アプリケーション SSH」

「アプリケーション開発パッケージ」

「CLI プラグイン ディストリビューション サービス」

「Cisco IOS サービス API」

「Embedded Event Manager API」

「リモート シリアル デバイス」

「Perl」


) 目次に戻るには、ここをクリックしてください。


OSGi

パッケージ名: axp-prosyst-mbs6.<platform>.<version>.pkg

パッケージ名:例

axp-prosyst-mbs6.nme.1.0.1.pkg

OSGi フレームワーク仕様では、デバイスの動作に影響を与えることなく、Java アプリケーションまたはコンポーネントのバンドルのインストール、起動、停止、アップデート、およびアンインストールをリモートで行う方法が定義されています。

OSGi インフラストラクチャ アドオン パッケージ バンドルを使用すると、コンピュータ オペレーティング システムを再起動することなく、アプリケーションまたはコンポーネントの起動、停止、アップデート、またはアンインストールをリモートで実行できます。

ProSyst は商用 OSGi ソフトウェアのプロバイダーであり、ProSyst パッケージは OSGi TM フレームワークの拡張および最適化を含めた組み込みシステムを提供します。

パッケージ axp-prosyst-mbs6.<platform>.<version>.pkg は、ProSyst Embedded Server mBS6.0 Framework パッケージです。

パッケージ package axp-prosyst-mbs6.<platform>.<version>.pkg がシステム要件を満たさない場合は、ProSyst から OSGi TM バンドルを購入して、アプリケーションとともにパッケージ化してください。

インフラストラクチャ アドオン パッケージ axp-prosyst-mbs6.<platform>.<version>.pkg には、組み込みライセンス キーはありません。パッケージを使用する前に、ProSyst からライセンスを取得してください。ライセンス キー ファイル(domain.crp)は、プロジェクト ディレクトリ /opt に置きます。

axp-prosyst-mbs6.<platform>.<version>.pkg の起動スクリプトは、ライセンス キー ファイルをコピーしてから mBeddedServer を起動します。

OSGi フレームワークの管理には、Cisco AXP の CLI コマンドを使用します。 connect osgi を使用します。 Cisco AXP User Guide 』の「Configuring the Application Service Environment」を参照してください。

このコマンドは、Prosyst OSGi フレームワークのテキスト コンソールに相互接続します。テキスト コンソールから Prosyst テキスト コマンド(CLI)を使用して、OSGi フレームワークを管理できます。

Tomcat

パッケージ名: axp-tomcat5.<platform>.<versionジョン>.pkg

パッケージ名:例

axp-tomcat5.nme.1.0.1.pkg

tomcat パッケージを使用して、Tomcat 5.5 servlet コンテナを仮想インスタンスに組み込みます。

アプリケーション SSH

パッケージ名: axp-ssh-4.6p1-k9.<platform>.<version>.pkg

パッケージ名:例

axp-ssh-4.6p1-k9.nme.1.0.1.pkg

アプリケーション SSH パッケージは、SSH トンネリングの作成に使用します。「SSH トンネリング」を参照してください。

アプリケーション開発パッケージ

パッケージ名: axp-app-dev.<platform>.<version>.pkg(axp-app-dev.nme.1.0.1.pkg など)

Linux シェルにアクセスして CLI コマンドを発行します。「アプリケーションのコンソール アクセス権の取得」を参照してください。

アプリケーションをパッケージ化するときに、パッケージ axp-ssh-4.6p1-k9.<platform>.<version>.pkg または axp-app-dev.<platform>.<version>.pkg のどちらかを依存関係として追加します。

アプリケーション開発パッケージは、仮想インスタンスで動作する SSH サーバを提供します。

SSH トンネリング、rsync ユーティリティ、および GDB デバッグについては、「デバッグ ツール」を参照してください。

CLI プラグイン ディストリビューション サービス

パッケージ名: axp-cli-plugin.<platform>.<version>.pkg(axp-cli-plugin.nme.1.0.1.pkg など)

Cisco AXP CLI プラグイン ディストリビューション サービスは、Cisco AXP システム内で各自の CLI を使用するために必要なライブラリを提供する、インフラストラクチャ アドオン パッケージです。このサービスは、Cisco AXP CLI サーバからアプリケーションに CLI プラグインを配布します。

3 種類の主要なコンポーネントを定義する必要があります。CLI プラグイン定義、CLI プラグイン ディストリビューション リスナー、および CLI プラグイン アクションです。「CLI プラグイン アプリケーション」を参照してください。

Cisco IOS サービス API

パッケージ名: axp-iosapi.<platform><version>.pkg(axp-iosapi.nme.1.0.1.pkg など)

Cisco IOS サービス API によって、ルータ情報にアクセスし、コンフィギュレーション モードおよび EXEC モードの Cisco IOS コマンドと同等のコマンドを使用してシステム コンフィギュレーションを変更するアプリケーションを作成できます。

Cisco AXP SDK には、Cisco IOS コンフィギュレーション モード コマンドを使用するアプリケーションの作成に必要なライブラリおよびモジュールが含まれています。 表6 に、SDK でサポートされる言語および関連ライブラリ/モジュールを示します。

 

表6 Cisco IOS サービス API 用のファイル

言語
ライブラリ/モジュール/ヘッダー ファイル

C/C++

iosapi.h
libiosapi.so

Java

iosapi.jar

Python

iosapiPython.so
IosapiFactory.py
Iosapi.py

Perl

iosapi.pm

Bash

iosapi

次に示す各 API には、タイムアウト API が組み込まれています。タイムアウト API を使用すると、戻りメッセージを待機中に、コール プログラムが膠着状態にになるのを防ぎます。タイムアウトの時間の長さは、引数としてタイムアウト API に渡されます。コール プログラムで、特定のバッチ処理(一括実行)にこのタイムアウト期間を設定しておくことができます。タイムアウトは、同一セッションで、タイムアウト API をコールしたあとのすべての Cisco IOS ソフトウェア コマンドに適用されます。

Cisco IOS API

Cisco IOS コマンドにアクセスするための API は、次のとおりです。

C/C++ API

typedef struct IosServiceAPI_t {
apiMethod exec;
apiMethod config;
} IosServiceAPI_t;
 
extern int getIosApi(const char *serviceName, IosServiceAPI_t* iosapi);
 
void set_timeout (int sec)
 

Java API

public int exec(IosapiMessage msg);
 
public int Config(IosapiMessage msg);
 
public void set_timeout (int sec);
 

Python API

class Iosapi
def Config(self, request)
 
def Exec(self, request)
 
def Set_timeout(self, sec)
 

Perl API

package Iosapi::Iosapi;
sub exec(self, request);
 
sub config(self, request);
 
sub set_timeout (timeout)
 

Bash API

appreapi [--mode name] [[--file filename] | [cmdlist]] [--timeout sec]
 

Cisco IOS API の応答およびステータス

C、C++、および Java の場合、API は応答ストリングを戻します。この応答ストリングは、メッセージ構造体に格納されます。

Perl および Python の場合、API は応答ストリングおよびステータス コード(複数の戻り値)を戻します。

次の表で、戻る可能性のあるステータス コードについて説明します。

 

表7 Cisco IOS の戻りステータス コード

ステータス コード(C/C++)
ステータス コード(Java)
説明

IOSAPI_OK

IosServiceAPI.OK

0

要求が処理され、正常に実行されました。

IOSAPI_FAIL

IosServiceAPI.FAIL

1

エラーが原因で要求が打ち切られました。
応答ストリングが戻った場合(Java/C)、エラー メッセージが含まれています。

IOSAPI_FILE

IosServiceAPI.FILE

2

要求は正常に処理されました。
応答ストリングが戻った場合(Java/C)、ファイル名およびパスが含まれており、ファイルに書き込まれます。

Cisco IOS API の例

次の Cisco IOS API 例では、 request (C)、 setRequest (Java)などの関数またはメソッドにストリングを渡すことによって、コマンドが発行されます。各コマンドをセミコロンで区切ると、複数のコマンドを一度に渡せます。 setRequest を使用して 2 つまたはそれ以上のシステム コマンドをコールする例を示します。

msg.setRequest(cmd)
 

cmd は、セミコロンで区切ったコマンド シーケンスを含むストリングです。

例を示します。

String cmd = "int fa0/0; ip address 172.31.100.195; no shutdown"
 

C/C++:IosapiMessage_t

C/C++ の場合、構造型変数 IosapiMessage_t を使用します。

typedef struct IosapiMessage_t {
char *request;
char *response;
int size;
} IosapiMessage_t;
 

response :API に応答用メモリを割り当てさせる場合は、ゼロに設定します。ユーザ自身で応答用メモリを割り当てる場合は、非ゼロに設定します。

size :ゼロに設定API がメモリを割り当てるには、非ゼロを設定します。コール側がメモリを割り当てる場合は、非ゼロに設定します。

どちらの場合も、コードの実行後に、割り当てられたスペースを解放する必要があります。


) 応答ストリングが使用するメモリ スペースの割り当ておよび解放は、コール側の責任で行います。


C/C++:例

#include "iosapi.h"
 
int main(int argc, char** argv){
char buf[] = "show run";
IosServiceAPI_t iosapi;
IosapiMessage_t msg;
msg.size = 0;
msg.response = NULL;
msg.request = buf;
getIosApi("CommonService", &iosapi);
retcode = iosapi.exec(&msg);
retcode = iosapi.config(&msg);
return retcode;
}
 

Java:IosapiMessage

Java の場合は、bean オブジェクト IosapiMessage を使用します。

public class IosapiMessage {
public void setRequest(String request);
public void setResponse(String response);
public String getRequest();
public String getResponse();
}
 

Java:例

import com.cisco.aesop.apphosting.iosapi.*;
 
public static void main (String[] args){
int status = 0;
IosServiceAPI iosapi = IosapiFactory.getIosApi("commonservice");
IosapiMessage msg = new IosapiMessage();
msg.setRequest("show run");
status = iosapi.exec(msg);
status = iosapi.config(msg);
}
 
Perl: Example
 
use Iosapi::Iosapi;
my $request = "show run";
my $type = "CommonService";
my $val;
my $response;
 
$iosapi = Iosapi::Iosapi->new($type);
($val, $response) = $iosapi->exec($request);
($val, $response) = $iosapi->config($request);
 

Python:例

import Iosapi
import IosapiFactory
 
type = "CommonService"
request = "show run"
val, iosapi = IosapiFactory.getIosApi(type)
val, response = iosapi.Exec(request)
val, response = iosapi.Config(request)
 

コンフィギュレーション

Cisco IOS ソフトウェアの Netconf over BEEP は、どのような認証もサポートしません。Netconf over BEEP がサポートするのは、SASL/Anonymous プロファイルだけです。

セキュリティを強化するために、netconf コンフィギュレーションに ACL(アクセス コントロール リスト)を追加し、netconf/BEEP 接続へのアクセスを許可または拒否することができます。「Cisco IOS ソフトウェア内のコンフィギュレーション例」 を参照してください。

Netconf over BEEP の詳細については、次の URL にアクセスしてください。
http://www.cisco.com/en/US/products/ps6441/products_feature_guide09186a00806a5961.html

Cisco IOS ソフトウェア内のコンフィギュレーション例

>config t
>sasl profile JAVALIN_ANONYMOUS_SASL
>mechanism anonymous
>ip access-list standard 1
>permit host 10.1.10.2
>netconf beep listener 12345 acl 1 sasl JAVALIN_ANONYMOUS_SASL
>netconf max-sessions 16
 

Cisco AXP Service Module 内のコンフィギュレーション例

>config t
>netconf beep initiator 1.100.50.1 12345
>netconf max-sessions 16
 

1.100.50.1 は Cisco IOS ルータの IP アドレスです。

ポート 12345 は、Cisco IOS ソフトウェアおよび Cisco AXP の両方と一致するポートです。 12345 という番号は 1 つの例です。

Embedded Event Manager API

パッケージ名: axp-eemapi.<platform>.<version>.pkg

パッケージ名の 1 例は axp-eemapi.nme.1.0.1.pkg です。

Embedded Event Manager(EEM)は、Cisco IOS イベント通知をサポートし、Cisco IOS ソフトウェアからユーザの Cisco AXP アプリケーションに、広範囲なイベントを報告できるようにします。

Cisco AXP EEM API は、次の Cisco IOS イメージをサポートします。

IP-Voice

Adv-Security

Adv-Enterprise

Cisco AXP アプリケーションのイベントを登録するには、次の 2 つの方法のどちらか 一方 を使用します。

1. パッケージ化するときに、イベント コンフィギュレーション ファイルを使用します。これが推奨方式です。「イベント コンフィギュレーション ファイルを使用して登録する場合」を参照してください。

2. アプリケーションに対応する Cisco AXP CLI を使用してイベントを登録します。『 Cisco AXP User Guide 』の「Registering an Event Using the Cisco AXP Service Module」を参照してください。

Cisco IOS EEM の設定は、起動時に自動的に行われます。この設定には、各イベントに対応する EEM ポリシー ファイルの生成、Cisco IOS へのファイルの引き渡し、および EEM の設定が含まれます。

要求されたイベントが発生すると EEM が EEM ポリシーをトリガーします。これは通常、Tcl スクリプトです。イベント ポリシーの実行によって、Cisco AXP ホスト上の EEM イベント ディスパッチャにイベント情報が渡されます。ディスパッチャはイベントを登録したアプリケーションに、イベントをディスパッチします。

EEM の詳細については、次のマニュアルを参照してください。

Embedded Event Manager Overview

Writing Embedded Event Manager Policies Using Tcl

Writing Embedded Event Manager Policies Using the Cisco IOS CLI

API コールを使用してイベントを通知する場合は、「EEM API」を参照してください。

イベント コンフィギュレーション ファイルを使用して登録する場合

イベント コンフィギュレーション ファイル eem_config.xml にイベントを指定します。アプリケーションとともにイベント コンフィギュレーション ファイルをパッケージ化し、ブレードにアプリケーションをインストールします。リブート時に EEM 固有の起動ルーチンが実行されると、対応するイベント ポリシー ファイルが設定され、Cisco IOS EEM が設定されます。イベントがアクティブになります。

イベント コンフィギュレーション ファイルの例および対応する DTD については、「イベント コンフィギュレーション ファイル:例」および「イベント コンフィギュレーション ファイル DTD:例」を参照してください。イベント要素の名前アトリビュートは、ファイル内で重複しないようにする必要があります。

パラメータ ストリングを入力する場合は、ストリング全体を二重引用符で囲み、サブストリングを単一引用符で囲みます。例を示します。

<event name = "myeventname" type = "syslog" parameter = "pattern 'ethernet' " />
 

) EEM API アドオン パッケージを使用してアプリケーションをパッケージ化するときには、イベント コンフィギュレーション ファイル eem_config.xml をディレクトリ ~/usr/eemapi に置く必要があります。


イベント コンフィギュレーション ファイル:例

<Events >
<event name=”myCLIEvent” type=”timer” parameter = “cron name ... “ />
<event name=”myIntEvent” type=”interface” parameter= “name Ethernet0/0 .......” />
<event name=”myiosevent” type=”ios_config” / >
<\Events>
 

イベント コンフィギュレーション ファイル DTD:例

<!ELEMENT events (event+) >
<!ELEMENT event EMPTY>
<!ATTLIST event name CDATA #required>
<!ATTLIST event parameter CDATA >
<!ATTLIST event type ( appl | cli | counter | interface | ioswdsysmon |
none | oir | snmp | syslog | timer | timer_subscriber |
ios_config) #required>
 

イベント タイプ アトリビュート値は、EEM のイベント レジスタ キーワードにマップするタイプのリストで構成されています。さらに、event ios_config のように、EEM からは提供されない他の Cisco IOS イベントがあります。

イベント タイプおよびコマンド拡張機能

表8 に、イベント タイプおよび対応するコマンド拡張機能を示します。


) イベント タイプ ios_config は Cisco IOS ソフトウェアのイベント タイプであり、パラメータ値はありません。



表8 のタイプ リストは、完全ではない可能性があります。タイプの詳細については、『Writing Embedded Event Manager Policies Using Tcl』の「EEM Policy Tcl Command Extension Reference」を参照してください。


 

表8 イベント タイプおよびコマンド拡張機能

イベント タイプ
コマンド拡張機能

appl

event_register_appl

cli

event_register_cli

counter

event_register_counter

interface

event_register_interface

ioswdsysmon

event_register_ioswdsysmon

none

event_register_none

oir

event_register_oir

snmp

event_register_snmp

syslog

event_register_syslog

timer

event_register_timer

timer_subscriber

event_register_timer_subscriber

ios_config(IOS イベント)

[値なし]

EEM API

イベント通知

アプリケーションから API コールを使用してイベントを通知するには、イベント通知を受信するイベント ハンドラの機能を使用します。eemapi をパッケージ化するときに(パッケージ
axp-eemapi.nme.1.0.1.pkg
など)、ユーザのアプリケーションに依存関係を設定しておくことも必要です。この依存関係は、アプリケーションのパッケージ化時に設定します。パッケージ化の詳細については、「アプリケーションのパッケージ化」を参照してください。

次に、Java、C、および Python に対応する EEM API を示します。

 

表9 EEM API 用のファイル

言語
ライブラリ/モジュール/ヘッダー ファイル

Java

eemapi.jar

C/C++

eemapi.h
libeemapi.so

Python

eemapi.py

Java の EEM API はファイル eemapi.jar にバンドルされています。このファイルには、EEM イベントの受信をサポートするあらゆる インターフェイス API が含まれています。

 

Java
package com.cisco.aesop.apphosting.eemapi
 
EventManager.java
 
int Register (EventHandler eventHandler, String eventTypes)
 

EEM イベントを受信するイベント リスナー スレッドを起動します。

パラメータ:

eventHandler :EventHandler クラスのサブクラスのオブジェクト

eventTypes :イベント タイプのストリング

戻り値:

1: 成功

< 0: 失敗

int Deregister()
 

イベント受信を中止します。

戻り値:

1: 成功

< 0: 失敗

//get the single instance of EventManager.
EventManager em = EventManager.getInstance();
int regOk = em.Register(eventHandler, “cli interface”);
int result = em.Deregister();
 

C の EEM API は、ゲスト OS のディレクトリ /lib にある lib eemapi.so にバンドルされています。ユーザのアプリケーションにヘッダー ファイル eemapi.h を組み込む必要があります。

 

C
eemapi.h
 
EEMRegister (void * eventhandlerFP, char *eventTypes)
 

EEM イベントの受信用イベント リスナー スレッドを起動します。

パラメータ:

eventHandlerFP -- アプリケーションのイベント ハンドラに対する関数ポインタ

eventTypes -- イベント タイプの文字列

戻り値:

1: 成功

< 0: 失敗

int EEMDeregister()
 

イベント受信を中止します。

戻り値:

1: 成功

< 0: 失敗

int result = EEMRegister( &eventHandler, “cli interface”);
 

Python の EEM API は、Cisco AXP ゲスト OS のディレクトリ /lib/python2.3/eemapi にある eemapi.py にバンドルされています。

 

Python
eemapi.h
 
EEMRegister (void * eventhandlerFP, char *eventTypes)
 

EEM イベントの受信用イベント リスナー スレッドを起動します。

パラメータ:

eventHandlerFP -- アプリケーションのイベント ハンドラに対する関数ポインタ

eventTypes -- イベント タイプの文字列

戻り値:

1: 成功

< 0: 失敗

int EEMDeregister()
 

イベント受信を中止します。

戻り値:

1: 成功

< 0: 失敗

int result = EEMRegister( &eventHandler, “cli interface”);
 

イベント登録

アプリケーションでイベントを扱うには、イベント登録関数またはメソッドを使用します。
イベントを扱う関数およびメソッドについては、C、Java、および Python のところで説明します。それぞれの引数については、 表10 を参照してください。

C の場合、イベント ハンドラはユーザのアプリケーションで定義したコールバック関数です。

Void AppEventHandler (char *eventName, char *eventType, char *eventInfo)
 

Java の場合、イベント ハンドラはユーザのアプリケーションで定義されたクラス、EventHandler クラスのサブクラスです。イベント ハンドラ クラスは、イベントを受信するために、EventHandler クラスのコールバック関数を上書きする必要があります。

public class EventHandler {
public void callback (String eventName, String eventType, String eventInfo);
}
 

Python の場合、イベント ハンドラはユーザのアプリケーションで定義されたクラス、EventHandler クラスのサブクラスです。イベント ハンドラ クラスは、イベントを受信するために ReceiveEvent 関数を上書きする必要があります。

class EventHandler :
def ReceiveEvent (self, eventName, eventType, eventInfo);
 

 

表10 アプリケーション イベント ハンドラの引数

パラメータ
説明

eventName

イベント コンフィギュレーション ファイルのイベント要素の「名前」アトリビュートまたは CLI を使用して指定したイベント名
(『 Cisco AXP User Guide 』の「Registering an Event using the Cisco AXP Service Module」を参照)

eventType

表8 に記載されているイベント タイプ

eventInfo

Cisco IOS EEM によって結果として生成されたストリング event_reqinfo。ストリングはフォーマットされ、イベントに固有です。『 Writing Embedded Event Manager Policies Using Tcl 』の「event_reqinfo」を参照してください。

リモート シリアル デバイス

パッケージ名: axp-vserial.<platform>.<version>.pkg

仮想シリアル ドライバ パッケージによって、アプリケーション サービス モジュール上で動作しているアプリケーションから、Cisco IOS ルータのシリアル ポートに接続された外部 Cisco IOS シリアル デバイスにアクセスできます。したがって、アプリケーションで GPS ロケータなど、シリアル ポートに接続する周辺機器をサポートできます。

Cisco IOS ルータの補助シリアル ポートは仮想化され、Cisco AXP OS でローカル デバイスとして認識されます。Cisco IOS ルータに接続された外部デバイスは、アプリケーション サービス モジュールがホスティングする Linux アプリケーションで、"/dev/tty1"、"/dev/tty2" などの標準ローカル デバイスとして認識されます。したがって、サードパーティのアプリケーションでは、デバイスの位置を特に認識しなくても、ルータの補助シリアル ポートに接続された外部周辺機器を制御できます。アプリケーションでは以下の標準 Linux システム コールを使用して、周辺機器に対するオープン、クローズ、読み取り、書き込みが可能です。それは、open("/dev/vtty1")、read( ) などです。

リバース Telnet セッションは、ライン インターフェイスまたはシリアル インターフェイス(シリアル インターフェイスが非同期モードで設定されている場合)のどちらかに対して確立されます。この Telnet セッションによって、シリアル データ転送が可能になります。

アプリケーションをパッケージ化するときに、axp-vserial.<platform>.<version>.pkg を依存関係として追加する必要があります。

シリアル デバイスを使用するアプリケーションの開発:概要

1. open( )、read( ) などの標準 Linux システム コールを使用して、シリアル デバイスにアクセスするアプリケーションを開発します。


) デバイス名をアプリケーションにハード コーディングする場合("modem"、"gps" など)、デバイス名を書き留めておいてください。アプリケーションが CLI サーバを使用してシリアル デバイスをバインドするときに、このデバイス名を使用します。


int main(int argc, char *argv[]) {
char *dev;
int fd;
if (argc > 1)
dev = strdup(argv[1]);
else
dev = strdup("/dev/modem");
fd = open (dev, O_RDWR | O_NONBLOCK | O_NOCTTY | O_NDELAY);

2. 「パッケージ ツール」を使用してアプリケーションをパッケージ化し、axp-vserial.<platform>.<version>.pkg への依存関係を組み込みます。

3. アプリケーション サービス モジュールにアプリケーションおよびインフラストラクチャ アドオン パッケージをインストールします。アプリケーションとパッケージをいっしょにインストールするか、またはパッケージをインストールしてからアプリケーションをインストールするかのどちらかです。

4. ルータのシリアル ポートにシリアル デバイスを接続し、Cisco IOS CLI を使用してルータ側のデバイスを設定します。「ルータ CLI から設定する手順の概要」で、設定手順の概要を示します。詳細な設定情報については、『 Cisco AXP User Guide 』の「Remote Serial Device Configuration」を参照してください。

ルータ CLI から設定する手順の概要

interface serial0/0/0
physical-layer async
 
line 0/0/0
no exec
transport input telnet
speed 115200
 

physical-layer async を使用して Serial0/0/0 インターフェイスを非同期モードで設定すると、line 0/0/0 インターフェイスが自動的に作成されます。


) ライン インターフェイスの場合、no exec が設定されていることを確認します。


シリアル インターフェイスの設定後、 show line コマンドを実行し、このシリアル インターフェイスに関連付けられたラインに、「int」 カラムのシリアル インターフェイス名が与えられていることを確認します。出力例を示します。

Tty Line Typ Tx/Rx A Modem Roty AccO AccI Uses Noise Overruns Int
* 0/0/0 2 TTY 4800/4800 - - - - - 114 1 0/0 Se0/0/0
 

5. Host-Router 上で SASL を設定することも必要です。

ホスト ルータ上で次のコマンドを入力し、SASL プロファイルを作成します。

sasl profile javalin
mechanism anonymous
 

6. ホスト ルータおよびサービス モジュールの両方で netconf を設定し、シリアル デバイスの CLI が動作するようにします。例

ホスト ルータ上で次のコマンドを入力します。

netconf max-sessions <4-16>
netconf beep listener <port to listen on> sasl <SASL profile to use for this session>
 

サービス モジュール インターフェイス上で次のコマンドを入力します。

netconf beep initiator <IP address of destination> <port>
netconf max-sessions <4-16>
 

7. サービス モジュール インターフェイス上:

show device serial
 

Cisco IOS シリアル インターフェイスに割り当てられているデバイス名が表示されます。

出力例を示します。

Device Name TTY No. Line No. Line Type Intf Name Assigned To
vaux 1 1 AUX - - -
vtty000 0/0/0 2 TTY Se0/0/0 - -
 

show device serial コマンドを実行しても出力が得られない場合は、「トラブルシューティング:show device serial」を参照してください。

8. アプリケーション サービス モジュール上でアプリケーション サブコマンド コンフィギュレーション モード:

bind serial <device name defined in host> <device name for the hosting environment>
 

アプリケーションの仮想インスタンスにデバイスがバインドされます。

<device name for the hosting environment> は任意のデバイス名です。

任意のデバイス名を指定した場合は、アプリケーションの仮想インスタンスの /dev ディレクトリに、その名前がエントリとして作成されます。

任意のデバイス名を指定しなかった場合は、アプリケーションの仮想インスタンスの /dev ディレクトリに、vtty000 のような実際のデバイス名が作成されます。

前のステップ 1 のように、デバイス名がアプリケーションにハード コーディングされている場合は、任意のデバイス名を使用すると便利です。デバイス名として「/dev/gps」を使用して GPS 用のアプリケーションを作成する場合は、次のように入力すると、シリアル インターフェイスをバインドできます。

bind serial <device name defined in host> gps
 

アプリケーションの仮想インスタンスに「/dev/gps」エントリが作成されます。アプリケーションは、ホスト ルータに接続された GPS デバイスにアクセスできます。

アプリケーションはこれで、(ホスト ルータ上の)外部デバイスをローカル シリアル ポートの場合と同様に制御できます。

シリアル デバイスにアクセスするアプリケーションの例については、「リモート シリアル デバイス:例」を参照してください。

トラブルシューティング:show device serial

コマンド show device serial を実行しても出力が表示されない場合は、ルータおよびサービス モジュールで NETCONF over BEEP が正しく設定されているかどうかを確認します。

ルータ上では、次の 2 種類のデバッグ コマンドのうち、どちらか 1 つを実行できます。

show processes | include beep

show processes | include NETCONF

NETCONF over BEEP が正しく設定されている場合は、どちらかのコマンドがプロセスを返します。

Perl

パッケージ名: axp-perl-5.8.8.<platform>.<version>.pkg(axp-perl-5.8.8.nme.1.0.1.pkg など)

Perl はインフラストラクチャ アドオン パッケージとしてサポートされます。Version 5.8.8 は安定しています。 www.perl.org からソース パッケージをダウンロードしてください。パッケージはマルチスレッド サポートが組み込まれていて、ithread を使用します(各スレッドに Perl Interpreter が 1 つずつ)。Perl パッケージはディレクトリ /isr/local(デフォルトのディレクトリ)の仮想インスタンス下にインストールします。Perl のサンプル ソース コードおよびチュートリアルについては、
www.perl.org にアクセスしてください。

開発システムの要件

アプリケーションは Linux 環境で開発する必要があります。最小限のシステム要件は、次のとおりです。

Intel Pentium 4 CPU 1.8 GHz、40 GB ハードディスク、および 512 MB メモリ

C コンパイラ:GNU C Compiler(gcc)Version 3.4.3

Fedora Core 4 以上などの Linux ディストリビューション

前提条件

Cisco AXP SDK をインストールする前に、次の作業について、『 Cisco AXP User Guide 』を参照してください。


ステップ 1 ルータおよびアプリケーション サービス モジュールを設置します。『 Cisco Network Modules Hardware Installation Guide 』を参照してください。

ステップ 2 Cisco IOS イメージのバージョン 12.4(15)T3 をダウンロードし(詳細については、『 Cisco AXP User Guide 』の「Software Requirements」を参照)、ルータを設定します。

ステップ 3 起動後、サービス モジュール インターフェイスを設定します(『 Cisco AXP User Guide 』の「Configuring the Cisco AXP Service Module Interface」を参照)。Cisco AXP はサービス モジュールにロード済みです。


 

開発フロー

開発フローは、図7 に示したアプリケーション開発の主要フェーズから構成されます。このフローから、サービス モジュール用のアプリケーションを開発する場合の、主要ステップの概要がわかります。

図7 アプリケーション開発フロー

 

アプリケーション開発フローの各ステージについて説明します。


ステップ 1 アプリケーション ソフトウェアの準備

a. ワークステーションを設定します。

Linux オペレーティング システムで、最終的なサービス モジュール ランタイム環境に対応する同様なソフトウェア コンポーネントが組み込まれた PC を使用します。「アプリケーションの作成」を参照してください。

b. Cisco Download Software Area から Cisco AXP SDK をダウンロードします。

Cisco AXP サービス モジュールに Cisco AXP ソフトウェアがすでにロードされている場合は、Cisco AXP ソフトウェアと同じバージョン番号の SDK をダウンロードします。

c. SDK をインストールして、作業スペースを準備します。

Linux 環境で動作するように、アプリケーション ソフトウェアを準備します。アプリケーション ソフトウェアが置いてあるディレクトリをワークステーションの Linux 環境から切り離しておくことを忘れないでください。シミュレーションのルート ディレクトリ(/opt/ など)に、アプリケーション ソフトウェアを隔離します。このルート ディレクトリの下にあるソフトウェアは、アプリケーション サービス モジュールの仮想環境にロードするときのアプリケーション ソフトウェアと同じセットアップになります。シミュレーションしたルート ディレクトリに、すべてのアプリケーション ソフトウェアおよび必要なライブラリを配置します。組み込みゲスト OS にすでに含まれているライブラリまたはシステム アドオン パッケージは、シミュレーションのルート ディレクトリに含める必要はありません。

各シンボリック リンクの絶対パスを相対パスに変換します。シンボリック リンクは、シミュレーションのルート ディレクトリ下にあるファイルだけを参照します。

ライセンス インストール、サイト/ネットワーキング コンフィギュレーションなど、エンドポイント固有のコードをポストインストール シェル スクリプトに隔離します。コア ソフトウェアは自己完結させ、外部に依存させないことを推奨します。

ステップ 2 初期ソフトウェア パッケージの作成

初期ソフトウェア パッケージは、開発の出発点であり、この段階ではフル機能ではありません。Cisco AXP サービス モジュールにソフトウェアをロードするための準備として、初期パッケージを作成すると、欠落している依存関係を検出したり、ソフトウェアをカスタマイズしたりできるので便利です。

a. ワークステーションの同期リポジトリで、実行可能ファイル、スクリプトなど、必要なソフトウェアの追加または変更を行います。

同期リポジトリには、ソース ファイルではなくバイナリ ファイルを格納します。

b. Linux シェルにアクセスできるようにします。

Linux シェルにアクセスすると、Cisco AXP サービス モジュールにアプリケーション ソフトウェアをロードしたあとで、ソフトウェアをデバッグできます。「ポストインストール スクリプトを使用するコンソール アクセス」を参照してください。

c. 必要なシスコのインフラストラクチャ パッケージに対するアプリケーション ソフトウェアの依存関係を定義します。

d. アプリケーションが依存するシスコのインフラストラクチャ パッケージに、アプリケーション ソフトウェアをバンドルします。

例については、「パッケージ ツールの実行」を参照してください。

ステップ 3 サービス モジュールへのアプリケーションのロード

a. Cisco AXP サービス モジュールにアプリケーション ソフトウェアをロードします。たとえば、2 つの環境間でファイルを同期させる、 rsync ユーティリティを使用して行います。

rsync の詳細については、「rsync」を参照してください。

b. Linux シェルにアクセスできることを確認します。

c. アプリケーション ソフトウェアが必要とするシスコのインフラストラクチャ パッケージからのリンクが設定されたファイル(CLI プラグイン、OSGi TM 、Tomcat ファイルなど)が仮想環境にあることを確認します。

d. 「RPM ファイルの抽出」を参照し、アプリケーションに必要なその他のファイルおよびスクリプトを抽出します。

ステップ 4 アプリケーションのテストおよび開発

a. SFTP または rsync を使用して、脱落しているアプリケーション コンポーネントおよびライブラリ、またはその両方をサービス モジュールにアップロードします。

必要に応じて、サービス モジュール上で対話方式の開発を行います。ただし、ステップ 5 で、変更したソフトウェアをワークステーション環境に同期させることを忘れないでください。

b. 組み込み仮想環境にアプリケーションを統合します。エンド ユーザ インターフェイスの問題を、アプリケーションの設定および診断を含めて考慮します。開発サービス モジュール上の CLI を拡張する場合は、「CLI プラグイン ディストリビューション サービス」を使用します。

c. アプリケーションの機能および安定性をテストします。

(デバッグ ツールの詳細については、アプリケーションのトラブルシューティングおよびアプリケーション開発パッケージを参照)

d. アプリケーション起動スクリプト(複数可)をアップデートしてテストします。

e. アプリケーション ポストインストール スクリプトをアップデートしてテストします。

ステップ 5 開発ワークステーション上でのアプリケーション ソフトウェアのアップデート

サービス モジュール上で変更したアプリケーション ソフトウェアを開発ワークステーションにコピーして戻します。たとえば、 rsync CLI コマンドを使用します。

インフラストラクチャおよび組み込みゲスト OS のコンポーネントをアプリケーション ソフトウェア リポジトリにコピーしないでください。これはスペースを節約するためです。不必要にファイルをコピーすると、シスコのサービス モジュールにアプリケーションを配置したときに、アプリケーションが占めるストレージ スペースが大きくなってしまいます。

ステップ 6 アプリケーション ソフトウェア実稼働パッケージの作成

a. ワークステーション上で、アプリケーション ソフトウェアの新しいパッケージを作成します。

b. エンド ユーザに必要がない場合は、Linux シェルにアクセスできないようにします。

c. インフラストラクチャの依存関係およびポストインストール スクリプトを指定します。

d. パッケージ化の前に、不要な一時ファイルを削除します。

e. Library Dependency Checker ツールを実行し、アプリケーションが必要とするすべてのライブラリがパッケージに含まれていることを確認します。

f. 必要なシスコのインフラストラクチャ パッケージを含めて、アプリケーション ソフトウェアをバンドルします。

g. パッケージ化されたソフトウェアをインストールしてテストします。


 

Cisco AXP SDK

Cisco AXP は、開発者が Linux 開発環境で使用できる SDK(ソフトウェア開発キット)を提供します。SDK が提供するツールは、次のとおりです。

「パッケージ化およびバンドリング用のツール」

「CLI プラグイン ユーティリティ ツールおよび API」

「付加価値サービス API」

「SDK のインストール」


) 目次に戻るには、ここをクリックしてください。


パッケージ化およびバンドリング用のツール

パッケージ ツール

アプリケーション パッケージを作成して署名するには、パッケージ ツール pkg_build.sh を使用します。このツールを使用するには、アプリケーション サードパーティがシスコから開発許可を得ていて、アプリケーションの署名に使用する秘密鍵にアクセスできなければなりません。このツールには 2 つのインターフェイスがあります。コマンド引数およびインタラクティブ CLI です。詳細については、「パッケージ ツール」を参照してください。

バンドリング ツール

複数のパッケージを集めて 1 つのバンドルにするには、バンドリング ツール pkg_bundle.sh を使用します。詳細については、「バンドリング ツール」を参照してください。

次に、パッケージ化に関連するその他の便利なツールについて説明します。

「Library Dependency Checker」

「Package Information」

「RPM ファイルの抽出」

Library Dependency Checker

Library Dependency Checker ツール(pkg_check.sh)を使用すると、Cisco AXP サービス モジュールにアプリケーションをインストールする前に、ソフトウェアの依存関係を調べることができます。

Library Dependency Checker ツールは、デフォルトの /lib ディレクトリに置かれている、パッケージ化されたバイナリ ファイルの依存関係を調べます。ルート ディレクトリのチェックは行われません。このチェッカー ツールは、依存関係が満たされていないバイナリおよび欠落している対応ライブラリを表示します。「/opt/lib」などのディレクトリのライブラリは、--lib-path 引数を使用して追加していない場合、無視されます。

Library Dependency Checker:例

pkg_check.sh --project-dir '/xyz-src' --check-pkg AppXYZ-1.0.pkg --lib-path '/usr/local/lib:/opt/app/lib' DependencyPkg1.pkg DependencyPkg2.pkg
 

Library Dependency Checker の引数

 

表11 Library Dependency Checker の引数

引数
引数に関連付けられる名前
説明

--help

(引数なし)

バージョンおよび使用情報

--project-dir

プロジェクト ディレクトリ

抽出したパッケージ ファイルの一時保管場所として使用されるプロジェクト ディレクトリ

--check-pkg

チェックするプロジェクト(任意) または ソフトウェアのルート ディレクトリ(任意)

(依存関係を)チェックするパッケージ。対応する .prt1 ペイロード ファイルが同じディレクトリに保管されている必要があります。パッケージ名にはサフィックス .pkg が付きます。

または

ソフトウェアのルート ディレクトリ。アプリケーション ファイルを置きます。


) --check-pkg 引数には、パッケージまたはソフトウェア ルート ディレクトリのどちらかを指定する必要があります。


--lib-path

追加のパス ロケーション

--lib-path 引数を使用すると、デフォルトのライブラリ パス「 /lib 」のほかに、ライブラリ サーチ パス ロケーションを指定できます。ライブラリ パス ロケーションは、コロンで区切る必要があります。「 /usr/lib:/usr/local/lib 」が 1 例です。


) アプリケーションの実行前に、
LD_LIBRARY_PATH に必要なライブラリ ロケーションを追加することも必要です。


--core-sys

コア システム パッケージ

Cisco AXP コア システム パッケージ(フル パス)。アプリケーションの依存関係をコア システム パッケージと比較して調べます。「 axp-k9.nme.1.0.1.pkg 」が 1 例です。

<パッケージ名のリスト>

依存関係パッケージ

リストの各依存関係パッケージには、バイナリの依存関係を満たすためのファイルが含まれます。このリストにサブシステムを指定しなければならないことに注意してください。

Library Dependency Checker:制約事項

Library Dependency Checker ツールで検出できないものは、次のとおりです。

ダイナミックにロードされたプラグイン ライブラリの脱落。バイナリにはこのようなライブラリの連携情報が含まれないからです。

exec 権限が与えられていないバイナリ。

Package Information

Package Information ツール(pkg_info.sh)は、パッケージ情報を表示します。このツールは、SDK の tools ディレクトリにあります。

取得可能な役立つ情報の 1 例は、パッケージの SSID です。パッケージ化するときに SSID を使用して、アプリケーションに依存関係を追加できます。

SSID は、Packaging Tool の deps パラメータで指定されます。

pkg_info.sh の出力が格納されるファイルは、 <ユーザのプロジェクト ディレクトリ>/tmp/core.log です。

pkg_info.sh sanity_test.pkg
 
 
Subsystem ID: d984142e-4dfb-4a28-bf42-60d278b7e798
Name: sanity_test
Version: 1.0
Type: plug-in
Description: Sanity
Content:
/hello.txt (file, not-link, data)
/xterm (file, not-link, executable)
/sbin/.app_sig (file, not-link, data)
 

) Package Information ツール pkg_info.sh が一度に提供するのは、1 つのパッケージに関する情報だけです。



) ディレクトリによっては、パッケージ ツールがサブシステム SSID のほかに、そのパッケージのサブシステムも表示します。サブシステムが表示されるディレクトリは、<SDK Directory>/pkg および <Project Directory>/pkg です。


RPM ファイルの抽出

動作中のアプリケーションの動作がサービス モジュール上で停止することがあります。これを調べるには、手動でアプリケーションを起動します。「手動起動」を参照してください。

<script name> start(/etc/rc.d/init.d の起動スクリプトのコマンドなど)を入力することによって、プログラムを起動します。

ファイルが見つからないというエラー メッセージが表示され、さらに特定の RPM ファイルが必要であるというメッセージも表示された場合は、アプリケーションを正常に動作させるために、インストールする RPM ファイルを識別する必要があります。

脱落ファイルの特定後、次のユーティリティを利用して、脱落している個々の RPM ファイルを追加できます。

「標準 RPM ユーティリティ」

「RPM ファイル抽出ツール」

標準 RPM ユーティリティ

サードパーティのアプリケーションをインストールしたあとで、他のソフトウェアを追加する場合は、rpm、rpm2cpio などの標準 RPM ユーティリティを使用します。サービス モジュール上のアプリケーションのゲスト OS シェルにアクセスする必要があります。

RPM ファイルを抽出する手順は、次のとおりです。

1. 開発マシン上で rpm2cpio ユーティリティを実行します。

2. 開発マシンから FTP サーバにファイルをアップロードします。

3. curl ユーティリティを使用して、FTP サーバからクライアント(サービス モジュール)にダウンロードします( http://curl.haxx.se/docs/manpage.html を参照)。curl ユーティリティは HTTP/FTP サーバからファイルをダウンロードします。

アプリケーションの一部として RPM ファイルをインストールする手順は、次のとおりです。詳細については、「RPM File Extractor ツール」を参照してください。


ステップ 1 開発環境から RPM ファイルを抽出します。

現在のディレクトリに RPM ファイルを抽出します。

rpm2cpio /tmp/myapp.rpm | cpio -ivd
 

ステップ 2 インストール/アンインストール スクリプトおよび依存関係を検証します。

RPM ファイルを含むプリインストールまたはポストインストール/アンインストール スクリプトを検証するには、次のように、RPM ファイル抽出ツールを使用します。

rpm -qp --scripts /tmp/myapp.rpm
 

RPM に必要な依存関係(ライブラリ、またはその他の RPM ファイル)を調べるには、次のように、RPM ファイル抽出ツールを使用します。

rpm -qp -R /tmp/myapp.rpm
 

「RPM File Extractor ツール」を参照してください。

ステップ 3 スクリプトを検証し、必要なものを Cisco AXP モデルにフィットさせます。


 

RPM ファイル抽出ツール

RPM ファイル抽出ツール(tools/rpm_extractor.sh)は、Cisco AXP SDK の一部です。このツールは、すべての RPM ファイルをプロジェクト ソース ルート ディレクトリに迅速に抽出します。ルート ディレクトリから、RPM ファイルに必要な依存関係の有無を調査し、RPM に含まれているプリインストール、ポストインストール、またはアンインストール スクリプトを表示できます。

詳細については、「RPM File Extractor ツール」を参照してください。

CLI プラグイン ユーティリティ ツールおよび API

Cisco AXP は、Cisco AXP CLI 環境に CLI アプリケーションを統合するためのメカニズムを提供します。

開発中は CLI プラグインの検証、処理、およびメイン アプリケーションとのパッケージ化に、一連のツールを使用できます。

付加価値サービス API

サービス API によって、Cisco IOS の既存機能のアクセス、管理、および増加をプログラムで行うことができます。Cisco AXP SDK にはライブラリ、API、および関連ヘッダー ファイルが含まれています。SDK を使用すると、開発環境でアプリケーションをコンパイルする、アプリケーションをリンクする、またはその両方を行うことができます。

付加価値サービス API を入手するには、「インフラストラクチャ アドオン パッケージ」から必要なパッケージをインストールします。付加価値サービス API に依存するアプリケーションをパッケージ化するときには、相当するインフラストラクチャ アドオン パッケージへの依存関係を指定する必要があります。

ユーザのアプリケーションでサービスを使用できるようにするには、インフラストラクチャ アドオン パッケージとユーザのアプリケーション パッケージの両方をサービス モジュールにインストールする必要があります。

SDK のインストール

SDK には、ディレクトリおよびファイルが含まれています。 表12 を参照してください。

 

表12 Cisco AXP SDK のディレクトリおよびファイル

ディレクトリ/ファイル
説明

include

CLI ディストリビューション ヘッダー ファイル

jar

CLI ディストリビューション jar ファイル

lib

パッケージ、バイナリ、およびスクリプトのサブディレクトリ

perl

Perl モジュール ファイル

python2.3

Python モジュール ファイル

tools

アプリケーションのパッケージ化およびバンドル ツール

Cisco AXP SDK をインストールする手順は、次のとおりです。


) SDK のディレクトリ名は、ソフトウェア リリースによって異なります。後ろの手順で、ファイル名 axp-sdk.<package>.tar.gz は、x.y.z の値がバージョン 1.0.1 を意味する「1.0.1」のファイルを参照します。



ステップ 1 Cisco Download Software Area (または
https://upload.cisco.com/cgi-bin/swc/fileexg/main.cgi?CONTYPES=PCBU-Misc )から SDK ファイル axp-sdk.<package>.tar.gz をダウンロードします。

ステップ 2 SDK 用のディレクトリを作成します。

mkdir -p /source/sdk
 

ステップ 3 SDK ディレクトリに SDK ファイルの内容を抽出します。

tar xvzf axp-sdk.x.y.z.tar.gz -C /source/sdk
 

これで SDK がインストールされます。


 

アプリケーションの開発

次に、アプリケーションの開発について説明します。

「CLI プラグイン アプリケーション」も参照してください。

「アプリケーションの作成」

「自動または手動によるアプリケーションの起動」

「アプリケーションのパッケージ化」

アプリケーションの作成、テスト、パッケージ化

通常、開発プロセスの最初のステップは、Linux 開発環境で起動/シャットダウン スクリプトとともにアプリケーションを作成することです。アプリケーションが正常に動作することをテストしたあとで、アプリケーションおよび関連スクリプト、抽出した RPM ファイル、その他の必要なファイルをビルド ディレクトリにコピーします。その後、パッケージ ディレクトリを作成し、Cisco AXP ツールを実行して、Cisco AXP システムにインストールできるようにアプリケーションをパッケージ化します。

証明書

Cisco AXP にアプリケーションのインストール前に、アプリケーションをパッケージ化するときに、いくつかの手順があります。必須手順の 1 つは、アプリケーションの署名入り証明書を作成することです。Cisco AXP にインストールするアプリケーションには、署名入り証明書、秘密鍵、およびシスコが提供した開発許可証明書が必要です。詳細については、「証明書の作成」を参照してください。さらに、アプリケーションの OS シェルに対するアクセス許可およびファイルの保護を検討します。

シェル アクセスおよびセキュリティ

Cisco AXP にインストールした各アプリケーションは、専用の仮想インスタンスを使用します(Cisco Application eXtension Platform の概要も参照)。インスタンス内で、アプリケーションに専用のシェルおよび環境が与えられます。プログラムの特定ファイルをデバッグ、変更、表示、または他のアプリケーションやツールをインポートするには、ゲスト OS シェルにアクセスします。しかし、ユーザにシェルへのアクセスを許可すると、アプリケーションのセキュリティ リスクが増します。ゲスト OS シェルへのアクセスについては、「アプリケーションのパッケージ化」を参照してください。

アプリケーション環境へのシェル アクセスをだれかに許可する場合、特定のファイルが変更されたり削除されたりしないように、保護しなければならないことがあります。ファイルの保護については、「保護ファイルのファイル作成」を参照してください。指定したファイルのいずれかが変更または削除された場合、アプリケーションの仮想インスタンスが次回、再起動を試みるときに、変更または削除が報告され、仮想インスタンスは起動しません。これにより、アプリケーションの実行が防止されます。変更または削除されたファイルの名前を記したメッセージがシステム ログに書き込まれます。

アプリケーションの作成

アプリケーションは Linux 開発環境で作成してテストした後に、Cisco AXP にインストールします。

Cisco AXP は Cisco Linux に準拠しています。ライブラリの一覧については、付録を参照してください。アプリケーションのすべての追加コード機能を Cisco AXP にインポートする必要があります。このコードに含まれるものは、セットアップおよび kill スクリプト、これらのスクリプトへのソフトリンク、およびその他の必要な RPM です。

show state cli コマンドでアプリケーションのヘルス ステータスを表示できるように、アプリケーションにヘルス ステータスをコーディングすることを推奨します。


) 仮想インスタンスの /tmp ディレクトリのサイズは、16 MB に制限されています。


アプリケーションがコンソールにアクセスできるようにするには、ポストインストール スクリプトを使用するか、またはアプリケーションをデバッグ パッケージ axp-app-dev.<platform>.<version>.pkg に依存させる必要があります。
ポストインストール スクリプトおよびデバッグ パッケージの詳細については、「アプリケーションのコンソール アクセス権の取得」を参照してください。

C アプリケーション

Cisco AXP 上で動作させるネイティブ C/C++ ソフトウェアを開発する場合は、次のコンポーネントの使用を推奨します。

コンパイラ GCC/G++ 3.4.4

ライブラリ glibe: 2.3.5

ライブラリ libstdc++: 6.0.3

Fedora 6 C/C++ アプリケーションは、次のどちらかのリンカー オプションとリンクさせる必要があります。

-Xlinker -hash-style=sysv

-Xlinker -hash-style=both

Hello World アプリケーション:例

次に、単純な「Hello World」 アプリケーションのコード例を示します。

アプリケーションは Bash スクリプトであり、fancy_output というファイルに書き込むことによって、5 秒間隔でヘルス ステータスを報告します。


ステップ 1 次のコマンドを使用して、Bash スクリプトを保存するディレクトリを作成します。

mkdir /source/helloworldapp
 

ステップ 2 次のライン コードを含む helloworld.sh というスクリプトを作成します。

#!/bin/bash
#provide health status
/bin/app_status_notifier helloworld INITIALIZING
# remove old log file
rm -rf fancy_output
#provide health status
/bin/app_status_notifier helloworld ALIVE
while [ 1 ]; do
echo "Hello world!" >> fancy_output
sleep 5
done
 

ステップ 3 helloworld.sh をディレクトリ /source/helloworldapp に保存します。

ステップ 4 (任意)ゲスト OS シェルにアクセスしないで、fancy_output ファイルを表示する方法は 2 通りあります。

2 つのうち、どちらか一方の手順を選択します。

ディレクトリ /var/log/ の fancy_output ファイルに書き込みます。例を示します。

echo “Hello world!” >> /var/log/fancy_output
 

fancy_output ファイルのディレクトリから、ディレクトリ /var/log/ で作成するファイルへのソフトリンクを作成します。たとえば、ポストインストール スクリプトに次の行を追加します。

touch /var/log/fancy_output
ln -s /var/log/fancy_output /helloworld/fancy_output
 

fancy_output ファイルがディレクトリ /helloworld に書き込まれます。Cisco AXP では、/var/log ディレクトリからユーザのファイルへのソフトリンクを作成することはできません。セキュリティ違反につながる可能性があるからです。

ステップ 5 (任意)ゲスト CLI からファイルを表示します。

show log name <your file name>
 


 

自動または手動によるアプリケーションの起動

アプリケーションは、次のうちのどちらかの方法で起動します。

「自動起動」

「手動起動」

自動起動

Cisco AXP のブート時に自動的に起動する場合は、通常、/etc/rc.d/init.d で起動スクリプトを作成し、/etc/rc.d/rc3.d ディレクトリに置いたソフトリンクでそのスクリプトを参照します。起動ソフトリンクのフォーマットは S<priority><app-name> にする必要があります。この場合、S は起動、priority は 0 ~ 99、app-name はコールする起動スクリプトの名前です。

起動スクリプトを参照する kill ソフトリンクを作成し、/etc/rc.d/rc6.d ディレクトリにスクリプトを置きます。kill ソフトリンクは次のフォーマットにする必要があります。

K<priority><app-name> 。この場合、K は kill、priority は 0 ~ 99、app-name は起動スクリプトの名前です。

起動スクリプトに対するこれらのソフトリンクおよび参照とともにアプリケーションをパッケージ化し、Cisco AXP にインポートします。

手動起動

手動起動の場合、最初に、シェル アクセスできるようにシステムを設定します。詳細については、「アプリケーションのコンソール アクセス権の取得」を参照してください。

共通ルート ディレクトリの作成

/source/helloworldapp/build のような共通ルート ディレクトリを作成します。

これは共通ルート ディレクトリであり、このディレクトリからパッケージを作成して Cisco AXP にインストールします。

ファイルのコピー

/etc/rc.d/rc3.d および /etc/rc.d/rc6.d にある起動ソフトリンクおよび kill ソフトリンクを、ディレクトリ構造はそのままにして、共通ルート ディレクトリにコピーします。

参照するスクリプト /etc/rc.d/init.d を共通ルート ディレクトリにコピーします。

その他、アプリケーションに必要なすべてのファイルおよびリンクを共通ルート ディレクトリにコピーします。

Hello World ビルド ディレクトリ:例

この例では、共通ルート ディレクトリは /source/helloworldapp/build です。

共通ルート ディレクトリの下のサブディレクトリは、次のとおりです。

./bin:
post-install.sh
 
./etc/rc.d/init.d:
helloworld
 
./etc/rc.d/rc3.d:
S99helloworld -> ../init.d/helloworld
 
./etc/rc.d/rc6.d:
K99helloworld -> ../init.d/helloworld
 
./helloworldapp:
hello_world.sh
 
./sbin:
 

保護ファイルのファイル作成

ユーザにゲスト OS シェルへのアクセスを許可する場合は、ファイルが変更されないように、任意でファイルを保護することができます。起動スクリプト、kill スクリプト、helloworld、およびプロセス スクリプト helloworld.sh が対象になります。ファイル保護は、保護するファイルのリストを指定したファイルを作成することによって行います。

protect.txt という、保護ファイル リストを指定したファイルを作成します。各ファイル名の前に、必要なファイル パスがあれば組み込みます。


) protect.txt ファイルでは、1 行に指定するファイルは 1 つだけです。


パッケージ化するときに、protect.txt で指定された各ファイルでチェックサムが実行され、結果がパッケージとともに保管されます。仮想インスタンスが起動すると、チェックサムと比較して保護ファイルが検証され、ファイルの整合性が保証されます。

保護ファイルのリスト:例

/etc/rc.d/init.d/helloworld
/helloworldapp/helloworld.sh

証明書の作成

開発者の証明書は、VeriSign などの信頼できる認証局が署名した X.509 証明書です。証明書要求を作成して、署名入り証明書を取得する手順については、認証局に問い合わせてください。認証鍵には RSA 公開鍵暗号方式を使用し、1024 ビット以上の鍵長にすることを推奨します。


ステップ 1 2 つのオプションのうち、どちらか一方を選択します。

認証局から X.509 証明書を取得します。または

自己署名の X.509 証明書を作成します。手順は、次のとおりです。

OpenSSL ツールを使用して、自己署名入りの X.509 証明書を作成します。RSA 鍵のペアを作成します。結果として生成される秘密鍵のファイルに、秘密鍵が含まれます。

openssl genrsa -out private.key 1024

1 年間有効な自己署名入り X.509 証明書を作成します。

openssl req -new -x509 -days 365 -key private.key -out dev_certificate.sig


) 開発者証明書の名前は、dev_certificate.sig とする必要があります。


ステップ 2 開発者証明書をシスコに送信します。

ステップ 3 開発者証明書が承認されると、シスコから許可証明書 dev_authorization.sig が返却されます。

ステップ 4 ディレクトリが存在しない場合は、ディレクトリ /source/certs を作成します。

ステップ 5 許可証明書を秘密鍵のファイルを含め、ディレクトリ /source/certs に移します。

その後、アプリケーションをパッケージ化するときに、証明書と秘密鍵ファイルを含めます。


 

プロジェクト用パッケージ ディレクトリの作成

プロジェクト用のパッケージ ディレクトリを作成します。このディレクトリは、Cisco AXP にインストールするパッケージ ファイルに使用されます。例を示します。

mkdir /source/helloworldapp/package

パッケージ ツールの実行


) パッケージ ツールでは、バージョン 3.0 以上の Bash スクリプトが想定されます。



ステップ 1 axp-sdk.1.0.1/tools にある SDK パッケージ ツール pkg_build.sh を実行します。

このパッケージ ツールでは、パラメータを指定するか、しないかを選択できます。

ファイルのパラメータを指定する場合は、「パッケージ ツール」のリストのようなパラメータ リストを使用します。

対話方式でパラメータを指定する場合は、pkg_build.sh. を入力します。

パッケージ ツールがインタラクティブ モードになり、各パラメータ項目の入力を求めるプロンプトが表示されます。「Hello World アプリケーションのパッケージ化:例」を参照してください。

パッケージは、ファイル システムのどこからでも作成できます。

ステップ 2 (任意)ポストインストール スクリプトを実行します。スクリプトはインストール後、アプリケーションの初回起動までに実行します。

共通ルート ディレクトリに対する相対パスを使用して、スクリプトの場所を指定します。たとえば、スクリプト postinstall.sh がディレクトリ /source/build/bin にあり、共通ルート ディレクトリが /source/build の場合、スクリプトの場所を /bin/postinstall.sh に指定します。


 

Hello World アプリケーションのパッケージ化:例

パッケージ ツール pkg_build.sh をインタラクティブ モードで使用して、Hello World アプリケーションをパッケージ化する例を示します。パッケージ ツールのモードおよびパラメータについては、「パッケージ ツール」を参照してください。パッケージ化したあとで、アプリケーションをインストールします。「アプリケーションのインストール、アンインストール、およびアップグレード」を参照してください。

インタラクティブ モードでは、各パラメータの入力を指示するツール プロンプトが表示されます。パラメータ **project-dir が最初です。

1. プロジェクト ディレクトリ パラメータの説明が表示されます。

2. 「Project Directory:」というプロンプトが表示されます。

3. プロジェクト ディレクトリ名をパスとともに入力します。例を示します。

/source/helloworldapp/package
 

次のパラメータ ** dev-cert が表示されます。

パッケージ ツール:例


) この例では、** uuid など、任意のパラメータはブランクにしてあります。


**project-dir
Used to store output packages as well as any intermediary files, for example manifest files. Project directory must be readable and writable.
Project Directory: /source/axp_tools/axp-sdk.1.0.1/tools/pkg_build.sh
 
** dev-cert
Development certificate will be used to verify software package integrity during installation and runtime (if the feature is enabled). The certificate must be in X.509 format. Development certificate must be authorized for development on this platform. Please contact Cisco for information on development authorization.
 
Development Certificate File: /source/helloworld_app/certs/dev_certificate
 
** dev-auth
Development authorization verifies that development certificate can be used for software development. Development authorization contains cryptographic signature of development certificate. Please contact Cisco if you need to obtain a development authorization file for your development certificate.
 
Development Authorization File: /source/helloworld_app/certs/dev_authorization
 
** private-key
Private key in this file is used to sign application package files. The public key corresponding to this private key must be stored in development certificate.
 
Private Key for Signing Operations: /source/helloworld_app/certs/private.key
 
** name
 
Name of the application to be packaged: used to identify application through the command line interface(CLI) as well as for naming package files.
 
Application Name: helloworld
 
** version
Application version is used when displaying application information through command line interface. It is also used for upgrade/downgrade sequencing.
 
Version: 1.0
 
** description (optional)
Application description is used when displaying application information through command line interface. For example it may contain a statement about application's capabilities.
 
Description: hello hello
 
** uuid (optional)
Unique identifier to be used with this application. The identifier can be generated using Linux 'uuidgen' utility. Automatically generated if left blank.
 
Unique Identifier:
Using Default Value:
 
** source-dir
Source directory containing the files to be packaged. Files must be laid out in the same as they will appear in the root file system when the files are installed in the application hosting environment.
 
Source Directory: /source/helloworld_app/build
 
** protect (optional)
File that contains a list of application files to be protected. All files listed in this file will be verified during system startup. No application files will be if this parameter is left blank.
 
Protect List File:
Using Default Value:
 
** enable-license (optional)
Enables application licensing: the application will not start if the license for the application is not present.
 
Default Value: FALSE
Enable Application Licensing (y/n): n
 
 
** deps (optional)
Application may depend on one or more components outside of its own
package. Dependencies are specified based on application's unique
identifiers. This tool can lookup application unique identifiers
for packages in '/pkg' and '/pkg' directories.
If this option is not specified the application will have no
dependencies
 
Loading existing SLIM Packages in directories:
/source/sdk/tools/../pkg
/source/helloworldapp/package/pkg
 
Dependency Subsystem Identifier:
 
** disk-limit
disk limit option specifies the minimum disk space allocated
for the application. When disk resource falls below this limit, the
application will not be allowed to install. Minimum disk limit must be
specified in megabytes, for example 1500M.
 
Disk Limit: 10M
 
** memory-limit
Memory limit option allocates RAM space for the application.
Memory limit must be specified in megabytes, for example 256M
Memory Limit: 64M
 
** cpu-limit
CPU limit option specifies the minimum amount of cpu resource
allocated for the application. When the cpu resource falls below this
limit, the application will not be allowed to install.
This option is uniform across supported platforms so the same package
can be installed on any of the supported platforms of the same CPU
architecture. Please refer to developer's guide for the information on
how to calculate CPU limit
 
Cpu Limit: 1000
 
** postinstall (optional)
Postinstall script is executed after installation is complete but before
the application has been started for the first time. Postinstall script
must be packaged with the application. When entering postinstall script
location, use relative path with respect to source tree directory.
 
Post-install script path: bin/post-install.sh
 
Interactive mode complete. Resulting CLI command:
 
------------------
/source/axp_tools/axp-sdk.1.0.1/tools/pkg_build.sh --project-dir '/source/helloworld_app/package' --dev-cert '/source/helloworld_app/certs/dev_certificate.sig' --dev-auth '/source/certs/dev_authorization.sig' --private-key '/source/certs/private.key' --name 'helloworld' --version '1.0.1' --description 'hello hello' --source-dir '/source/helloworld_app/build' --disk-limit '10M' --memory-limit '64M' --cpu-limit '1000' --postinstall 'bin/post-install.sh'
-------------------
 
Press enter to continue...
 
SLIM packaging core log file saved to: /source/helloworld_app/package/tmp/core.log
Renaming helloworld.pkg -> helloworld.1.0.pkg
 

ヒント 上記の「Resulting CLI コマンド」を保存しておくと、今後のパッケージ化用スクリプト ファイルの土台として使用できます。


アプリケーションのインストール、アンインストール、およびアップグレード

ここでは、アプリケーションのインストール、アンインストール、およびアップグレードについて説明します。

「アプリケーションのインストール」

「アプリケーションのアンインストール」

「アプリケーションのアップグレード」

「アプリケーションのインストールおよび動作の確認」


) 目次に戻るには、ここをクリックしてください。


アプリケーションのインストール

ここでは、ソフトウェア パッケージまたはバンドルのインストール方法について説明します。

「インストール コマンド」

インストール コマンド

アプリケーションと Cisco AXP ホスト OS が含まれるバンドル、またはシスコのインフラストラクチャ アドオン パッケージと Cisco AXP ホスト OS が含まれるアプリケーションをインストールする場合は、 software install clean コマンドを使用します。クリーン インストール後は、スタートアップ コンフィギュレーションが工場出荷時のデフォルトに戻ります。結果は write erase コマンドの場合と同様です。

ユーザのアプリケーションが含まれるバンドル、またはシスコのインフラストラクチャ アドオン パッケージが含まれるアプリケーションをインストールする場合は、 software install add コマンドを使用します。

ftp ディレクトリからのパッケージ インストール

a)ftp anonymous ディレクトリ または b)non-anonyous ftp ディレクトリを使用してパッケージをインストールするには、次のコマンドのどちらかを使用します。

a. software install add url url

anonymous ftp ディレクトリの場合。url の例は ftp://<server>/helloworld.nme.1.0.1.pkg です。

b. software install add url url username username password password

non-anonymous ftp ディレクトリ(ユーザ名およびパスワードが必要)の場合。 url の例は ftp://<server>/<dir>/helloworld.nme.1.0.1.pkg です。


) パッケージのインストール後、システムがリブートします。


アプリケーションのアンインストール

アプリケーションをアンインストールするには、サービス モジュール上で次のコマンドを入力します。

software uninstall

表示されたメニューから、削除するサブシステムを選択します。

アプリケーションに割り当てられていたリソースが Cisco AXP ホスト OS によって解放され、回収されます。

アプリケーションのアップグレード

Cisco AXP インストーラは、シスコが開発したインフラストラクチャ アドオン パッケージのアップグレード、およびサードパーティが開発したインフラストラクチャ アドオン パッケージのアップグレードをサポートします。

「any-to-any」と記されているアップグレードは、アプリケーションの任意のバージョンから任意の他のバージョンにアップグレードできるという意味です。同じ名前で古いパッケージを新しいパッケージに完全に置き換える必要があります。アップグレード後、システムの起動時に、保存されていたスタートアップ コンフィギュレーションが復元されます。

アドオンをアップグレードする場合は、『 Cisco AXP User Guide 』の「Installing and Upgrading Software」を参照してください。次に、主要なアップグレード コマンドの要約を示します。

パッケージがブレードにダウンロード済みの場合:

software install upgrade <pkg file name>

匿名のユーザ名で ftp を使用して URL からダウンロードする場合:

software install upgrade url <url>

ユーザ名およびパスワードを指定して ftp を使用し、URL からダウンロードする場合:

software install upgrade url <url> username <username> password <password>

Cisco AXP は、アプリケーションの下位バージョンへのアップグレードをサポートします。このアプリケーションの「ダウングレード」とは、インストールするアプリケーションまたはパッケージのバージョンが、現在のアプリケーション バージョンより下位であることを表します。

アプリケーションのインストールおよび動作の確認

helloworld アプリケーションがインストールされているかどうかを確認するには、次のコマンドを入力します。


ステップ 1 app-service ?

アプリケーションがインストールされている場合は、リストにアプリケーションが示されます。

ステップ 2 app-service helloworld

アプリケーションが動作している場合は、ゲスト OS シェルの CLI が使用できます。

ステップ 3 show processes

プロセス リストにアプリケーションが含まれます。例として、helloworld などです。

ステップ 4 (任意) show state

プロセスとその状態が表示されます(アプリケーションにヘルス ステータスがプログラミングされている場合)。

APPLICATION STATE HEALTH
helloworld online ALIVE
 


 

CLI プラグイン アプリケーション

Cisco AXP CLI プラグインを使用すると、アプリケーション固有のコマンドを作成して、Cisco AXP CLI ですでに使用可能なコマンドに追加できます。

次に、最初の項目 5 つで、CLI プラグイン アプリケーションの開発方法について説明します。

「CLI プラグイン ディストリビューション サービス」

「CLI プラグイン アプリケーションのコンポーネント」

「CLI プラグイン アプリケーションのパッケージ化」

「CLI プラグイン アプリケーションのインストール」

「CLI プラグイン アプリケーションのアクティベーション」

「XML DTD ファイル」

「CLI プラグインの呼び出し」

「CLI プラグイン アクション API」

「no プレフィクスのサポート」

「CLI プラグイン ディストリビューション リスナー API」

「CLI プラグイン エラー」

「アクション呼び出しの割り込み」

「CLI プラグインの同時呼び出し」

「CLI プラグインのプレパッケージ」

「CLI プラグイン アプリケーション:例」


) 目次に戻るには、ここをクリックしてください。


CLI プラグイン ディストリビューション サービス

Cisco AXP CLI プラグイン ディストリビューション サービス
(axp-cli-plugin.<platform>.<version>.pkg)は、Cisco AXP CLI サーバからユーザのアプリケーションに、CLI プラグインを配布するために必要なライブラリを提供する、インフラストラクチャ アドオン パッケージです。詳細については、「インフラストラクチャ アドオン パッケージ」を参照してください。

CLI プラグイン アプリケーションのコンポーネント

表13 に、Cisco AXP にコマンドを組み込むために必要な、CLI プラグインのコンポーネントを示します。

 

表13 CLI プラグイン アプリケーションのコンポーネント

CLI プラグイン
コンポーネント
説明

XML 定義ファイル

ユーザが入力するコマンドの構文を定義します。コマンドの XML は、「XML DTD 定義」のData Type Definition(DTD)に準拠する必要があります。

アクション クラス

ユーザが XML 定義ファイルで定義されている CLI コマンドを入力したときに実行される Java クラス、C クラス、または Bash スクリプト


) CLI プラグイン アクションは、対応する CLI プラグイン アプリケーション(ディストリビューション リスナー)と同じ言語にする必要があります。


Java:Java を使用してアクション スクリプト(クラス)を作成する場合は、クラスを <action name>.class にコンパイルします。

C:C を使用してアクション スクリプト(クラス)を作成する場合は、クラスを <action name>.so という共有ライブラリにコンパイルします。

Bash:Bash シェル スクリプト <action name>.sh を使用してアクション スクリプトを作成した場合は、終了ステータスを示す整数値だけが戻ることに注意してください。CLI コンソールで表示するためのメッセージは戻りません。

アプリケーション

ユーザ コマンドを受信する CLI VM スレッド
startCLIDistributionVMThread
を起動します。ユーザが入力した CLI コマンドをスレッドが受信して応答できるのは、アプリケーションが実行中の場合に限られます。

ユーザが XML 定義ファイルで定義されている CLI コマンドを入力すると、 startCLIDistributionVMThread が対応するアクション クラスを呼び出します。

図8 に、 show time コマンドを処理するように設定された 3 種類の CLI プラグイン コンポーネントを示します。

図8 Cisco AXP CLI プラグイン サービス

 

CLI プラグイン アプリケーションのパッケージ化

CLI プラグインを事前にパッケージ化したファイルが /source/showtime/build ディレクトリにコピーされていることを確認します。例については、「CLI プラグインのプレパッケージ:例」を参照してください。CLI プラグインの事前パッケージ ファイルが tar ファイルの場合は、パッケージ ディレクトリに抽出します。showtime.tar ファイルを untar するコマンドの例を示します。

tar xvf showtime.tar -C /source/showtimeapp/build
 

「ファイルのコピー」の手順で、アプリケーションをパッケージ化します。

2 つのパッケージング オプションのうち、どちらか 1 つ を選択します。

依存関係としての axp-cli-plugin

Cisco AXP に別途 axp-cli-plugin.<platform>.<version>.pkg をインストールします。

axp-cli-plugin.<platform>.<version>.pkg の SSID の依存関係を指定して、アプリケーションをパッケージ化します(パッケージ ツールを参照)。

Cisco AXP にアプリケーション パッケージをインストールします。

または

アプリケーションにバンドルした axp-cli-plugin

axp-cli-plugin.<platform>.<version>.pkg の SSID の依存関係を指定して、アプリケーションをパッケージ化します(パッケージ ツールを参照)。

「バンドリング ツール」を参照し、アプリケーション パッケージに axp-cli-plugin.<platform>.<version>.pkg をバンドルします。

Cisco AXP にバンドル パッケージをインストールします。

CLI プラグイン アプリケーションのインストール

CLI プラグイン アプリケーションをインストールする手順は、次のとおりです。


ステップ 1 「アプリケーションのインストール、アンインストール、およびアップグレード」を参照してください。

ステップ 2 「アプリケーションのインストールおよび動作の確認」を参照してください。

ステップ 3 「CLI プラグイン アプリケーションのアクティベーション」を参照してください。


 

CLI プラグイン アプリケーションのアクティベーション

CLI プラグイン アプリケーションを呼び出すには、EXEC モードで次のように入力します。

app-service <application name>
 

CLI プラグイン アプリケーションのアクティベーション:例

「show time アプリケーション:例」で、コマンド show time 用のプラグインを作成しました。この CLI プラグインを呼び出すには、次のように入力します。

app-service showtime
 

Cisco AXP サービス モジュール上で現在時を表示するには、次のように入力します。

show time
 

XML DTD ファイル

サードパーティが作成した CLI プラグイン用の CLI コマンドは、XML を使用して定義します。XML は、XML DTD ファイルに準拠する必要があります。DTD ファイルを使用すると、CLI プラグイン アプリケーションを Cisco AXP CLI サーバにプラグインできます。

XML 定義ファイルを使用して CLI コマンドを定義する方法および CLI コマンド用に呼び出される個々のアクション クラスについては、「CLI プラグイン アプリケーション」を参照してください。

この項を理解するには、DTD ファイルの知識が必要です。DTD ファイルの詳細を学ぶ、または知識をリフレッシュするには、 http://www.w3schools.com/dtd/default.asp またはその他の DTD トレーニング情報を参照してください。

DTD の概要

DTD では、要素、アトリビュート、およびエンティティの宣言はいずれも同じように、前に左かぎカッコと感嘆符をつけます。(<!)。感嘆符の後ろは、すべて大文字で記した 3 種類のキーワード、ELEMENT、ATTLIST、または ENTITY です。これらのキーワードで宣言のタイプを指定します。

ELEMENT の構文は、次のとおりです。

<!ELEMENT element-name (child1,child2,...)>
 

child1、child2 は element-name の子要素です。

ATTLIST の構文は、次のとおりです。

<!ATTLIST element-name attribute-name attribute-type default-value>
 

ATTLIST キーワードの後ろには、アトリビュートの定義対象である要素の名前 element-name およびアトリビュート リストが続きます。

発生回数の演算子

ELEMENT の子要素は、上の例では「(child1,child2,...」です。

要素 child1 は、 child1 要素が正確に 1 回だけ発生することを示します。要素の任意性と発生回数の両方を制御するには、次の演算子を使用します。

疑問符(?) -- 要素を省略可能にしますが、反復は認められません。その要素を 1 回だけ使用するか、あるいは、まったく使用しないかのどちらかです。 (child1?) が例です。

プラス記号(+) -- 要素を省略不能かつ反復可能にします。少なくとも 1 回はその要素を使用する必要があります。 (child1+) が例です。

アスタリスク(*) -- 要素を省略可能かつ反復可能にします。その要素を任意の回数だけ使用することも、あるいは、まったく使用しないこともできます。 (child1*) が例です。

要素の選択

かっこで囲み、縦線で区切ることによって、要素の選択肢をネストできます。たとえば、 (e1|e2) は、要素 e1 または要素 e2 のどちらか一方が発生することを示します。

CLI DTD

CLI DTD ファイルは、CLI コマンドを指定する XML のフォーマットを定義するために使用します。Cisco AXP SDK の DTD ファイルは、tools/custom_cli/cli_grammar.dtd にあります。

<?xml version="1.0" encoding="UTF-8" ?>
<!ELEMENT cli_grammar (mode)+>
<!ELEMENT mode (pattern, (cmd)*)+>
<!ELEMENT pattern (#PCDATA)>
<!ATTLIST pattern type (id|regex|help) "id">
<!ELEMENT cmd ((pattern,(help)?), ((param)*),action)>
<!ELEMENT help (#PCDATA)>
<!ELEMENT param (pattern,(help)?)+>
<!ELEMENT action ((class)?, (interrupt-timeout)?)>
<!ATTLIST action
type (default) "default"
paginate (yes|no) "no"
pipehelp (yes|no) "no">
<!ELEMENT class (#PCDATA)>
<!ELEMENT interrupt-timeout (#PCDATA)>
 

cli_grammar

cli_grammar 要素では、CLI XML ファイルの最上位ドキュメント タイプを定義します。すべての CLI XML ファイルは、このドキュメント タイプを宣言し、「cli_grammar.dtd」定義ファイルを指定することによって開始する必要があります。

<!ELEMENT cli_grammar (mode)+>
 

各 cli_grammar 要素は 1 つまたは複数の mode 要素からなります。

<!DOCTYPE cli_grammar SYSTEM "cli_grammar.dtd">
<cli_grammar>
<!-- The contents of the CLI XML file are place here -->
</cli_grammar>
 

mode

<!ELEMENT mode (pattern, (cmd)*)+>
 

1 つまたは複数の mode 要素があります。アプリケーションは XML ファイル内で、最低 1 つは mode 要素を定義する必要があります。 mode 要素は、その後の XML 要素が適用される CLI モードを定義します。

mode 要素には pattern 要素が 1 つとゼロ以上の cmd 要素が含まれます。

pattern 要素には、2 種類のアトリビュート値があります。 exec および config で、2 種類の共通 CLI モードを表します。

mode:例

<cli_grammar>
<!-- Place valid mode elements here -->
<mode>
<pattern type="id">exec</pattern>
...
</mode>
...
<mode>
<pattern type="id">config</pattern>
...
</mode>
 
</cli_grammar>
 

pattern

<!ELEMENT pattern (#PCDATA)>
 

pattern 要素は 1 つで、解析されたキャラクタ データ(#PCDATA)が含まれます。

pattern 要素の解析キャラクタ データは、CLI がトークン照合に使用するネーム ストリングを定義します。 pattern 要素は、CLI XML の 2 種類の要素内で使用されます。

1. mode 要素内の pattern 要素 -- 「CLI モード」を定義します。

2. cmd 要素内の pattern 要素 -- 「CLI トークン ストリング」を定義します。

CLI モード

mode 要素内で定義された pattern 要素の場合、 pattern 要素で指定した名前によって、その後の XML 要素に適用される CLI モードの名前を定義します。次の例では、 pattern 要素を使用して、CLI exec モードを宣言します。

CLI モード:例

<cli_grammar>
<mode>
<pattern>exec</pattern>
<!-- Place additional mode elements here -->
</mode>
</cli_grammar>

CLI トークン ストリング

pattern 要素は cmd 要素内でも宣言できます。 pattern では、CLI パーサーに照合させるトークン ストリングを宣言します。

次に、 pattern 要素を使用して、CLI トークン ストリング show を宣言する例を示します。show コマンドは exec モードで使用します。CLI サーバは、 pattern 要素で定義されたトークン ストリングの完全一致を求めます。

CLI トークン ストリング:例

<cli_grammar>
<mode>
<pattern>exec</pattern>
<cmd>
<pattern>show</pattern>
</cmd>
<!-- Place additional mode elements here -->
</mode>
</cli_grammar>

type アトリビュート(pattern 要素内)

<!ATTLIST pattern type (id|regex|help) "id">
 

pattern 要素の type アトリビュートには、3 種類の値を使用できます。id、regex、および help です。

type アトリビュートはパターンを記述します。3 種類の type アトリビュート値がサポートされます。

1. type="id" は、厳密なキーワード ストリングを定義します。

"id" はデフォルトのアトリビュート値なので、次の 2 つの DTD パターン要素定義は同じです。

<pattern type=“id”>trace</pattern>
 
<pattern>trace</pattern>
 

2. type="regex" は、Perl5 の正規表現を定義します。 http://perldoc.perl.org/perlre.html を参照してください。例

pattern type=“regex”>[abc]</pattern>
 

3. type="help" は、コマンドラインに ? ヘルプが入力されたときに、正規表現の代わりに表示するトークンを定義します。 help 要素を使用して、追加テキストを定義します。例

<cli_grammar>
<mode>
<pattern>exec</pattern>
<cmd>
<pattern type="id">show</pattern>
<pattern type="regex">[abc]</pattern>
<!-Specifies the help WORD for display in place of the regex -->
<pattern type="help">A-B-C</pattern>
<help>Select A or B or C</help>
</cmd>
</mode>
<!-- Place additional mode elements here -->
</cli_grammar>
 

show? を入力すると、次のように表示されます。

A-B-C Select A or B or C

help

<!ELEMENT help (#PCDATA)>
 

help 要素の発生は 1 回で、解析されたキャラクタ データ(#PCDATA)が含まれます。

help 要素では、コマンドラインから入力された ? に対して、コンソール表示する、位置が重要なヘルプ テキストを定義します。help 要素は CLI XML で、前の pattern 要素と関連付けられます。pattern 要素ごとに関連ヘルプ パターンを指定し、有用なオンライン ヘルプ情報を提供することを推奨します。

exec モード コマンド show user に対して表示されるヘルプを示します。

hostname> ?
show Show running system information

hostname> show?

user Display user information
hostname>
 

前のヘルプ出力をサポートする XML は、次のようになります。

<cli_grammar>
<mode>
<pattern type=”id”>exec</pattern>
<prompt></prompt> <!--no prompt for exec mode-->
<cmd>
<pattern type=”id”>show</pattern>
<help>Show running system information</help>
<param>
<pattern type=“id”>user</pattern>
<help>Display user information</help>
</param>
</cmd>
</mode>
<!-- Place additional mode elements here -->
</cli_grammar>
 

param

<!ELEMENT param (pattern,(help)?)+>
 

1 つまたは複数の param 要素があり、1 つの子 pattern 要素、ゼロまたは 1 つの子 help 要素が伴います。

param 要素では、プライマリ キーワード 以外 の CLI コマンドライン上のキーワード/トークンを定義します。各 cmd 要素で、完全な CLI コマンドラインを定義します。この CLI コマンドラインは、プライマリ キーワード pattern 要素に、任意でゼロ以上の param 要素を続けます。param 要素ごとに、独自のキーワード pattern 要素を指定します。

次の例で、EXEC モードのコマンドライン「turn on the Lights」を作成するために必要な、最小数の定義を示します。分かりやすくするために、help 要素、省略可能な要素、および attlist を省いてあります。下記でプライマリ キーワードを定義してから

<pattern type=”id”>turn</pattern>
 

param 要素でコマンドラインの残りのキーワードを定義することに注意してください。

<cli_grammar>
<mode>
<pattern type=”id”>exec</pattern>
<prompt></prompt> <!--no prompt for exec mode-->
<cmd>
<pattern type=”id”>turn</pattern>
<param>
<pattern type=“id”>on</pattern>
</param>
<param>
<pattern type=“id”>the</pattern>
</param>
<param>
<pattern type=“id”>lights</pattern>
</param>
<action>
<class>com.home.lights.exec_lights_on</class>
</action>
</cmd>
</mode>
<!-- Place additional mode elements here -->
</cli_grammar>
 

cmd

<!ELEMENT cmd ((pattern,(help)?), ((param)*,action)>
 

cmd 要素には、オプションの子 help 要素が 1 つ、ゼロ以上の param 要素、および 1 つの action 要素が含まれます。

cmd 要素は、CLI コマンド定義の中核となる基礎単位です。 cmd 要素を使用して、CLI サーバ内で CLI パーサー ノードを作成します。CLI パーサー ノードのタイプおよび動作は、 cmd 要素の子要素から派生します。

cmd:例 1

CLI コマンド「show user database」および CLI eval( ) ハンドラを、クラス com.cisco.aesop.cli.commands.exec_show_user_database.class に定義します。

コマンド出力のフォーマット時にページ設定をイネーブルにし、パイプ「|」テキスト サーチ メカニズムの使用をイネーブルにするように CLI サーバに指示します。 action 要素内の paginate アトリビュートを参照してください。

<cli_grammar>
<mode>
<pattern type=”id”>exec</pattern>
<prompt></prompt> <!--no prompt for exec mode-->
<cmd>
<pattern type=”id”>show</pattern>
<help>Show running system information</help>
<param>
<pattern type=“id”>user</pattern>
<help>Display user information</help>
</param>
<param>
<pattern type=“id”>database</pattern>
<help>Display all the CLI commands</help>
</param>
<action paginate=”yes” pipehelp=”yes”>
<class>com.cisco.aesop.cli.commands.exec_show_user_database.class</class>
</action>
</cmd>
</mode>
<!-- Place additional mode elements here -->
</cli_grammar>
 

cmd:例 2

CLI コンフィギュレーション コマンド hostname <name> を定義する例を示します。この CLI コマンドの CLI eval( ) ハンドラをクラス com.cisco.aesop.platform.conf_hostname.class として定義します。

コマンドラインから入力したホスト名は、下記で定義する規則を満たす正規表現として受け入れられ、正規表現を含めたコマンドラインの各キーワードに ? ヘルプの応答が用意されます。

<cli_grammar>
<mode>
<pattern type=”id”>config</pattern>
<prompt>(config)</prompt>
<cmd>
<pattern >hostname</pattern>
<help>set the system name</help>
<param>
<pattern type="regex">[a-zA-Z][-a-zA-Z0-9]*[a-zA-Z0-9]/pattern>
<pattern type="help">name</pattern>
<help>hostname not including the domain</help>
</param>
<action>
<class>com.cisco.aesop.platform.conf_hostname.class</class>
</action>
</cmd>
</mode>
<!-- Place additional mode elements here -->
</cli_grammar>

action

<!ELEMENT action ((class)?, (interrupt-timeout)?)>
 

1 つの action 要素に、オプションの class およびオプションの interrupt-timeout 要素が含まれます。

action 要素では、CLI パーサーが CLI コマンドの一致を宣言したときに、CLI サーバが実行するアクションを定義します。

type アトリビュート

<!ATTLIST action type (default) "default" paginate (yes|no) "no" pipehelp (yes|no) "no">

 

action 要素は、 type アトリビュートをサポートします。現在、 type アトリビュートがサポートするのは、デフォルトの attribute-type だけですが、将来は他の action 要素タイプをサポートするように拡張される可能性があります。したがって、現時点では、CLI XML action 要素定義から type アトリビュートを除外しておいてかまいません。

paginate アトリビュート(type 要素内)

<!ATTLIST action type (default) "default" paginate (yes|no) "no" pipehelp (yes|no) "no">

 

action 要素は、 paginate アトリビュートをサポートします。 paginate アトリビュートは、アクション クラスの eval( ) ハンドラ メソッドからのテキスト出力をフォーマットするように、CLI サーバに指示します。CLI サーバは 24 行ごとに出力テキスト ストリームを区切り、ユーザ向けに「 -- More -- 」というメッセージを表示します。ユーザが任意のキーを押すと、次の出力ページが表示されます。

paginate:例

出力のページ設定を指定するコマンド( show parser commands )の作成例を示します。このコマンドは、ハンドラ クラス com.cisco.aesop.cli.commands.show_commands.class で eval( ) メソッドを呼び出します。

<cmd>
<pattern type=”id”>show</pattern>
<help>Show running system information</help>
<param>
<pattern type="id">parser</pattern>
<help>Display parser information</help>
</param>
<param>
<pattern type="id">commands</pattern>
<help>Display all the CLI commands</help>
</param>
 
<action paginate=”yes”>
<class>com.cisco.aesop.cli.commands.show_commands.class</class>
</action>
</cmd>
 

pipehelp アトリビュート(type 要素内)

<!ATTLIST action type (default) "default" paginate (yes|no) "no" pipehelp (yes|no) "no">

 

action 要素は、 pipehelp アトリビュートをサポートします。 pipehelp アトリビュートは、コマンドラインの末尾にパイプ「|」トークンを追加するように CLI サーバに指示します。パイプは、ハンドラ クラスの eval( ) メソッドから出力されたテキストをフィルタリングします(下の例のハンドラ クラスは、com.cisco.aesop.cli.commands.show_commands.class です)。

パイプ フィルタ:

begin -- 一致する行から開始

exclude -- 一致する行を除外

include -- 一致する行を包含

page -- 出力のページ設定( --More--

pipehelp:例

次に、パイプ機能を実装するコマンドの作成例を示します。

この例のコマンドは show parser commands です。

 
<cmd>
<pattern type=”id”>show</pattern>
<help>Show running system information</help>
<param>
<pattern type="id">parser</pattern>
<help>Display parser information</help>
</param>
<param>
<pattern type="id">commands</pattern>
<help>Display all the CLI commands</help>
</param>
<action pipehelp=”yes”>
<class>com.cisco.aesop.cli.commands.show_commands.class</class>
</action>
</cmd>
 

例:

hostname> show parser commands | ?
begin Begin with the line that matches
exclude Exclude lines that match
include Include lines that match
page Paginate output (--More--)
 

show parser commands の出力は、フィルタ タイプ begin、exclude、include、または page のいずれかによってパイプ処理されます。

例:

hostname> show parser commands | begin “d”
 

show parser commands は、ハンドラ クラス com.cisco.aesop.cli.commands.show_commands.class で eval( ) メソッドを呼び出します。

コマンド出力の各行は「begin」フィルタ タイプによってパイプ処理され、この例では「d」の文字から始まるコマンドだけが許可されています。

class

<!ELEMENT class (#PCDATA)>
 

class 要素は、 action 要素の子要素であり、CLI パーサーが対応する CLI コマンドを認識したときに呼び出される、eval( ) 関数/メソッドを含むハンドラ クラスを指定します。ハンドラ クラスの名前には、完全指定のドメインおよびクラス名が含まれます(com.cisco.aesop.service.handler.class など)。命名規則として、クラス名に CLI コマンドのモードを含めることを推奨します。これにより、名前空間の衝突を防止できます。たとえば、クラス名 com.cisco.aesop.service.exec_handler.class には、「exec」モードが含まれています。

class:例

次に、 action 要素内で class 要素を使用して、CLI コマンドの eval( ) ハンドラを定義する例を示します。CLI コマンドは show users です。 class 要素は com.cisco.aesop.exec_show_users.class です。

<cmd>
<pattern type=”id”>show</pattern>
<help>Show running system information</help>
<param>
<pattern type="id">users</pattern>
<help>Display user information</help>
</param>
<action>
<class>com.cisco.aesop.exec_show_users.class</class>
</action>
</cmd>
 

interrupt-timeout

<!ELEMENT interrupt-timeout (#PCDATA)>
 

interrupt-timeout 要素は、このアクションの割り込みタイムアウトを上書きします。解析キャラクタ データは、割り込みタイムアウトの長さ(分単位)を指定する整数を評価します。

次の例は前の例とよく似ていますが、interrupt-timeout を 10 分に設定する interrupt-timeout 要素が異なります。

<cmd>
<pattern type=”id”>show</pattern>
<help>Show running system information</help>
<param>
<pattern type="id">users</pattern>
<help>Display user information</help>
</param>
<action>
<class>com.cisco.aesop.exec_show_users.class</class>
<interrupt-timeout>10</interrupt-timeout>d>
</action>
</cmd>
 

type regex

pattern タグの type= ‘regex' で、Perl 5 regex 規格に準拠した正規表現として内容を定義します。Perl 5 regex のマニュアルについては、 http://perldoc.perl.org/perlre.html を参照してください。

regex の定義例:

例 1 :0 ~ 99 の 1 桁または 2 桁の数値

<pattern type=’regex’>[0-9][0-9]?</pattern>
 

例 2 :英数字ストリング

<pattern type=’regex’>[a-zA-Z0-9]*</pattern>
 

例 3 :HTTP の URL

<pattern type=’regex’>http://[-*.+:@?=a-zA-Z0-9/_]*</pattern>
 

CLI プラグインの呼び出し

コンフィギュレーション モードを開始し、CLI プラグイン コマンドを呼び出す手順は、次のとおりです。

手順の概要

1. configure terminal

2. app-service application-name

設定の詳細については、『 Cisco AXP User Guide 』の「CLI Plug-in Invocation」を参照してください。

CLI プラグイン アクション API

ディストリビューション サービスでサポートされる CLI プラグイン アクション スクリプトまたはクラスは、C クラス、Java クラス、および Bash シェル スクリプトとして記述します。スクリプトまたはクラス内部の API は、eval( ) メソッド(Java)または eval( ) 関数(C)で提供します。

ユーザが CLI コマンドを入力すると、そのコマンドに対応する CLI プラグイン アクションが呼び出されます。CLI プラグイン アクションはアプリケーションと相互作用します。必要な CLI プラグイン アクション、アプリケーション、および DTD の詳細については、「CLI プラグイン アプリケーション」を参照してください。

CLI プラグイン アクション API は、eval( ) メソッドまたは関数を使用して実装します。適切な C ライブラリまたは Java クラスに API コールをコンパイルします。

次に、action クラスに必要な Java、C、または シェル スクリプト対応 API について説明します。

Java

action クラスで eval( ) メソッドを実装する必要があります。

Java action クラスをファイルにコンパイルします。ファイル名のフォーマットは
<action_name>.class
です。クラスは com.xyz.myclass.class などの、名前空間の階層に含めることができます。CLI プラグイン用の XML 定義で、階層型クラス名を定義する必要があります。「XML DTD 定義」の class 要素を参照してください。

C

action クラスで eval( ) 関数を実装する必要があります。

C action クラスを <action_name>.so という名前の共有ライブラリにコンパイルします。

シェル スクリプト

シェル スクリプトは C システム コールを使用して、直接実行します。

シェル スクリプトから戻るのは、終了ステータスを示す整数値だけなので、シェル スクリプトに、CLI コンソールに表示されるメッセージを戻す動作はサポートされていません。

API は次の条件を使用します。

grammar:CLI コマンドの構文を指定する、スペースで区切られたストリング。たとえば、「show time」です。

tokens:ユーザが入力する実際の CLI コマンドを指定する、スペースで区切られたストリング。「show tim」、「sh time」、「sho ti」などです。

return status:CLI 実行戻りコードを指定する整数が含まれたストリング。0 は成功、ゼロ以外は失敗を示します。

return display:CLI コマンドを入力したユーザに対して、CLI コンソールに表示されるストリング。

次に Java、C、および Bash の API について説明します。

「eval:CLI プラグイン アクション API」

「evalError:CLI プラグイン アクション API」


) grammar[ ] パラメータには、正規表現(regex)を指定できます。Cisco AXP では Perl5 の regex を使用します。詳細については、次の URL にアクセスして Perl のマニュアルを参照してください。
http://perldoc.perl.org/perlre.html


eval:CLI プラグイン アクション API

 

Java
public static String[] eval(String tokens[], String grammar[])
 

CLI コマンドを呼び出します。

この Java コードの例、MyTime.java には、eval( ) メソッドへのコールが含まれています。これは図8 の CLI プラグインで示した Java コードと類似しています。

パラメータ:

tokens[] -- CLI のユーザにより入力された、スペースで区切られた token のストリングで、配列に分割されます(例: “sho tim” は、 {“sho”, “tim”} )。
 
grammar[] -- スペースで区切られた、token に一致する grammer のストリングで、配列に分割されます。この grammer のリストは、カスタム CLI 定義で定義されます。(例: “show time” は、 {“show”, “time”}
 

戻り値:

String[] -- String 配列には、2 つの String を含みます。1 つめの String には次の戻り値を含みます: “0” -- 成功、ゼロ以外 -- 失敗。Config CLI の場合、失敗の戻りステータスは保存されません。2 つめの String は、戻り表示です。それ以外のリストは無視されます( {“0”, “Tue, 07 Aug 2007 16:20:36”} など)。
 

例:

eval({“sho”, “tim”}, {“show”, “time”});
returns the following:
{“0”, “Tue, 07 Aug 2007 16:20:36”}
 

 

C
void eval(char* tokens[], int tokens_size, char* grammar[], int grammar_size, char** ret_status, int* ret_status_size, char** ret_display, int* ret_display_size);
 

CLI コマンドを呼び出します。

パラメータ:

tokens[] -- CLI のユーザにより入力された、スペースで区切られた token のストリングで、配列に分割されます(例:“sho tim”は、{“sho”, “tim”})。
 
tokens_size -- tokens[] 配列の長さ(例:上記の tokens[] 配列の場合は「2」)。
 
grammar[] -- スペースで区切られた、token に一致する grammer のストリングで、配列に分割されます。この grammer のリストは、カスタム CLI 定義で定義されます。(例:“show time”は、{“show”, “time”})
 
grammar_size -- grammar[] 配列の長さ(上記の grammar[] 配列の場合は「2」)。
 
ret_status -- 戻りステータスのストリング:0 -- 成功、ゼロ以外 -- 失敗。Config CLI の場合、失敗の戻りステータスは保存されません。
 
ret_status_size -- ret_status ストリングのサイズ
 
ret_display -- CLI コンソール表示のストリング。例:“Tue, 07 Aug 2007 16:20:36”
 
ret_display_size -- ret_display ストリングのサイズ
 

戻り値:

なし -- ret_status と ret_display(上記参照)のパラメータは、戻り値を提供します。
 

例:

my_time.c
 
#include ...
 
void eval(char* tokens[], int tokens_size, char* grammar[], int grammar_size, char** ret_status, int* ret_status_size, char** ret_display, int* ret_display_size){
...
}
...
eval({“sho”, “tim”}, 2, {“show”, “time”}, 2, “0”, 1, “Tue, 07 Aug 2007 16:20:36”, 25);
 

戻り値:(パラメータ ret_status および ret_display)

ret_status = “0”
ret_status_size = “1”
ret_display = “Tue, 07 Aug 2007”
ret_display_size = 25
 

 

Bash
my_time.sh $1 $2
 

Bash シェル アクションの呼び出し方は、C および Java の場合と異なります。シェル スクリプト内の関数を呼び出すのではなく、スクリプトそのものを呼び出し、トークンおよびグラマーを引数として渡します。したがって、このシグニチャはシェル スクリプトそのものの呼び出しに適用されます。

パラメータ:

$1 -- 引用符(“)で囲まれた CLI token リスト。CLI のパラメータはスペース( )で区切られます。
 
$2 -- 引用符(“)で囲まれた CLI grammar リスト。CLI のパラメータはスペース( )で区切られます。
 

戻り値:

整数値は、コマンドが成功したかどうかを示します。
0 -- 成功
ゼロ以外 -- 失敗
Config CLI の場合、失敗の戻りステータスは保存されません。シェル スクリプトから戻るのは、終了ステータスを示す整数値だけなので、シェル スクリプトに、CLI コンソールに表示されるメッセージを戻す動作はサポートされていません。
 

例:

スクリプト例

my_time.sh
 
#!/bin/bash
# inside the shell script my_time.sh
...
tokens=$1
grammar=$2
 
# Do something with ${tokens} and ${grammar}
...
 
exit 0
 
 

スクリプト コールの例

my_time.sh “sho tim” “show time”
は、次の値を返します。
0
 

evalError:CLI プラグイン アクション API

 

Java
public static void evalError()
 

アクション呼び出し時の割り込みを処理する、オプションの割り込みハンドラ。CLI ディストリビューション リスナーによって生成された別個のスレッドでコールされます。

パラメータ:

なし
 

戻り値:

なし
 

例:

public static void evalError() {
..
}
 

 

C
void eval_error()
 

アクション呼び出し時の割り込みを処理する、オプションの割り込みハンドラ。CLI ディストリビューション リスナーのメイン スレッドから eval( ) を呼び出したワーカー スレッドに対して発生した信号によって呼び出されます。

パラメータ:

なし
 

戻り値:

なし
 

例:

void eval_error( ){
...
}
 

no プレフィクスのサポート

次に、次の構文に関して説明します。

>set timeout [0-9][0-9]?
 

このコマンドには、次の例のように、プレフィクスとして no を指定できます。

>no set timeout 10
 

no プレフィクスは、すべてのコンフィギュレーション CLI で自動的にサポートされ、tokens 配列の CLI トークンの前に追加されます。

次の例では、CLI プラグイン アクションは次の Grammar および Tokens 配列に示された項目を受け取ります。

Grammar:

set timeout [0-9][0-9]?

Tokens:

no set timeout 10

CLI プラグイン ディストリビューション リスナー API

アプリケーションは、メイン プログラム内で起動する CLI プラグイン ディストリビューション リスナーをコールして、CLI プラグイン ディストリビューション サービスを開始します。

ディストリビューション リスナーを起動すると、メイン プログラムと同じプログラム空間内で、CLI アクションを呼び出せます。

CLI プラグイン ディストリビューション リスナーは、Java、C、またはシェル スクリプトで起動できます。使用する言語に応じて、コードが対応するメイン プログラム内で次の API のいずれか 1 つを呼び出します。

次の Java コードの抜粋は、startCLIDistributionVMThread( ) メソッドのコールを示しています。

 

Java
package com.cisco.aesop.apphosting.cli_distribution.CLIDistributionVM;
 
public static void startCLIDistributionVMThread(String appName);
非ブロックの CLI プラグイン ディストリビューション サービスを開始します。
 

パラメータ:

appName -- アプリケーション/仮想インスタンスの名前。この名前は、実装のプロセスで使用された名前と一致する必要があります。
 

戻り値:

なし
 

例:

CLIDistributionVM.startCLIDistributionVMThread(“myAppFoo”);
 
make/compile-time dependency:
cli_distribution_vm.jar
 
run-time dependency:
cli_distribution_vm.jar
localsocket.jar
/cli_commópath to the CLI actions
 

次の C コードの抜粋は、start_cli_distribution_vm_thread( ) 関数のコールを示しています。

 

C
cli_distribution_vm.h
 
int start_cli_distribution_vm_thread(char* app_name);
非ブロックの CLI プラグイン ディストリビューション サービスを開始します。
 

パラメータ:

app_name -- アプリケーション/仮想インスタンスの名前。この名前は、実装のプロセスで使用された名前と一致する必要があります。
 

戻り値:

rc -- リスナーを開始する戻りコードです。
0 -- 成功
1 -- 失敗
 

例:

int rc = start_cli_distribution_vm_thread(“my_app_bar”);
 
make/compile-time dependency:
cli_distribution_vm.h
libcli_distribution_vm.so
 
run-time dependency:
libcli_distribution_vm.so
liblocal_socket.so
 

次のシェル スクリプトの抜粋は、cli_distribution_vm の呼び出しを示しています。

 

シェル スクリプト
/bin/cli_distribution_vm $1
 

パラメータ:

$1 -- アプリケーション/仮想インスタンスの名前。この名前は、実装のプロセスで使用された名前と一致する必要があります。
 

戻り値:

なし
 

例:

cli_distribution_vm my_app_bar &

CLI プラグイン エラー

アクション クラスは、Cisco AXP サーバにコマンドの戻りステータスを伝えます。戻りステータスは、コマンドの実行が成功したか、失敗したかを伝えます。アクション クラスは戻りストリングを使用して、ユーザにコンソールで表示しなければならないメッセージを伝えます。

戻りストリングをサポートするのは、C および Java のアクション クラスだけです。

戻りステータスは、C アクション クラス、Java アクション クラス、およびシェル スクリプトがサポートします。

次の条件のいずれかが「真」の場合は、CLI コンソールにエラー メッセージが表示されます。

CLI プラグイン アクションがゼロ以外の戻りステータス コードを戻す。

Cisco AXP CLI サーバ、CLI プラグイン ディストリビューション サービス、または CLI プラグイン アクションが相互に通信できなかった。

CLI プラグイン アクションの呼び出しがタイムアウトした。

エラー メッセージのヘッダーが、CLI プラグイン サービスによってメッセージが表示されたことを示します。

アクション呼び出しの割り込み

CLI プラグインのユーザは、Ctrl-C を押すと、アクションの呼び出しに割り込むことができます。

アクション クラスへの Ctrl-C 割り込みを処理する、割り込みハンドラをオプションで実装できます。割り込みハンドラを使用できるのは、C および Java のみです。「evalError:CLI プラグイン アクション API」を参照してください。割り込みハンドラはアクション固有です。したがって、ハンドラが適用されるのは、特定のアクション クラスだけです。

C の場合、アクションを呼び出したのと同じスレッドとして、割り込みハンドラを呼び出します。CLI ディストリビューション リスナーのメイン スレッドで、アクション呼び出しワーカー スレッドに対して信号を発します。

Java では、別個のスレッドとして割り込みハンドラを呼び出します。

割り込みハンドラが設定されていないアクションは、CLI ディストリビューション リスナーが処理します。リスナーはシステム コールを使用して、eval( ) 関数を実行しているスレッドを停止します。

割り込みハンドラーは、膠着状態になる可能性があります。レスキュー タイマーで、割り込みハンドラの呼び出しを監視します。デフォルト値は 5 分です。このタイマー値を変更するには、XML 定義ファイルで interrupt-timeout を変更します。定義ファイルについては、「XML DTD 定義」を参照してください。レスキュー タイマーがタイムアウトを検出すると、割り込み処理が失敗したものとみなされます。割り込み処理が失敗した場合は、CLI ディストリビューション リスナーが割り込みを処理します。

表14 で、割り込み処理のさまざまな例について説明します。

 

表14 割り込み処理:例

ケース
アクションに割り込みハンドラの実装が含まれているか
割り込みハンドラが eval( ) コールからただちに戻るか
<interrupt-timeout> 要素が x 分として定義されているか
内部割り込み処理の説明
ユーザから見た動作

1

eval_error による CLI 呼び出しの割り込み。

CLI プロンプトが戻り、ただちに新しい CLI プラグインを処理できます。

2

×

eval_error による CLI 呼び出しの割り込み。

CLI プロンプトが戻り、ただちに新しい CLI プラグインを処理できます。

3

×

x 分後、ディストリビューション リスナーによる CLI 呼び出しの割り込み。

CLI プロンプトに戻りますが、x 分が経過するまでは、新しい CLI プラグインを処理できません。

4

×

×

5 分後、ディストリビューション リスナーによる CLI 呼び出しの割り込み。

CLI プロンプトに戻りますが、5 分が経過するまでは、新しい CLI プラグインを処理できません。

5

×

起こりえないケース。

起こりえないケース。

6

×

×

起こりえないケース。

起こりえないケース。

7

×

×

CLI ディストリビューション リスナーによる CLI 呼び出しの即時割り込み。

CLI プロンプトが戻り、ただちに新しい CLI プラグインを処理できます。

8

×

×

×

CLI ディストリビューション リスナーによる CLI 呼び出しの即時割り込み。

CLI プロンプトが戻り、ただちに新しい CLI プラグインを処理できます。

CLI プラグインの同時呼び出し

ユーザは複数の CLI セッションを開始できます。ただし、同じ CLI ディストリビューション リスナーに対する CLI プラグイン同時呼び出しはサポートされません。CLI ディストリビューション リスナーが、ある CLI プラグインを処理している間(すなわち、CLI プラグイン アクションが呼び出されていて、まだ戻っていないとき)、リスナーはすべての新しい CLI プラグイン要求をブロックします。ユーザに対して、CLI プラグイン要求がブロックされたので、あとで再試行するように指示するメッセージが CLI コンソールに表示されます。

CLI プラグインのプレパッケージ

CLI プラグイン アプリケーションは、パッケージ ツールを実行する前に、プレパッケージを行う必要があります。パッケージ化の詳細については、「パッケージ ツール」を参照してください。

CLI プラグイン SDK パッケージ ツールを使ったプレパッケージの方法は、ディレクトリ sdk/tools/custom_cli/ におけるデータのセットアップにより異なります。

必要なコンポーネントは次のとおりです。各コンポーネントの説明については、 表15 を参照してください。

sdk/tools/custom_cli/
actions/
definitions/
internal/
cli_plugin.config
cli_plugin.py
cli_grammar.dtd
 

) cli_plugin.py を使用するには、開発マシンに Java SDK バージョン 1.4.2 以上をインストールしておく必要があります。


 

表15 パッケージ ツール コンポーネント

コンポーネント
説明
actions/

コンパイル済み CLI プラグイン アクション クラス

definitions/

CLI プラグインの定義

internal/

ツールが使用する内部ファイル


) これらのファイルを変更してはなりません。


cli_plugin.config

コンフィギュレーション ファイル

cli_plugin.py

CLI プラグイン アプリケーションをパッケージ化する実行可能ファイル

cli_grammar.dtd

Data Type Definition(DTD; データ タイプ定義)ファイル


) このファイルを変更してはなりません。


CLI プラグイン アプリケーションをプレパッケージする手順は、次のとおりです。


ステップ 1 ディレクトリ actions/ にアクション ファイルをコピーします。

ステップ 2 ディレクトリ definitions/ に CLI プラグインの定義ファイルをコピーします。


) internal/ ディレクトリのファイルを変更してはなりません。


ステップ 3 コンフィギュレーション ファイル cli_plugin.config を編集します。 表16 を参照してください。

 

表16 コンフィギュレーション ファイル コンポーネント

コンポーネント
説明

file

ディレクトリ definitions/ にある CLI プラグイン定義ファイル

javapath

ディレクトリ Java SDK bin/ のパス。Java の推奨バージョンは J2SDK 1.4 です。

vm

アプリケーション名。この名前は、あとでアプリケーション パッケージ ツールで指定する名前と一致する必要があります。「パッケージ名」を参照してください。

proj_src

この製品をプレパッケージするルート ディレクトリ。

proj_src 引数を指定すると、プロジェクト ファイルがディレクトリ /source/showtimeapp/build に移動し、いつでもパッケージ化できるようになります。

proj_src 引数を指定しなかった場合は、/source/showtimeapp/build のファイルの showtime.tar にプロジェクト ファイルが作成されます。あとでパッケージ化を実行中に、次の例のように showtime.tar を untar する必要があります。

tar xvf showtime.tar -C /source/showtimeapp/build

ステップ 4 CLI プラグイン SDK パッケージ ツールを実行して、定義およびアクションをパッケージ化します。

実行可能パッケージ ツール(cli-plugin.py)を実行するには、次のように入力します。

python cli-plugin.py
 

ツールの実行が正常に完了すると、アプリケーションの tar ファイルが output/ ディレクトリに作成されます。

ステップ 5 次の例のように、ソース ディレクトリに tar ファイルを移動させます。

tar ファイルの移動:例

#cp output/showtime.tar /tmp/proj_dir/src
#cd /tmp/proj_dir/src
#tar xf showtime.tar
#rm showtime.tar
 

上記の例の各行について説明します。

#cp output/showtime.tar /tmp/proj_dir/src
 

showtime.jar をパッケージ ツールが動作するソース ディレクトリにコピーします。

#cd /tmp/proj_dir/src
 

ディレクトリをソース ディレクトリ /tmp/proj_dir/src に切り替えます。

#tar xf showtime.tar
 

showtime.tar ファイルを untar し、ソース ディレクトリの内容の一部にします。

#rm showtime.tar
 

showtime.tar を削除します。

CLI プラグインのプレパッケージはこれで完了です。

次に、パッケージ ツールを実行します。詳細については、「パッケージ ツール」を参照してください。

パッケージ化が終了したあとで、パッケージの内容を確認するには、スクリプト pkg_info.sh を使用します。詳細については、「Package Information」を参照してください。


 

CLI プラグイン アプリケーション:例

次のセクションに、簡易な CLI プラグイン アプリケーションの開発例を示します。

「ヘルス ステータス」

「パッケージ名」

「show time アプリケーション:例」

ヘルス ステータス

show state cli コマンドでアプリケーションのヘルス ステータスを表示できるように、アプリケーションにヘルス ステータスをコーディングすることを推奨します。

アプリケーションにヘルス ステータスがコーディングされていない場合、show state コマンドを実行すると、報告されたアプリケーションのヘルス ステータスは、ダッシュ「---」で表示されます。

show state コマンド(アプリケーションのヘルス ステータスがコーディングされていない場合):例

my-javalin> app-service helloworld
my-javalin(exec-appservice)> show state
APPLICATION STATE HEALTH
helloworld online ---

パッケージ名

アプリケーションのパッケージ名を決定し、同じパッケージ名を次の 3 箇所で使用する必要があります。

1. cli_plugin.config ファイルの VM トピックに割り当てるパッケージ名

2. アプリケーションが API startCLIDistributionVMThread ( ) をコールするときに、引数として割り当てられるパッケージ名

3. パッケージ ツールの **name 引数に割り当てられたパッケージ名

show time アプリケーション:例

カスタム コマンドは、XML 定義ファイルおよびアクション スクリプトで定義します。カスタム コマンドのコードを作成し、アプリケーションとともにパッケージ化して、Cisco AXP にインポートできます。

例として、ユーザ要求に応答し、コマンド show time を使用して時刻を表示しなければならないアプリケーションについて検討します(ユーザ要求は、CLI プラグイン アプリケーション:例 のステップ 3)。

「show time」の例を作成する手順は、次のとおりです。


ステップ 1 ディレクトリ mkdir /source/showtimeapp を作成します。

ステップ 2 XML ファイル MyTime.xml を作成し、ディレクトリ /source/showtimeapp に保存します。「XML スクリプト:例」を参照してください。

ステップ 3 アクション クラス MyTime.java を作成します。「アクション クラス:例」を参照してください。

ステップ 4 アプリケーション(リスナー)を作成します。「アプリケーションからのリスナーの起動:例」を参照してください。

ステップ 5 ビルドおよびテストを行います。「ビルドおよびテスト:例」を参照してください。

ステップ 6 CLI プラグイン アプリケーションのプレパッケージを行います。「CLI プラグインのプレパッケージ:例」を参照してください。


 

図9 に、showtime CLI プラグイン アプリケーションを Cisco AXP CLI サーバで実行した場合のイベント シーケンスを示します。

図9 CLI プラグイン アプリケーション:例

 

XML スクリプト:例

XML DTD を使用して、XML 定義ファイルを作成します。XML DTD 定義の詳細については、「XML DTD ファイル」を参照してください。

次に、スクリプト MyTime.xml show time のコードを示します。

<?xml version='1.0' encoding='UTF-8' ?>
<!DOCTYPE cli_grammar SYSTEM "cli_grammar.dtd" >
 
<cli_grammar>
<mode>
<pattern type="id">exec</pattern>
<cmd>
<pattern type="id">show</pattern>
<help>show time</help>
<param>
<pattern type="id">time</pattern>
<help>show current time</help>
</param>
<action>
<class>MyTime.class</class>
</action>
</cmd>
</mode>
</cli_grammar>
 

ユーザがコマンド show time を入力すると、Java アクション クラス MyTime.class がコールされます。

アクション クラス:例

MyTime.java が日付と時刻を返します。eval() メソッドは、ユーザの CLI コマンドを受け付け、現在の日付と時刻を返す API です。eval( ) メソッドの詳細については、「CLI プラグイン アクション API」を参照してください。

/*MyTime.java is a simple CLI Action class that returns the application return code and

*the current date/time. If it fails an application return code of 1 is returned along

*with the exception message. The static main program can be invoked to easily test the

*program independently

*/

import java.util.Date;

import java.text.SimpleDateFormat;

 

/**

* Returns the current time of the day

*/

 

public class MyTime{

public static String[] eval(String[] tokens, String[] grammar){

String[] retArray = new String[2];

try{

if(tokens.length == 2 && grammar[0].tolower().equals(“show”) &&

grammar[1].tolower().equals(“time”)){

Date curTime = new Date();

SimpleDateFormat sdf = new SimpleDateFormat("EEE, d MMM yyyy HH:mm:ss");

retArray[0]="0";

retArray[1]=sdf.format(curTime);

}

else{

retArray[0]=”1”;

retArray[1]=”Unknown command”;

}

}

catch(Exception e){

retArray[0]="1";

retArray[1]=e.getMessage();

}

return retArray;

}

 

public static void main(String[] args){

String[] tokens = {"show","time"};

String[] grammer = {"show","time"};

String[] message = eval(tokens,grammer);

System.out.println("Exit code: " + message[0] + " Result:" + message[1]);

}

}

 

XML スクリプト MyTime.xml で、 show time コマンドを定義します。「XML スクリプト:例」を参照してください。

上記アクション クラス(MyTime.class)をコンパイルしてテストしてから、あとで容易にアクセスできるように、ファイル showtime.jar に保管します。jar ファイルの格納先は、/source/showtimeapp ディレクトリの jar -cvf showtime.jar MyTime.class です。

ユーザがコマンド show time を入力すると、このアクション クラス MyTime.class がコマンドを処理します。「アクション クラス:例」を参照してください。

クラス MyTime.class をコールするには、アプリケーションでリスナーが起動していなければなりません。「アプリケーションからのリスナーの起動:例」を参照してください。

アプリケーションからのリスナーの起動:例

スレッド startCLIDistributionVMThread を使用して、アプリケーション リスナーを起動します。たとえば、アプリケーション MyAppMgr 内で次のコマンドを使用します。

CLIDistributionVM.startCLIDistributionVMThread("showtime");
 

MyAppMgr はアプリケーションのヘルス ステータスを提供し、定義済みの show time コマンドを受信する VM スレッドを起動します。ユーザがコマンド show time を入力すると、アプリケーションが MyTime クラスをコールします。

/*

* Third party application that reports its health status, starts up the CLI distribution

* thread, and then waits.

*/

import com.cisco.aesop.apphosting.cli_distribution.CLIDistributionVM;

import java.io.*;

import java.lang.*;

 

public class MyAppMgr{

/**

*Displays and writes passed in message

*@param msg: message to be displayed and logged.

*@param pw: PrintWriter object

*@return nothing

*

*/

public void printMessage(String msg, PrintWriter pw){

System.out.println(msg);

if(pw != null){

pw.println(msg);

pw.flush();

}

}

/**

*Sends the health status. Logs exception.

*@param name: application package name

*@param status: health status

*@param pw: PrintWriter object

*@return nothing

*

*/

 

public void sendStatus(String name, String status, PrintWriter pw){

try{

Runtime rt = Runtime.getRuntime();

rt.exec("/bin/app_status_notifier " + name + " " + status);

}

catch(Exception e){

printMessage("Send of status failed. Exception " + e.getMessage(),pw);

}

}

 

//code for testing application

public static void main(String[] args){

MyAppMgr mgr = new MyAppMgr();

PrintWriter pw = null;

try{

pw = new PrintWriter(new FileOutputStream(new File("/var/log/showtime.log")));

mgr.sendStatus("showtime","INITIALIZING",pw);

mgr.printMessage("Starting VM Thread",pw);

// The following line starts the listener

CLIDistributionVM.startCLIDistributionVMThread("showtime");

Object obj = new Object();

synchronized(obj){

mgr.sendStatus("showtime","ALIVE",pw);

mgr.printMessage("Going into wait mode",pw);

pw.flush();

obj.wait();

}

}

catch(Exception e){

mgr.printMessage("Exception " + e.getMessage(),pw);

}

finally{

mgr.printMessage("Exiting MyAppMgr program",pw);

mgr.sendStatus("showtime","DOWN",pw);

if(pw != null){

pw.close();

}

}

} //end main

} //end class

 

ビルドおよびテスト:例

ビルド

[bash]# javac -classpath cli_distribution_vm.jar MyAppMgr.java
 

このクラスをファイル showtime.jar に追加し、あとで簡単にアクセスできるようにします。

jar -uvf showtime.jar MyAppMgr.class
 

テスト

テストに必要な Linux ライブラリ:liblocal_socket.so

showtime.jar をディレクトリ /source/showtimeapp にコピーします。

次の java コマンドで、アプリケーション MyAppMgr をテストします。ファイル liblocal_socket.so および jar ファイルは、現在のディレクトリより 1 レベル下の lib ディレクトリにあります。


) 開発環境でこのテストを実行するには、ユーザ「root」である必要があります。



) CLI プラグイン パッケージへの依存関係を指定してアプリケーション(MyTime)をパッケージ化した場合、パッケージ化されるのは showtime.jar だけです。これは、ファイル liblocal_socket.so およびその他の jar ファイルがゲスト OS(仮想インスタンス)にあるためです。


[bash]# java -Djava.library.path=lib/ -cp lib/cli_distribution_vm.jar:lib/localsocket.jar:lib/showtime.jar MyAppMgr
 

出力:

Starting VM Thread
Going into wait mode
CLI_PLUGIN:CLIDistributionVM.receiveIPCMessages: server socket opened successfully
 

build ディレクトリの作成

パッケージ化し、Cisco AXP にインストールするプレパッケージ ファイルの保管用ディレクトリを作成します。

mkdir /source/showtimeapp/build
 

CLI プラグインのプレパッケージ:例

「CLI プラグインのプレパッケージ」の手順に従った、CLI プラグイン アプリケーションのプレパッケージ例を示します。


ステップ 1 ディレクトリ actions/ にアクション ファイル MyTime.class をコピーします。

ステップ 2 ディレクトリ definitions/ に CLI プラグイン定義ファイル MyTime.xml をコピーします。

ステップ 3 コンフィギュレーション ファイル cli_plugin.config を編集します。

file=MyTime.xml
javapath=/usr/bin/java/bin
vm=showtime
proj_src=/source/showtimeapp/build
 

proj_src 引数を変更するかどうかを選択できます。表16 の proj_src を参照してください。

ステップ 4 CLI プラグイン SDK パッケージ ツールを実行して、定義およびアクションをパッケージ化します。

python cli-plugin.py
 

詳細については、「CLI プラグインのプレパッケージ」のステップ 4 を参照してください。

次に、ソース ディレクトリに tar ファイルを移動させます。「tar ファイルの移動:例」を参照してください。

プレパッケージングはこれで完了です。


 

トラブルシューティングおよびロギング

このセクションではトラブルシューティングについて、続くサブセクションでは主要なロギング タイプについて説明します。

「アプリケーションのトラブルシューティング」

「vi エディタのトラブルシューティング」

「ロギング」

「Syslog サーバでのロギング」


) 目次に戻るには、ここをクリックしてください。


アプリケーションのトラブルシューティング

デバッグ手順

次のデバッグ手順は、アプリケーションをデバッグするさまざまなオプションを網羅しています。


ステップ 1 下記を入力して、アプリケーションが動作しているかどうかを確認します。

app-service <app name>

<app name> はアプリケーション名です。

show process

プロセス ID でソートされたすべてのプロセスが、昇順で表示されます。『 Cisco AXP User Guide 』の「Viewing Processes」を参照してください。CLI プラグイン アプリケーションに含まれているアプリケーションは、常時動作している必要があります。

ステップ 2 下記を入力して、アプリケーションの状態を表示します。

show state

ステップ 3 アプリケーション ステートが「online」ではなかった場合は、ステップ 4 に進みます。

アプリケーション ヘルスが「ALIVE」で、アプリケーションが動作している場合は、手順の最後に進みます。

アプリケーション ステートが「---」で、ヘルス ステータスを提供するようにアプリケーションがコーディングされている場合は、ステップ 5 に進みます。

アプリケーション ヘルスが「ALIVE」ではない場合は、ステップ 5 に進みます。

ステップ 4 次の手順では、アプリケーションに対応する仮想インスタンスが起動しなかった理由の詳細を調べます。

a. exit を入力して Cisco AXP プロンプトに戻ります。

b. messages.log ファイルまたは messages.log.prev ファイルを確認します。次のコマンドのどちらか 1 つを入力します。

show log name messages.log containing <application name> paged

show log name messages.log.prev containing <application name> paged

<application name> はアプリケーション名です。ログ ファイルには、システムが作成したエラー メッセージが含まれています。

これら 2 つのうち、どちらか 1 つのコマンドによって表示されたログ ファイルを調べます。仮想インスタンスが起動しなかった理由がわかります。一度に表示されるログ ファイルは 1 ページです。

ステップ 5 ロギングを行うようにアプリケーションを設定している場合、アプリケーション ログ ファイルはゲスト インスタンスに置かれ、アプリケーションが作成したメッセージを含んでいます。次のコマンドのどちらか 1 つを入力します。

show log name messages.log paged

show log name messages.log.prev paged

<application name> はアプリケーション名です。これら 2 つのうち、どちらか 1 つのコマンドによって表示されたログ ファイルを調べます。アプリケーションが起動しなかった理由がわかります。ログ ファイルには、アプリケーションが作成したエラー メッセージが含まれています。


) アプリケーションがディレクトリ /var/log にログ ファイルを書き込む場合、またはアプリケーションにこのディレクトリを参照するリンクがある場合は、上記の 2 つのコマンドの最初の方で、messages.log の代わりにログ ファイルの名前を指定すると、ログ ファイルを表示できます。


ステップ 6 アプリケーションのトレースをオンにします。指定したモジュール、エンティティ、またはアクティビティをトレースできます。フル トレースを行う場合は、次のように入力します。

trace all

プロセスの実行後、次のように入力します。

show trace buffer

ステップ 7 断続的な問題に対応するために、Cisco AXP は vmstat top などの Linux コマンドをシェルでサポートします。したがって、アプリケーションが CPU を多用しているのか、大量のメモリを使用しているのかを調べることができます。使用可能な RAM または割り当てられた CPU を使い果たすと、アプリケーションの動作がきわめて遅くなることがあります。システムがトラフィック容量を超えていないかどうかを調べるには、ルータ上で次のコマンドを入力します。

show interfaces <interface>


 

vi エディタのトラブルシューティング

vi エディタは一部の端末では、予期した動作をしません。この問題を修正するには、次のパラメータを指定して vi を実行します。

-T ansi

ロギング

仮想インスタンス内部のロギングに関しては、syslog デーモン syslog-ng がファイル /var/log/messages.log に、トレース情報およびロギング情報を追加します。

次のセクションでは、ロギングについて説明します。

「ログ ファイルの循環」

「ログ レベル」

「ロギングの使用」


) 目次に戻るには、ここをクリックしてください。


次のトピックの詳細については、『 Cisco AXP User Guide 』を参照してください。

ログ ファイルのサイズ限度設定

システム ログ レベルの設定

リモート ロギングの設定

ファイルの表示

ファイルのコピー

ファイルの消去

ログ ファイルの循環

Cisco AXP の Syslog は、次の 2 ファイルによるログ ファイルの循環をサポートします。

messages.log(プライマリ ログ ファイル)

messages.log.prev(バックアップ ログ ファイル)

messages.log が limit log-file size コマンドで指定した限度に達すると、ファイル内容がバックアップ ファイル messages.log.prev に移され、新しい messages.log ファイルへのロギングが始まります。デフォルトのログ ファイル サイズは 20 MB です。

コマンド show logs を使用すると、すべてのログ ファイルの内容を表示できます。コマンド show log name を使用すると、/var/log ディレクトリに置かれているログ ファイルの内容を表示できます。

ログ レベル

Cisco AXP は、次のログ レベルをサポートします。

LOG_EMERG:システムが使用不能

LOG_ALERT:即時対処が必要

LOG_CRIT:クリティカル条件

LOG_ERR:エラー条件

LOG_WARNING:警告条件

LOG_NOTICE:正常だが重要な条件

LOG_INFO:情報メッセージ

LOG_DEBUG:デバッグレベル メッセージ

アプリケーションで使用可能なすべてのログ レベルの中から、CLI はログ レベル数を管理が容易な 4 に減らします。

ログしきい値を次のいずれかの値に設定できます。

Errors :LOG_ERR およびそれ以下の重大度のイベントが記録されます。LOG_EMERG、LOG_ALERT、および LOG_CRIT を含みます。

Warning :LOG_WARNING およびそれ以下の重大度のイベントが記録されます。Error しきい値で説明したすべてのエラー メッセージを含みます。

Notice :LOG_NOTICE およびそれ以下の重大度のイベントが記録されます。Warning しきい値で説明したすべてのエラー メッセージを含みます。

Info :LOG_INFO およびそれ以下の重大度のイベントが記録されます。Notice しきい値で説明したすべてのエラー メッセージを含みます。

ロギングの使用

仮想インスタンス上のロギングの C または Java コードについて説明します。

「C:Syslog」

「Java:log4j」

ログ メッセージは仮想インスタンスのファイル /var/log/messages.log に格納されます。ログ ファイルが指定限度(コマンド limit log-file size で設定)に達すると、ログ ファイルの内容がバックアップ ログ ファイル messages.log.prev に移されます。新しい messages.log ファイルがログ メッセージの収集を開始します。ログ ファイルおよびバックアップ ログ ファイルのデフォルト ログ ファイル サイズは、5 MB です。

C:Syslog

C に対応する Syslog API の詳細および例については、 GNU の Web サイトを参照してください。

C の Syslog:例

int main(int argc, char* argv[]){
setlogmask (LOG_UPTO (LOG_DEBUG));
openlog("myapp", LOG_CONS | LOG_PID | LOG_NDELAY, LOG_LOCAL1);
syslog(LOG_DEBUG, "myapp_user_management.eval( ) processing a CLI message\n ");
}

Java:log4j

log4j パッケージの Syslog の詳細については、log4j のマニュアルの「 syslog appender 」を参照してください。URL: http://logging.apache.org/log4j/docs/documentation.html

Cisco AXP API およびライブラリでは、ログは stdout にリダイレクトされます(System.out.println を使用)。

Syslog にログをリダイレクトするには、アプリケーションの出力を /bin/logger にパイプします。次の例を参照してください。

Syslog へのログのリダイレクト:例

この例では、アプリケーション MyAppMain を起動し、CLI プラグインを使用します。CLI プラグインの stdout およびアプリケーションが行った System.out.println コールの出力は、LOG_INFO のログ レベルで Syslog にリダイレクトされます。

# java -cp ./app_bin/myApp.jar:/cli_comm/:/usr/lib/java/localsocket.jar:/usr/lib/java/cli_distribution_vm.jar com.myApp.MyAppMain | /bin/logger -p info
 

ロギングの開始:例

Logger myLogger = Logger.getInstance(“myapp”);
myLogger.debug(”myapp_user_management.eval( ) processing CLI message”);
 

syslog appender のイネーブル化:例

# To enable the syslog appender, set the root logger level to DEBUG and an appender to mySyslog.

log4j.rootLogger=DEBUG, mySyslog, myFile, myConsole

 

# appender definitions

log4j.appender.myConsole=org.apache.log4j.ConsoleAppender

log4j.appender.mySyslog=org.apache.log4j.net.SyslogAppender

log4j.appender.myFile = org.apache.log4j.RollingFileAppender

 

# myConsole config

log4j.appender.myConsole.layout=org.apache.log4j.PatternLayout

log4j.appender.myConsole.layout.ConversionPattern=%p %t %c - %m%n

 

# mySyslog config

log4j.appender.mySyslog.layout=org.apache.log4j.PatternLayout

log4j.appender.mySyslog.layout.ConversionPattern=%p %t %c - %m%n

log4j.appender.mySyslog.SyslogHost=localhost

log4j.appender.mySyslog.Facility=USER

log4j.appender.mySyslog.threshold=INFO

 

# myFile config

log4j.appender.myFile.File = example.log

log4j.appender.myFile.MaxFileSize = 100KB

log4j.appender.myFile.MaxBackupIndex=1

log4j.appender.myFile.layout=org.apache.log4j.PatternLayout

log4j.appender.myFile.layout.ConversionPattern=%p %t %c - %m%

Syslog サーバでのロギング

ホスト Syslog サーバへのメッセージをログに記録するには、Syslog サーバの機能を使用します。たとえば、ワークステーションからホスト Syslog サーバにメッセージをロギングできます。

次のセクションでは、ホスト Syslog サーバにメッセージをロギングする C または Java コードについて説明します。

「C:Syslog サーバ」

「Java:Syslog サーバ」

C:Syslog サーバ

C プログラムでホスト Syslog サーバにログ メッセージを転送するには、/etc/syslog.conf または /etc/syslog-ng.conf で Syslog サーバの config ファイルを設定します。これらのロケーション名は、仮想インスタンスの Syslog サーバが syslog-ng の場合に適用されます。「ロギング」を参照してください。

リダイレクト:例

ファシリティが「local1」、プライオリティ値が「info」以上のすべてのログ メッセージをリダイレクトするには、Syslog サーバのコンフィギュレーション ファイルに次の行を追加します。

local1.info @myblade
 

Java:Syslog サーバ

Java プログラムで、ホスト Syslog サーバにログ メッセージを転送するには、log4j パッケージの log4j.properties ファイルを編集します(Java:log4jを参照)。次に例を示します。

log4j.rootLogger=DEBUG, mySyslog
 
# mySyslog config
log4j.appender.mySyslog.layout=org.apache.log4j.PatternLayout
log4j.appender.mySyslog.layout.ConversionPattern=%p %t %c - %m%n
log4j.appender.mySyslog.SyslogHost=myblade
/* Note the SyslogHost is “myblade” compared to “localhost” used by logging in the virtual instance */
log4j.appender.mySyslog.Facility=USER
log4j.appender.mySyslog.threshold=INFO
 

アプリケーション コードを変更する以外に、ホスト Syslog サーバを実行するには Cisco AXP サービス モジュール上でコマンドを実行する必要があります。

blade# config terminal
(config)# syslog-server
 

リモート Syslog サーバの状態を表示するには下記を入力します。

blade# show syslog-server
Syslog Server
Status: RUNNING
 

循環させるファイル数およびファイル サイズを設定するには下記を入力します。

blade# config terminal
(config)# syslog-server limit file-rotation 2 file-size 500
 

file-rotation の範囲は 1 ~ 40 です。デフォルト値は 10 です。

file-size の範囲は 1 ~ 1000 MB です。デフォルト値は 20 MB です。

バンドリングおよびパッケージ化

バンドリングは、複数のパッケージをグループとしてまとめて、Cisco AXP サービス モジュールにインストールできるようにする動作です。ここで説明する内容は、次のとおりです。

「バンドリング」

「パッケージ ツール」

「バンドリング ツール」


) 目次に戻るには、ここをクリックしてください。


バンドリング

バンドリングは、Cisco AXP ホスト オペレーティング システムを含め、または含めずに、複数のパッケージをグループとしてまとめる動作です。ここでは次の 2 種類の主要なバンドリングの例について、簡単に説明します。

「Cisco AXP ホスト OS を含むバンドリング」

「Cisco AXP ホスト OS を含まないバンドリング」


) (シスコが開発した)署名入りインフラストラクチャ アドオン パッケージを、(サードパーティが開発した)署名入りアドオン アプリケーションとともにバンドリングしなかった場合、サービス モジュールにそのバンドルをインストールすることはできません。つまり、シスコが開発したパッケージだけからなるバンドルはインストールできません。


Cisco AXP ホスト OS を含むバンドリング

サードパーティが開発した署名入りアドオン アプリケーションのインストールを含め、Cisco AXP ホスト OS を含むバンドルをサービス モジュールにインストールするには、コマンド software install clean を使用します。『 Cisco AXP User Guide 』の「Installing and Upgrading Software」を参照してください。

クリーン インストール後は、スタートアップ コンフィギュレーションが出荷時の設定に戻ります。結果は write erase コマンドの場合と同様です。

Cisco AXP ホスト OS

Cisco AXP ホスト OS + 署名入りアドオン アプリケーション(サードパーティが開発)

Cisco AXP ホスト OS + 署名入りインフラストラクチャ アドオン パッケージ(シスコが開発)+ 署名入りアドオン アプリケーション(サードパーティが開発)、署名入りインフラストラクチャ アドオン パッケージ(シスコが開発)への依存関係の有無

Cisco AXP ホスト OS + 署名入りインフラストラクチャ アドオン パッケージ(シスコが開発)+ 署名入りアドオン アプリケーション(サードパーティが開発)、下記への依存関係の有無

他の署名入りインフラストラクチャ アドオン パッケージ(シスコが開発)

署名入りアドオン パッケージ(サードパーティが開発)


) 署名入りアドオン パッケージ(サードパーティによる)は、署名入りインフラストラクチャ アドオン パッケージ(シスコによる)および同じサードパーティによる基本アプリケーションに依存できます。あるサードパーティが署名したアドオン パッケージが、別のサードパーティが署名したアプリケーションに依存することはできません。署名入りアドオン パッケージ(サードパーティによる)が同時に複数のアプリケーションに依存することはできません。署名入りアドオン パッケージ(サードパーティによる)がアドオン パッケージ(サードパーティによる)に依存することはできません。すなわち、チェーン依存関係は認められません。(サードパーティが署名した)基本アプリケーションが(サードパーティが署名した)アドオン パッケージに依存することはできません。



) ソフトウェア インストールの許可が適用されるのは、Certificate Authority(CA; 認証局)がすでに署名した X.509 証明書に限られます。また証明書の一部とすることはできません。



) サードパーティには、各自の X.509 証明書をシスコに提出し、アプリケーション パッケージにシスコの許可チェックサムを含める義務があります。


Cisco AXP ホスト OS を含まないバンドリング

サードパーティが開発した署名入りアドオン アプリケーションのインストールを含み、Cisco AXP ホスト OS を 含まない バンドルをサービス モジュールにインストールするには、コマンド software install add を使用します。

署名入りアドオン アプリケーション(サードパーティが開発)

署名入りインフラストラクチャ アドオン パッケージ(シスコが開発)+ 署名入りアドオン アプリケーション(サードパーティが開発)、署名入りインフラストラクチャ アドオン パッケージ(シスコが開発)への依存関係の有無

署名入りインフラストラクチャ アドオン パッケージ(シスコが開発)+ 署名入りアドオン アプリケーション(サードパーティが開発)、署名入りインフラストラクチャ アドオン パッケージ(シスコが開発)への依存関係の有無 + インフラストラクチャ アドオン パッケージ(シスコが開発)または署名入りアドオン アプリケーション(サードパーティが開発)、あるいはその両方に依存する可能性のある、署名入りアドオン パッケージ(サードパーティが開発)

同じサードパーティが作成して署名したものであれば、複数のアプリケーションをまとめてバンドリングできます。

サードパーティのアドオンは、単独でバンドリングすることも、対応する基本アプリケーション(複数可)と組み合わせてバンドリングすることもできます。

「Cisco AXP ホスト OS を含むバンドリング」の最初の(注)を参照してください。サードパーティのアドオン パッケージを作成してバンドリングする場合の、依存関係に関する制約事項が指定されています。

パッケージ ツール

次のモードのどちらかを使用して、パッケージ ツール コマンド(pkg_build.sh)をコールします。

1. シングル コマンドライン モード: コマンド pkg_build.sh <list of arguments> を入力します。

2. インタラクティブ モード: コマンド pkg_build.sh を入力し、各引数を別々に(1 行に 1 つの引数ずつ)入力します。


) パッケージ ツールを実行する前に、PATH 環境変数でストリングの先頭にシステム パスが指定されているかどうかを確認します。パス環境変数の値を調べるには、次のように入力します。
>echo $PATH
次のパス値が表示されます。
>/bin:/sbin:/usr/bin:/usr/local/sbin:/usr/sbin



) Bash スクリプトをパッケージ化している場合、パッケージ ツールは Bash スクリプトのバージョンが 3.0 以上であることを要求します。


パッケージ ツールに与えられた値によって、パッケージのインストール時にパッケージ化したアプリケーションに割り当てられるリソースが決まります。リソース割り当てを変更する方法は、再パッケージ化だけです。

アップグレード

アプリケーションをアップグレードする場合は、パッケージ ツールの検討すべき引数/パラメータが 3 つあります。

1. uuid:パッケージを最初に作成したときの uuid を入力します。使用した uuid を調べるには、コマンド show software versions detail を使用します(『 Cisco AXP User Guide 』の「Verifying and Troubleshooting System Status」を参照)。

2. name:パッケージを最初に作成したときに使用したのと同じ名前で、パッケージ名を入力します。

3. version:アップグレードしたアプリケーションには、サービス モジュール上のアプリケーションとは異なるバージョンである必要があります。

その他の引数には、deps、disk-limit、および cpu-limit があります。各引数の詳細については後述します。


) パッケージの作成後、pkg_info.sh を使用すると、パッケージの内容を確認できます。「Package Information」を参照してください。


次にパッケージ ツールについて説明します。

「パッケージ ツールの引数」

「依存関係」

「ディスク限度」

「CPU 限度」

「パッケージ ツール コマンド:例」

パッケージ ツールの引数

表17 で、パッケージ ツールの引数について説明します。

 

表17 パッケージ ツールの引数

引数
概要
説明

project-dir

プロジェクト ディレクトリ

パッケージ ファイル、テンプレート、およびパッケージ化実行時に作成された一時ファイルが置かれます。

 

dev-cert

開発証明書の保管場所

Cisco AXP 上のソフトウェア開発を許可する X.509 証明書

/xyz_source/x509.cer

dev-auth

ソフトウェア開発許可ファイルの保管場所

証明書の所持者に Cisco AXP 対応ソフトウェアの開発を許可するバイナリ ファイル

/xyz_source/dev_auth

private-key

秘密鍵ファイルの保管場所

アプリケーション サードパーティ ソフトウェアの署名に使用する RSA 鍵を含むファイル

/xyz_source/privkey.txt

name

アプリケーション名

パッケージ化するアプリケーションの名前

myapp

version

アプリケーションのバージョン

パッケージ化するアプリケーションのバージョン

1.0

description

(任意)アプリケーションの説明

アプリケーションの機能の説明

myapp utility

uuid

(任意)アプリケーションの UID(固有識別情報)

1. uuid 値を入力できます。Linux の uuidgen ツールを使用して生成された uuid などです。こちらの方法を推奨します。表の下の(注)を参照してください。または、

2. uuid をブランクにしておくこともできます。ID が自動的に生成されます。

 

source-dir

アプリケーション ファイルの場所

パッケージ化するアプリケーション ファイルが置かれているディレクトリ。ディレクトリ構造は、対象のファイル システム上の所定のディレクトリ構造とミラーリングする必要があります。

/xyz_source/root_fs

protect

(任意)保護するファイルのリスト

アプリケーションの初期化前に、改ざんの有無を調べるファイルのリスト(1 行に 1 ファイル)を指定した、プレーン テキスト ファイル

 

deps

(任意)パッケージの依存関係

「依存関係」 を参照してください。

<dependency list>、例については「依存関係」を参照してください。

disk-limit

ディスク限度

アプリケーションに最小限必要なディスク スペース。disk-limit の詳細については、「ディスク限度」を参照してください。

10 M

memory-limit

メモリ限度

RAM の使用限度。メモリ限度を選択するときには、対象のハードウェアのリソースを考慮してください。要求したリソース容量が対象のハードウェアで使用できなかった場合、アプリケーションのインストールまたは実行に失敗する可能性があります。
(1 M = 1048576 バイト)

10 M

cpu-limit

CPU 限度

アプリケーションが使用する CPU リソース。CPU 限度については、「CPU 限度」を参照してください。

200

postinstall

(任意)ポストインストール スクリプト

(任意)インストール後に実行するスクリプト

共通ルート ディレクトリに対する相対パスを使用して、スクリプトの場所を指定します。たとえば、スクリプト postinstall.sh がディレクトリ
/source/build/bin にあり、共通ルート ディレクトリが /source/build の場合、スクリプトの場所を /bin/postinstall.sh と指定します。

/bin/postinstall.sh

依存関係

依存関係パラメータ(deps)のリストは、SDK およびプロジェクト ディレクトリから選択できるパッケージで構成されます。開発ワークステーション上にすでに存在しているパッケージを指定する場合は、そのパッケージの UUID およびファイル名を指定できます。各依存関係のあとに、次の依存関係タイプのいずれか 1 つを指定する必要があります。

From [version]:依存関係は指定されたバージョンまたはそれ以降のバージョンでなければなりません。

To [version]:依存関係は指定されたバージョンまたはそれ以前のバージョンでなければなりません。

Exclude [version]:指定されたバージョンの他の依存関係があるパッケージはインストールできません。

Only [version]:依存関係は指定されたバージョンでなければなりません。

None:指定された依存関係のあるパッケージはインストールできません。

All:パッケージをインストールするには、すべてのバージョンの依存関係が存在していなければなりません。

バージョン

各アプリケーション パッケージにはバージョン番号があります。インストーラは、サブシステム間の依存関係を解決するときに、このバージョン番号を使用します。

依存関係チェックでは、バージョン番号の最初の 2 桁だけが調べられます。

1 桁めは Major バージョン番号、2 桁めは Minor バージョン番号として扱われます。

たとえば、バージョン 1.2.3.4 の場合、Major 番号が 1、Minor 番号が 2 であり、依存関係チェックでは、バージョン 1.2 またはバージョン 1.2.3 と同じ扱いになります。

依存関係リスト:構文

[依存関係リスト] =>(1 つまたは複数のコロン「:」)で区切られた[依存関係ストリング][依存関係ストリング]=>[依存関係 UUID],(1 つまたは複数のカンマ「,」)で区切られた[依存関係タイプ][依存関係タイプ]=> [to/from/exclude/only/none/all](=[バージョン])

依存関係リスト:例

--deps 'cc1b5b06-6b17-42c9-b9dd-88c29674b390,from=1.0,to=2.0: b569b32d-1b5b-4306-8eb6-c7d6808aa7b6,only=3.0'
 

ディスク限度

ディスク限度を計算するときには、次のコンポーネントに必要なディスク スペースを考慮してください。アプリケーション パッケージ(シスコのパッケージが使用するディスク スペース以外)、ログ ファイル、およびコア ダンプです。

ディスク限度は、アプリケーションに最小限必要なディスク スペースです。ディスク リソースがこの限度を下回っている場合は、アプリケーションをインストールできません。ディスク限度は、「1 M」のように、メガバイト単位で指定する必要があります。

CPU 限度

パッケージ ツールの cpu-limit 引数によって、CPU インデックス ポイントで測定される、アプリケーション パッケージの CPU 使用率が設定されます。

cpu-limit は、アプリケーションの最小 CPU 限度です。最小 CPU 限度で、アプリケーションに割り当てる CPU リソースの最小容量を指定します。対象のサービス モジュール上で使用できる CPU リソースが CPU 限度を下回っている場合は、アプリケーションをインストールできません。

サービス モジュールの CPU インデックスは、既知の値であり、ベンチマークに基づいて計算されています。強力なサービス モジュールほど CPU インデックスが大きくなり、対応できる並行アプリケーションの数も増えます。詳細については、「専用のアプリケーション リソース」を参照してください。

CPU インデックスは、CPU の能力に基づいて各サービス モジュールに割り当てられます。アプリケーションの CPU インデックスは、次の公式に基づいて計算します。

アプリケーション CPU インデックス =(サービス モジュールの)CPU インデックス × CPU 使用率(%)

たとえば、NME APPRE 302 サービス モジュールの CPU インデックスは 10000 です。各サービス モジュールの CPU インデックスは、10000 の値に比例します。アプリケーションに 60% の CPU 使用率が必要な場合、アプリケーションの CPU インデックスは 10000 × 60% = 6000 です。この値を cpu-limit 引数として指定します。

アプリケーションの CPU インデックスを把握しておくと、他のサービス モジュールにアプリケーション パッケージをインストールでき、モジュールに十分な CPU リソースがあれば、アプリケーション パッケージが正常に動作することを予見ができるというメリットがあります。

パッケージ ツール コマンド:例

echo $PATH
//the next line shows example output
/bin:/sbin:/usr/bin:/usr/local/sbin:/usr/sbin
 
/source/axp_tools/appre-sdk.nme.1.0.1/tools/pkg_build.sh --project-dir '/source/helloworld_app/package' --dev-cert '/source/helloworld_app/certs/dev_certificate' --dev-auth '/source/helloworld_app/certs/dev_authorization' --private-key '/source/helloworld_app/certs/private.key' --name 'helloworld' --version '1.0' --description 'hello hello' --source-dir '/source/helloworld_app/build' --disk-limit '10M' --memory-limit '10M' --cpu-limit '100' --postinstall '/bin/post-install.sh'

バンドリング ツール

バンドリング ツール(pkg_bundle.sh)は、複数のパッケージを 1 つのバンドルにまとめます。バンドリング ツールを使用するには、引数のリストを使い、単一のコマンドラインを入力します。引数については、 表18 を参照してください。

 

表18 バンドリング ツール コマンドの引数

パラメータ
概要
説明

help

バージョンおよび用途

 

project-dir

プロジェクト ディレクトリ

project-dir パラメータおよび「/pkg」を追加して指定されたサブディレクトリに、パッケージ化実行時に作成されたパッケージ ファイル、テンプレート、および一時ファイルを保管します。「バンドリング ツール:例」 を参照してください。

private-key

秘密鍵ファイルの保管場所

セキュリティ ヘッダーおよびパッケージ指定に使用する RSA 鍵を含むファイル

output

出力パッケージ

パッケージのリスト。最初の名前には、結合されたパッケージ「バンドル」の名前が入ります。パス名が指定されていない場合、または無効な場合、パッケージが書き込まれるディレクトリは project-dir/pkg です。「output」に続くパラメータ値リストの 2 番めおよびそれ以降の名前は、バンドルを構成する他のパッケージの名前です。prt1、prt2 などのペイロード ファイルは、対応するパッケージ ファイルと同じディレクトリに置く必要があります。

バンドリング ツール:例

次の例では、2 種類のパッケージ iosapi_test.1.1.pkg および axp-iosapi.nme.1.0.4.pkg を、iosapi_test_bundle.1.0.4.pkg にバンドルします。このバンドルは、プロジェクト ディレクトリ /iosapi_app/package/pkg に配置されます。


) --project-dir 内にパラメータにディレクトリ /iosapi_app/package を指定した場合、パッケージは /iosapi_app/package/pkg に格納されます。


/axp-sdk.1.0.4/tools/pkg_bundle.sh --project-dir '/iosapi_app/package' --private-key '/certs/private.key' --output 'iosapi_test_bundle.1.0.4.pkg' '/iosapi_app/package/pkg/iosapi_test.1.1.pkg' '/bryce/axp-iosapi.nme.1.0.4.pkg'

パケット分析

ここでは、Cisco AXP のトラフィック フィルタリングおよびパケット分析について説明します。

「RITE トラフィック フィルタリングおよびサンプリング」

「パケット モニタリングおよび分析」


) 目次に戻るには、ここをクリックしてください。


RITE トラフィック フィルタリングおよびサンプリング

Cisco AXP は RITE(Router IP Traffic Export)をサポートします。RITE は、トラフィック フィルタリングおよびサンプリングをサポートする、Cisco IOS ソフトウェア エクスポート ツールです。RITE は監視対象インターフェイス上のトラフィックを複製してエクスポートします。Cisco AXP サービス モジュールが使用する Integrated-Service-Engine(統合サービス エンジン)インターフェイスは、イーサネット インターフェイスのように動作し、RITE でサポートされます。RITE を使用すると、(Cisco AXP Promiscuous Packet API と異なり)Cisco ISR に分析モジュールを接続する必要がなくなります。

RITE の機能は、次のとおりです。

インバウンド、双方向、またはアウトバウンドのトラフィックのモニタリング

エクスポート インターフェイスの指定

ACL フィルタリングおよびサンプリング レートの制御

イーサネット インターフェイスのように動作する Integrated-Service-Engine インターフェイスを含め、さまざまなカプセル化タイプのインターフェイスを監視する機能

インターフェイスとしての vlan 指定

トラフィック サンプリング時に、 n パケットごとに 1 回のサンプリング

インターフェイスにプロファイルを適用する前の簡易プロファイル キャプチャ

Cisco AXP Promiscuous Packet API を使用する場合に比べて、いっそう粒度の細かいトラフィック キャプチャ

ユーザによる ACL、サンプリング レート、およびキャプチャするトラフィックの方向(インバウンド/アウトバウンド)の指定

ただし、RITE の使用には 1 つ制約があります。RITE はルータが生成したトラフィックをキャプチャしません。ルータが生成したパケットは、cef スイッチドではなく、プロセス スイッチドです。

RITE の設定

RITE 設定の詳細については、『 Cisco AXP User Guide 』の「Configuring Router IP Traffic Export」を参照してください。


) RITE がルータによって生成されたトラフィックをキャプチャしないのは、ルータによって生成されたパケットが cef スイッチドではなく、プロセス スイッチドのためです。また、1 つのプロファイルに使用できるエクスポート インターフェイスは 1 つだけであり、プロファイルは監視対象インターフェイスごとに 1 つだけです。


次に、RITE の設定について説明します。

「RITE キャプチャ プロファイルの作成」

「RITE キャプチャ プロファイル パラメータの設定」

「インターフェイスへの RITE キャプチャ プロファイルの適用」

RITE キャプチャ プロファイルの作成

プロファイルの作成:

ip traffic-export profile <your-profile-name>
 

エクスポート用インターフェイスの設定:

interface Integrated-Service-Engine 1/0
 

Integrated-Service-Engine1/0 インターフェイスの MAC アドレスの設定:

mac-address <address>

) 上記コマンドでの、mac-address は Cisco AXP サービス モジュールの有効な MAC アドレスです。


ただし、サービス モジュールは Cisco AXP Promiscuous Packet API を使用して設定するので、無効な MAC アドレスを指定してコマンドを実行しても、コマンドは動作します。

MAC アドレス a.a.a

Cisco AXP サービス モジュールは、デフォルトでパケットをルーティングするように設定されるので、有効な MAC アドレスを設定すると、サービス モジュールのルーティング スタックがトラフィックをルーティングします。その結果、重複パケットがルーティングされるという状況が発生します。重複パケットのルーティングを避けるために、無効な MAC アドレスを設定することを推奨します。無効な MAC アドレスの例は a.a.a です。無効な MAC アドレスを使用すると、パケットが Cisco AXP サービス モジュールに到達してもルーティングされません。

インバウンド トラフィックとアウトバウンド トラフィックの両方をキャプチャする場合は、インターフェイスを双方向として設定します(デフォルトは着信のみ)。

RITE キャプチャ プロファイルの作成:例

jc1(config)#ip traffic-export profile rite-bi
jc1(conf-rite)#?
IP traffic export profile configuration commands
bidirectional Enable bidirectional traffic export
exit Exit from ip traffic export profile sub mode
incoming Configure incoming IP traffic export
interface Specify outgoing interface for exporting traffic
mac-address Specify ethernet address of destination host
no Negate or set default values of a command
outgoing Configure outgoing IP traffic export
 
ip traffic-export profile rite-bi
interface Integrated-Service-Engine1/0
bidirectional
mac-address a.a.a
!
 

RITE キャプチャ プロファイル パラメータの設定

RITE キャプチャ プロファイルを設定するには、エクスポート インターフェイス、発信 MAC アドレス、およびアクセス リストまたはサンプリングのパラメータを設定します。

着信または発信トラフィック サンプリングをアクセス リストとして、またはサンプル レートとして設定します。

access-list:標準 ACL

sample:エクスポート トラフィックのサンプル レート

RITE キャプチャ プロファイル パラメータの設定:例

jc1(config)#ip traffic-export profile rite-bi
jc1(conf-rite)#incoming ?
 
access-list Apply standard or extended access lists to exported traffic
sample Enable sampling of exported traffic
 
ip traffic-export profile rite-bi
interface Integrated-Service-Engine1/0
bidirectional
incoming access-list 4
outgoing access-list 4
mac-address a.a.a
incoming sample one-in-every 2
outgoing sample one-in-every 2
!

インターフェイスへの RITE キャプチャ プロファイルの適用

インターフェイスを監視するには、インターフェイスにプロファイルを適用する必要があります。

ip traffic-export apply <profile name>
 

インターフェイスへの RITE キャプチャ プロファイルの適用:例

interface GigabitEthernet0/0
description $ETH-LAN$$ETH-SW-LAUNCH$$INTF-INFO-GE 0/0$
ip address 1.100.50.221 255.255.255.0
ip traffic-export apply rite-bi
duplex auto
speed auto
no keepalive
end

パケット モニタリングおよび分析

Cisco AXP のパケット モニタリングは、Cisco IOS 環境でのパケット モニタリングと類似しています。

Cisco AXP サービス モジュール インターフェイス上でパケット モニタリングをイネーブルにする方法については、『 Cisco AXP User Guide 』の「Packet Analysis」を参照してください(たとえば、インターフェイス コンフィギュレーション モードで analysis-module monitoring コマンドを使用します)。

Cisco AXP Promiscuous Packet API は、着信および発信トラフィックを設定されたインターフェイスにエクスポートし、ローカル ルータが生成したパケットをエクスポートします。「混合モード Packet API」を参照してください。

混合モード Packet API

カーネルは、下記の直接アクセス可能な機能を使って設定されます。

raw ソケット インターフェイス(CONFIG_RAW)

raw ソケット メモリ マップ モード(CONFIG_RAW_MMAP)

ソケット フィルタリング(CONFIG_FILTER)

raw ソケット インターフェイスは、libpcap および MMAP パケット アクセスの上位レベル抽象と互換性があります。libpcap/tcpdump の詳細については、次の資料を参照してください。

libpcap/tcpdump: http://www.tcpdump.org

マニュアルの man 3 pcap のページなど

チュートリアル:

http://yuba.stanford.edu/~casado/pcap/section1.html


) 仮想インスタンス内部で動作するアプリケーションは、raw ソケットを使用して、Cisco AXP サービス モジュール上で使用可能なあらゆるネットワーク インターフェイスを監視できます。


raw ソケット:例

#include <stdio.h>
#include <sys/socket.h>
#include <sys/types.h>
#include <linux/if_ether.h>
#include <linux/if_arp.h>
#include <errno.h>
 
int main (int argc, char* argv[]){
int result = 0;
int s = socket(AF_PACKET, SOCK_RAW, htons(ETH_P_ALL));
if(s != -1){
struct sockaddr_ll socket_address;
socket_address.sll_family = AF_PACKET;
socket_address.sll_protocol = htons(ETH_P_ALL);
bind(s, (struct sockaddr*) &socket_address, sizeof(socket_address));
char* buffer= (char*)malloc(ETH_FRAME_LEN+1);
int length=recvfrom(s, buffer, ETH_FRAME_LEN,0,NULL,NULL);
}
else{
printf("Socket creation error %d\n",errno);
result = s;
}
return result;
}

デバッグ ツール

デバッグ ツールは、次のインフラストラクチャ アドオン パッケージに含まれています。

axp-ssh-4.6p1-k9.<platform>.<version>.pkg

axp-app-dev.<platform>.<version>.pkg

次にデバッグ ツールについて説明します。

「SSH トンネリング」

「rsync」

「GDB のデバッグ」


) 目次に戻るには、ここをクリックしてください。


SSH トンネリング

デバッグ環境または開発環境では、Cisco AXP はフル シェル アクセスでの SSH サーバ アクセスを提供します。ユーザは root として仮想インスタンスにログインできます。

実稼働環境

実稼働環境では、tunnel_user SSH ユーザ用のパッケージ axp-ssh-4.6p1-k9.<platform>.<version>.pkg を使用します。

このパッケージに、SSH ログイン時のシェル アクセス権はありません。開発者が、SSH ログイン後に実行する起動スクリプトを記述して、tunnel_user が実行できる作業を制御します。

開発環境

開発環境では、tunnel_root SSH ユーザは、パッケージ axp-app-dev.<platform>.<version>.pkg を使用します。

このパッケージは、SSH ログイン時に仮想インスタンスにシェル アクセス権を与えます。「アプリケーション開発パッケージ」を参照してください。

フォワーディングの例

仮想インスタンスの SSH トンネリング オプションは 2 つあります。

ポート フォワーディング「ssh-L」

X11 フォワーディング「ssh-X」

各オプションの詳細については、SSH の次のマニュアル ページを参照してください。

http://www.die.net/doc/linux/man/man1/ssh.1.html

ポート フォワーディング:例

workstation-shell# ssh -L <local port>:<host>:<host port> <user>@<host> -p <port>
workstation-shell# ssh -L 7777:localhost:8888 tunnel_root@myblade -p 2022
 

X11 フォワーディング:例

workstation-shell# ssh -X <user>@<host> -p <port>
workstation-shell# ssh -X tunnel_root@myblade -p 2022
vserver-shell# xterm &
 

仮想インスタンスでの SSH サーバの設定

SSH サーバを実行するように仮想インスタンスを設定する手順は、次のとおりです。


) 次の手順では、<name> に使用するアプリケーションの名前を指定します。



ステップ 1 アプリケーション開発パッケージ axp-app-dev.<platform>.<version>.pkg の依存関係を使用して、アプリケーションをパッケージ化します。

ステップ 2 アプリケーションおよび axp-app-dev.<platform>.<version>.pkg をインストールします。

ステップ 3 仮想インスタンスにインターフェイスをバインドします。

blade# configure terminal
(config)# app-service <name>
(config-myapp)# bind interface eth0
(config-myapp)# end
 

ステップ 4 パスワードを設定して、ユーザ tunnel_root をアクティブにします。

blade# configure terminal
(config)# app-service <name>
(config-myapp)# ip ssh username tunnel_root password hello
(config-myapp)# end
 

ステップ 5 パスワードを設定して、ユーザ tunnel_user をアクティブにします。

blade# configure terminal
(config)# app-service <name>
(config-myapp)# ip ssh username tunnel_user password hello
(config-myapp)# end
 

ステップ 6 仮想インスタンスの SSH サーバをイネーブルにします。

blade# config terminal
(config)# app-service <name>
(config-myapp)# ip ssh server
(config-myapp)# end
 

ステップ 7 仮想インスタンスの SSH サーバが動作していることを確認します。

blade# app-service <name>
(myapp)# show ssh-server
Application SSH Server
Status: RUNNING
 

ステップ 8 これで仮想インスタンスの SSH サーバに接続できるようになりました。使用するデフォルト ポートは 2022 です。

ユーザは次のいずれかの方法で接続します。

a. SSH ユーザとしてユーザ tunnel_root に接続し、シェル アクセス権を取得します。

workstation-shell# ssh tunnel_root@myblade -p 2022
tunnel_root@myblade's password:
vserver-shell#
 

b. 起動スクリプトを使用し、SSH ユーザとしてユーザ tunnel_user と接続して、アクセス権を取得します。

起動スクリプト /usr/ssh/home/tunnel_user_app_startup.sh に応じてメッセージが表示されます。

たとえば、 tunnel_user_app_startup.sh:例 1 の起動スクリプト例の場合、メッセージ「Welcome Tunnel User!」が表示されます。メッセージの表示後、起動スクリプトの残りのコマンドが処理されます。


 

SSH トンネリングの例

tunnel_user_app_startup.sh:例 1

#!/bin/bash
echo "Welcome Tunnel User!"
echo "Please enter 1 to do a 'pwd', or 2 to do a 'ls'"
read choice
if [ $choice -eq 1 ]; then
pwd
else
ls
fi
 

tunnel_user_app_startup.sh:例 2

スクリプトで SSH トンネル アプリケーションを直接呼び出せます。

#!/bin/bash
xterm
 

tunnel_user_app_startup.sh:例 3

スクリプトをインタラクティブにすると、ユーザがさまざまなコマンドの呼び出しを選択できます。

#!/bin/bash
echo “Please enter 1 to start xterm, or 2 to start ethereal”
read choice
if [ $choice -eq 1 ]; then
xterm -a abc
else
ethereal -l abc -b -D
fi
 

SSH ユーザとして tunnel_user を使用する場合の入力/出力:例

 
workstation-shell# ssh tunnel_user@myblade -p 2022
tunnel_user@myblade's password:
=====Start of message from the Cisco AppRE Application SSH Support=====
Tunnel User (tunnel_user) has logged in successfully
Application specific Tunnel User startup script will be invoked (if exists)
=====End of message from the Cisco AppRE Application SSH Support=======
Welcome Tunnel User!
Please enter 1 to do a 'pwd', or 2 to do a 'ls'
2
tunnel_user_app_startup.sh tunnel_user_startup.sh
tunnel_user_app_startup.sh.sample
Connection to myblade closed.
workstation-shell#
 

rsync

rsync は、サービス モジュール上の仮想インスタンスと開発ワークステーション間でファイルを同期させるユーティリティです。

開発中に開発ワークステーションから仮想インスタンスに、コードを移動できます。あとで、仮想インスタンス上のコードを変更した場合は、開発ワークステーション上のコードと同期させることができます。

rsync を使用してファイルを同期させる前に、予め完了しておかなければならない手順については、『 Cisco AXP User Guide 』を参照してください。rsync をアクティブにするには、 sync コマンドを使用します。

手順の概要

1. app-service application-name

2. sync file url rsync: host_url direction [ in | out ] username username

3. exit

rsync:例

exec-appname> sync file url rsync://10.1.1.1/source/container direction in username john

 

この例では、仮想インスタンスのコンテンツが開発ワークステーション(アドレス 10.1.1.1)にあるディレクトリ /source/container によって上書きされます。 direction in で、ワークステーションのコンテンツをマスター ファイルとして使用することを指定します。


) 仮想インスタンスの動作中に、ワークステーションからサービス モジュールに同期させた場合、libc など、一部のライブラリが予期どおりに動作しないことがあります。システムの動作中は同期させないことを推奨します。


システム ライブラリのアップデート

サービス モジュール上のシステム ライブラリをアップデートするには、システム ライブラリをアプリケーションの中にパッケージ化して、アプリケーションをインストールします。

libc ライブラリのアップデートが必要な場合は、libc に関連するライブラリおよび libc に依存するライブラリもアップデートします。これらのライブラリをアップデートすれば、実行時にライブラリ バージョンの不一致は発生しなくなります。

たとえば、libc をアップデートする場合は、libpthread、libm、libdl、libresolv などの関連ライブラリもアップデートします。libc 関連ライブラリの詳細については、libc のマニュアルを参照してください。URL: http://www.gnu.org/software/libc/

GDB のデバッグ

「gdbserver」が提供するリモート デバッグ サービスによって、リモート デバッガ クライアントは Cisco AXP サービス モジュール上のアプリケーションに接続し、アプリケーションの実行を制御できます。OpenSSH ソフトウェアを使用する SSH トンネルによって、セキュアな接続が確保されます。SSH トンネルにより、ファイアウォールを通過する場合も含め、Cisco AXP サービス モジュールの場所に関係なくアプリケーションをデバッグできます。SSH トンネル認証は、パスワード認証を使用します。

デバッグ サービス「gdbserver」は、C/C++ で作成されたアプリケーションをサポートします。リモート デバッグは、Bash、Perl、Python、TCL、PHP などのスクリプト言語で記述された解釈型(非コンパイル型)アプリケーションに関しては、サポートされません。

リモート Java デバッグを使用する場合は、jdb などのリモート デバッガを組み込むか、またはアプリケーションでリモート デバッグ スタブをコンパイルする必要があります。リモート デバッガを提供するサードパーティ製のアプリケーションと組み合わせて SSH トンネルを使用し、デバッグ セッションを保護することは可能です。

SSH トンネリングを使用する場合の gdb および gdbserver の使用方法の詳細については、
http://www.cucy.net/lacp/archives/000024.html を参照してください。

GDB デバッグ ユーティリティでは、gdbserver および gdb コマンドを使用してデバッグを行います。

SSH トンネル経由で仮想インスタンスに接続します。

「gdb」の実行手順は、次のとおりです。


ステップ 1 gdbserver を使用し、仮想インスタンス上で動作しているアプリケーションでデバッグ セッションを確立します。「gdb の設定」を参照してください。

ステップ 2 SSH トンネル接続を作成します(ポート フォワーディングの「-L」オプションについては、SSH トンネリングおよびSSH トンネル接続 の例を参照してください)。

ステップ 3 ワークステーション上で「gdb」を実行し、SSH トンネルに接続します。「開発ワークステーションでの GDB の実行」を参照してください。


 

gdb の設定

次に、GDB デバッグ セッションを開始し、ssh トンネル接続を確立して、開発ワークステーションで gdb を実行する 2 通りの方法を示します。

tunnel_root GDB デバッグ セッション

tunnel_user GDB デバッグ セッション

SSH トンネル接続

開発ワークステーションでの GDB の実行

tunnel_root GDB デバッグ セッション

tunnel_root として仮想インスタンスの SSH サーバにログインし、gdbserver を手動で実行します。

次の例では、アプリケーション名は /my_app/debug です。

workstation-shell# ssh tunnel_root@myblade -p 2022
tunnel_root@myblade's password:
vserver-shell# gdbserver localhost:2222 /my_app/debug
Process /my_app/debug created; pid = 29165
Listening on port 2222
 

tunnel_user GDB デバッグ セッション

アプリケーション プロセス ID を使用し、ランタイム gdbserver バインドを実行する tunnel_user 起動スクリプトを設定します。それには次のコード例のように、tunnel_user 起動スクリプトを変更する必要があります。次の例では、アプリケーション名は「debug」です。

#!/bin/bash
pid=`ps -ef | grep debug | awk '{print $2}'`
echo "gdbserver will be running on process ${pid}, bound to port 2222"
gdbserver localhost:2222 --attach ${pid}
 

SSH トンネル接続

ポート 2222 が仮想インスタンス側の gdbserver にバインドされている場合、次の例のコマンドでワークステーションのポート 4567 からサービス モジュールのポート 2222 への SSH トンネルを設定します。

workstation-shell# ssh -L 4567:localhost:2222 tunnel_root@myblade -p 2022
 

開発ワークステーションでの GDB の実行

次の例は、「SSH トンネル接続」のコード例で示したように、ポート 4567 がワークステーション上の SSH トンネルにバインドされていることを前提とします。

workstation-shell-2# gdb
(gdb) file debug
(gdb) target remote localhost:4567
(gdb)
 

break、continue、step など、代表的な GDB コマンドを使用できます。

ここで紹介する例は、次のとおりです。

「GetRouterIP API:例」

「net-snmp:例」

「リモート シリアル デバイス:例」


) 目次に戻るには、ここをクリックしてください。


GetRouterIP API:例

関数 GetRouterIP( ) を使用して、Cisco IOS ルータの IP アドレスを取得します。GetRouterIP( ) はライブラリ /lib/libipcserviceapi.so にあります。

次の例では、インクルード文で ipcServiceAPI.h のインクルード ファイルを指定します。

#include <ipcServiceAPI.h>

 

C
unsigned int GetRouterIP( void);
 

Cisco IOS ルータの IP アドレスを取得します。

パラメータ:

なし

戻り値:

IP アドレスを表す 4 バイト値

#include <stdio.h>
#include <string.h>
#include <ipcServiceAPI.h>
 
#define maskA 0x000f
#define maskB 0x00f0
#define maskC 0x0f00
#define maskD 0xf000
main () {
 
unsigned int ip = GetRouterIP();
 
printf("Router ip address=%d.%d.%d.%d\n",
(maskA & ip) , ((maskB & ip) >> 8), ((maskC & ip) >> 16), ((maskD &
ip) >> 24 ));
}

net-snmp:例

この例では、ルータから MIB 情報を取得します。

SNMP バージョン 1 のコミュニティ ストリングを使用して、システム記述 MIB ノード ".1.3.6.1.2.1.1.1.0" の MIB 情報にアクセスします。

ルータでコミュニティ ストリング demopublic を設定する必要があります。

この例では、 1.2.3.4 はルータの IP アドレスです。SNMP_MSG_GET を使用して情報を取得します。

例で使用している net-snmp API は、次のとおりです。snmp_sess_init、snmp_open、snmp_perror、snmp_log、snmp_pdu_create、snmp_add_null_var、snmp_synch_response、snmp_errstring、snmp_sess_perror、snmp_free_pdu、snmp_close

 
// file snmpapp.c
 
#include <net-snmp/net-snmp-config.h>
#include <net-snmp/net-snmp-includes.h>
#include <string.h>
 
/* change the word "define" to "undef" to try the insecure SNMP version 1*/
#define DEMO_USE_SNMP_VERSION_3
 
#ifdef DEMO_USE_SNMP_VERSION_3
const char *our_v3_passphrase = "The UCD Demo Password";
#endif
 
int main(int argc, char ** argv)
{
struct snmp_session session, *ss;
struct snmp_pdu *pdu;
struct snmp_pdu *response;
 
oid anOID[MAX_OID_LEN];
size_t anOID_len = MAX_OID_LEN;
 
struct variable_list *vars;
int status;
int count=1;
 
/*
* Initialize the SNMP library
*/
init_snmp("snmpapp");
 
/*
* Initialize a "session" that defines who we're going to talk to
*/
snmp_sess_init( &session ); /* set up defaults */
session.peername = strdup("1.2.3.4");
 
/* set up the authentication parameters for talking to the server */
 
/* set the SNMP version number */
session.version = SNMP_VERSION_1;
 
/* set the SNMPv1 community name used for authentication */
session.community = "demopublic";
session.community_len = strlen(session.community);
 
/* Open the session */
SOCK_STARTUP;
ss = snmp_open(&session); /* establish the session */
 
if (!ss) {
snmp_perror("ack");
snmp_log(LOG_ERR, "something horrible happened!!!\n");
exit(2);
}
/*
* Create the PDU for the data for our request.
* 1) We're going to GET the system.sysDescr.0 node.
*/
pdu = snmp_pdu_create(SNMP_MSG_GET);
read_objid(".1.3.6.1.2.1.1.1.0", anOID, &anOID_len);
 
snmp_add_null_var(pdu, anOID, anOID_len);
/* Send the request*/
status = snmp_synch_response(ss, pdu, &response);
 
/* Process the response*/
if (status == STAT_SUCCESS && response->errstat == SNMP_ERR_NOERROR) {
/*
* SUCCESS: Print the result variables
*/
 
for(vars = response->variables; vars; vars = vars->next_variable)
print_variable(vars->name, vars->name_length, vars);
 
/* Manipulate the information */
for(vars = response->variables; vars; vars = vars->next_variable) {
if (vars->type == ASN_OCTET_STR) {
char *sp = (char *)malloc(1 + vars->val_len);
memcpy(sp, vars->val.string, vars->val_len);
sp[vars->val_len] = '\0';
printf("value #%d is a string: %s\n", count++, sp);
free(sp);
}
else
printf("value #%d is NOT a string! Ack!\n", count++);
}
} else {
/* FAILURE: print error*/
 
if (status == STAT_SUCCESS)
fprintf(stderr, "Error in packet\nReason: %s\n",
snmp_errstring(response->errstat));
else
snmp_sess_perror("snmpget", ss);
 
}
 
/* Clean up */
if (response)
snmp_free_pdu(response);
snmp_close(ss);
 
SOCK_CLEANUP;
return (0);
} /* main() */
 

リモート シリアル デバイス:例

次に、シリアル モデム デバイスをテストするアプリケーションのコード例を示します。

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <string.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <fcntl.h>
#include <termios.h>
#include <ctype.h>
#include <sys/time.h>
#include <stropts.h>
#include <sys/ioctl.h>
 
int serial_open(char *dev) {
int ttyfd;
 
if (dev == NULL) {
printf("\nDevice Empty");
return -1;
}
printf("Opening..%s",dev);
ttyfd = open (dev, O_RDWR | O_NONBLOCK | O_NOCTTY | O_NDELAY);
 
if (ttyfd < 0) {
perror("Device Open Failed: ");
return (-1);
}
fcntl(ttyfd, F_SETFL, 0);
return ttyfd;
}
 
int device_send(int ttyfd, char* data, int len) {
int n;
 
n = write(ttyfd, data, len);
if (n<0) {
perror("Device send failed: ");
return n;
}
 
printf("Send Worked: %d", n);
return 0;
}
 
int device_recv(int ttyfd) {
char data[128];
int r=0;
memset(data, 0, sizeof(data));
 
r = read(ttyfd, data, 128);
if (r<0) {
perror("device_recv failed: ");
return -1;
}
 
printf("\nReceived: %s, Len: %d", data, r);
return 0;
}
int modem_read (int fd) {
char buffer[255]; /* Input buffer */
char *bufptr; /* Current char in buffer */
int nbytes; /* Number of bytes read */
 
printf("\nReading...");
/* read characters into our string buffer until we get a CR or NL */
bufptr = buffer;
while ((nbytes = read(fd, bufptr, buffer + sizeof(buffer) - bufptr - 1)) > 0)
{
bufptr += nbytes;
if (bufptr[-1] == '\n' || bufptr[-1] == '\r')
break;
}
if (nbytes<0) {
perror("Modem Read Failed: ");
return (-1);
}
 
printf("\nModem Replied: %s", buffer);
return 0;
}
 
int select_data (int fd) {
struct timeval timeout;
int readsocks=0;
fd_set socks;
 
FD_ZERO(&socks);
FD_SET(fd,&socks);
timeout.tv_sec = 1;
timeout.tv_usec = 0;
 
while(1) {
readsocks = select(FD_SETSIZE+1, &socks, (fd_set *)0,(fd_set *) 0, &timeout);
 
if (readsocks < 0) {
perror("select");
exit(1);
}
if (readsocks == 0) {
/* Nothing ready to read, just show that
we're alive */
//printf(".");
continue;
}
if (FD_ISSET(fd,&socks)) {
/* Data Avilable */
if (modem_read(fd) < 0) {
return -1;
}
 
}
}
 
}
void raw_mode(int fd) {
struct termios options;
/* get the current options */
tcgetattr(fd, &options);
 
/* set raw input, 1 second timeout */
options.c_cflag |= (CLOCAL | CREAD);
options.c_lflag &= ~(ICANON | ECHO | ECHOE | ISIG);
options.c_oflag &= ~OPOST;
options.c_cc[VMIN] = 0;
options.c_cc[VTIME] = 10;
 
/* set the options */
tcsetattr(fd, TCSANOW, &options);
}
 
int /* O - 0 = MODEM ok, -1 = MODEM bad */
init_modem(int fd) /* I - Serial port file */
{
char buffer[255]; /* Input buffer */
char *bufptr; /* Current char in buffer */
int nbytes; /* Number of bytes read */
int tries; /* Number of tries so far */
 
for (tries = 0; tries < 3; tries ++)
{
/* send an AT command followed by a CR */
if (write(fd, "AT\r", 3) < 3) {
perror("Modem Write Failed: ");
continue;
}
 
/* read characters into our string buffer until we get a CR or NL */
bufptr = buffer;
while ((nbytes = read(fd, bufptr, buffer + sizeof(buffer) - bufptr - 1)) > 0)
{
bufptr += nbytes;
if (bufptr[-1] == '\n' || bufptr[-1] == '\r')
break;
}
if (nbytes<0) {
perror("Modem Read Failed: ");
}
 
printf("\nRead %d Bytes(%s)", nbytes, buffer);
 
/* nul terminate the string and see if we got an OK response */
*bufptr = '\0';
 
if (strstr(buffer, "OK") != NULL) {
printf("\nModem Initialized");
return (0);
}
}
printf("\nModem Initialization Failed");
return (-1);
}
 
int dial(int fd, char* number) {
char cmd[64];
 
memset(cmd, 0, 64);
sprintf(cmd, "ATD %s\r", number);
printf("\n(%d)Dialing...%s", strlen(cmd), cmd);
if (write(fd, cmd, strlen(cmd)) < 3) {
perror("Modem Write Failed: ");
return -1;
}
return 0;
}
 
void print_termios(struct termios *options) {
printf("\nTERMIOS ");
printf("\nSpeed: %d", cfgetispeed(options));
printf("\n");
 
}
 
void set_ioctl_baud(int fd, speed_t speed)
{
struct termios ttyset;
 
if (ioctl (fd, TCGETA, &ttyset) < 0) {
perror("IOCTL GETA ERROR");
exit(1);
}
print_termios(&ttyset);
ttyset.c_ispeed = speed;
ttyset.c_ospeed = speed;
 
if (ioctl (fd, TCSETA, &ttyset) < 0) {
perror("IOCTL SETA ERROR");
exit(1);
}
}
 
 
int set_baud(int fd, speed_t speed) {
struct termios options;
 
/*
* Get the current options for the port...
*/
 
tcgetattr(fd, &options);
print_termios(&options);
/*
* Set the baud rates to 19200...
*/
 
cfsetispeed(&options, speed);
cfsetospeed(&options, speed);
 
/*
* Enable the receiver and set local mode...
*/
 
options.c_cflag |= (CLOCAL | CREAD);
 
/*
* Set the new options for the port...
*/
 
tcsetattr(fd, TCSANOW, &options);
 
tcgetattr(fd, &options);
print_termios(&options);
}
 
int main(int argc, char *argv[]) {
 
char *dev;
int r, ttyfd;
if (argc > 1)
dev = strdup(argv[1]);
else
dev = strdup("/dev/modem");
ttyfd=serial_open(dev);
if (ttyfd) {
//raw_mode(ttyfd);
//init_modem(ttyfd);
set_ioctl_baud(ttyfd, B4800);
//dial(ttyfd, "9809649");
//select_data(ttyfd);
close(ttyfd);
}
printf("\n");
}

RPM File Extractor ツール

RPM File Extractor ツールは、すべての RPM ファイルをプロジェクト ソース ルート ディレクトリに抽出します。

プロジェクト ソースのルート ディレクトリから、RPM ファイルに必要な依存関係の有無を調べ、RPM に含まれている preinstall、postinstall、preuninstall または postuninstall スクリプトを表示できます。

RPM File Extractor ツールの詳細については、次の項を参照してください。

「RPM File Extractor ツールの実行」

「RPM File Extractor ツールの引数」

「RPM のトラブルシューティング」


) 目次に戻るには、ここをクリックしてください。


RPM File Extractor ツールの実行

RPM File Extractor Tool(rpm_extractor)の使用手順は、次のとおりです。


ステップ 1 まだ作成していない場合は、プロジェクト ディレクトリを作成します。パッケージ ツールを実行するディレクトリと同じディレクトリに作成できます。

ステップ 2 次のコマンドおよび引数を入力します。

workstation# rpm_extractor.sh --proj <Project Directory> [--output] [--scripts] [--deps] <RPM files> [--help]
 

引数の詳細については、「付録 B:ゲスト OS のコマンド」を参照してください。

RPM File Extractor ツールは、次の例のように、<project directory> の下にサブディレクトリ構造を作成します。

 
myprojdirectory/
rpm_extractor/
output/
scripts/
deps/
 

ステップ 3 RPM スクリプトの抽出後(標準 RPM ユーティリティまたはRPM ファイル抽出ツールのどちらかを使用)、表示された preinstall スクリプト、または postinstall スクリプト、および RPM の依存関係を確認します。

ステップ 4 抽出された情報から必要な部分を判断し、プロジェクト ソース ディレクトリに移します。


) Cisco AXP がサポートするのは、postinstall スクリプトだけです。


ステップ 5 アプリケーションをパッケージ化して、サービス モジュールにインストールします。


 

RPM File Extractor ツールの引数

RPM File Extractor ツールの引数は、次のとおりです。

--proj <Project Directory>:プロジェクト ディレクトリの位置を指定します。これは通常、パッケージ ツールの project-dir パラメータで使用するのと同じディレクトリ名です。

--output:(任意) output/ ディレクトリを作成するかどうかを指定するフラグ。 output/ ディレクトリには、ルート( / )ディレクトリとして指定したディレクトリで抽出する RPM ファイルが格納されます。たとえば、rpmfile1 です。

--scripts:(任意) scripts/ ディレクトリを作成するかどうかを指定するフラグ。 scripts/ ディレクトリには、スクリプト情報を含みます。スクリプト ファイルの名前は RPM のファイル名拡張子 .scripts からなります。

--deps:(任意) deps/ ディレクトリを作成するかどうかを指定するフラグ。このディレクトリには、RPM ファイル名が前に付いた、各 RPM ファイルの依存関係ファイルを含みます。たとえば、 rpmfile1.deps です。各依存関係ファイルは、この RPM ファイルに必要なその他のファイルを表示します。

<RPM files>:抽出する RPM ファイルのリスト。RPM ファイルは、ルート ディレクトリ( / )として指定したディレクトリに抽出されます。相対パス名または絶対パス名を使用します。

--help:RPM File Extractor ツールのヘルプ情報を出力します。


) RPM File Extractor ツールの 3 種類のオプションの引数をどれも指定しなかった場合は、3 種類すべてのサブディレクトリが作成されます(output/ scripts/ deps/)。(オプションの引数は、[--output] [--scripts] [--deps] です)。


RPM のトラブルシューティング

RPM ファイルを含むアプリケーションを初めてサービス モジュールにインストールする場合は、脱落ライブラリ、脱落コンフィギュレーションといった問題が起きることがあります。

脱落ライブラリ

他のライブラリが脱落している場合は、脱落ライブラリを探し、FTP でサービス モジュールに転送してから、アプリケーションを再テストします。これにより、サービス モジュール上でアプリケーションを実行する前に、アプリケーションを再パッケージ化する必要がなくなります。

脱落コンフィギュレーション

RPM ファイルから抽出したコンフィギュレーション スクリプトが正常に実行されない場合があります。簡単なデバッグ手順として、アプリケーションの Linux シェルにアクセスし、手動でスクリプトを呼び出素方法があります。この方法で、問題の特定を試みてください。

付録 A:Fedora Core 6 からのアプリケーションのポーティング:例

ここでは、Fedora Core 6 開発環境から Cisco AXP にアプリケーションをポーティングする例を 2 つ示します。

例 1 は簡易な C++ アプリケーションです。例 2 は、例 1 より複雑なアプリケーションで、 Apache Software Foundation から httpd ソフトウェアをポーティングします。

ここで説明する内容は、次のとおりです。

「セットアップ」

「例 1:簡易な C++ アプリケーション」

「例 2:既存アプリケーションのポーティング」

「Cisco AXP パッケージ コンテンツの特定」

「アプリケーションでのライブラリのバンドリング」


) 目次に戻るには、ここをクリックしてください。


セットアップ

使用する開発環境のセットアップは、Fedora Core 6 ワークステーションに基づきます。

Fedora Core 6 ワークステーションは、次の両方に使用します。

ポーティング元のプラットフォーム

開発マシン

Cisco AXP 開発用にマシンのセットアップおよび準備を行います。

ワークステーション Fedora Core 6 に基本 OS をインストールします。

tftp および ftp サーバをインストールして設定します。

Cisco AXP SDK に必要なその他のパッケージをインストールします。

sharutils(uuencode ユーティリティ)をインストールします。

XML プロセッシング ソフトウェア xmlstarlet がまだない場合は、インストールします。

Cisco AXP SDK をダウンロードして抽出します。

作業用のワークスペース ディレクトリを作成します。

例 1:簡易な C++ アプリケーション

C++ アプリケーションを Fedora Core 6 コンパイラ(3.4.4)でコンパイルした場合、生成されたバイナリは最小限、次のライブラリ(ldd で検索)に依存します。

libstdc++.so.6
libm.so.6
libgcc_s.so.1
libc.so.6
/lib/ld-linux.so.2
 

これらのライブラリは Cisco AXP のゲスト OS が提供します。これは、最小ライブラリ セットをあらゆるサードパーティ アプリケーションの一部としてバンドルしなくてもすむようにするためです。

アプリケーションを実行する前に、パス LD_LIBRARY_PATH が設定されていることを確認します。

LD_LIBRARY_PATH=/usr/lib:/lib
 

この簡易なアプリケーションの場合は、libc にパッチは不要です。アプリケーションは Cisco AXP ゲスト OS のライブラリを使って動作します。ただし、Fedora Core 6 でコンパイルしたアプリケーションは、リンク フォーマットが異なるので、他の環境で実行すると、浮動小数点例外エラーが発生して失敗する可能性があります。この例外を軽減するために、「 -Xlinker -hash-style=sysv 」または「 -Xlinker -hash-style=both 」リンク オプションのどちらかを使用して、Fedora Core 6 で C/C++ アプリケーションをコンパイルしてください。

Cisco AXP ブレード上で 簡易な C++ アプリケーションを実行したときに、Thread Local Storage(TLS)エラーが発生した場合は、プログラムに TLS サポートが必要です。Cisco AXP は TLS をサポートしません。しかし、libc サポートを提供するあらゆるライブラリを含め、libc ライブラリを組み込むことによって、Cisco AXP にアプリケーションをポーティングできます。

「システム ライブラリのアップデート」を参照してください。

例 2:既存アプリケーションのポーティング

ポーティング元のオペレーティング システムは、多数のダウンロード可能アプリケーション(RPM パッケージ)を提供し、広く普及している Fedora Core 6 Linux です。Cisco AX のネットワーク モジュールに Apache の httpd アプリケーションをポーティングする手順は、次のとおりです。

1. 「RPM のダウンロード」

2. 「RPM の抽出」

3. 「RPM コンテンツの点検」

4. 「Postinstall スクリプト」

5. 「スクリプトの例」

6. 「トラブルシューティング:脱落コンフィギュレーション ファイル」

RPM のダウンロード

Fedora Core の Web サイトから httpd RPM パッケージ(ソース パッケージではなくコンパイル済みのバージョン)をダウンロードします。


) 次のリンクから、RPM をダウンロードできます。


http://download.fedora.redhat.com/pub/fedora/linux/core/6/i386/os/Fedora/RPMS/httpd-2.2.3-5.i386.rpm

この例のように、パッケージが i386 プラットフォーム用の場合、ソースから実行可能ファイルを再ビルドしないでください。

RPM の抽出

RPM の内容を抽出します。これにより、内容を検証し、必要に応じて RPM ファイルの内容を変更し、他のファイルを追加して再パッケージ化できます。

RPM の抽出には、提供されている Cisco AXP RPM Extraction ツールを使用します。RPM Extractor ツールは Cisco AXP SDK に含まれており、tools ディレクトリにあります。RPM Extractor ツールは、ディレクトリを作成して、そのディレクトリに書き込む抽出 RPM ファイルを指定すれば使用できます。extracted_httpd_rpm というディレクトリを作成します。

RPM を抽出する例を示します。

../tools/rpm_extractor.sh --proj extracted_httpd_rpm httpd-2.2.3-5.i386.rpm
 

rpm_extractor ツールによって、extracted_httpd_rpm ディレクトリの下に次のディレクトリ構造が作成されます。

rpm_extractor
deps
output
scripts
 

deps ディレクトリには、ファイル httpd-2.2.3-5.i386.rpm.deps があります。これは、各種コマンドおよび抽出した RPM ファイルが依存するライブラリのリストです。output ディレクトリには、抽出した RPM ファイルのディレクトリおよびファイル コンテンツがあります。これらのディレクトリをソース ディレクトリにコピーします。ファイルを使用して httpd データをパッケージ化します。scripts ディレクトリには、ファイル httpd-2.2.3-5.i386.rpm.scripts があります。このファイルには、preinstall、postinstall、および preuninstall スクリプトが含まれます。preinstall スクリプトおよび postinstall スクリプトは、アプリケーションに使用する Cisco AXP postinstall スクリプトにコピーできますが、Cisco AXP ブレード上でスクリプトのコマンドが動作するかどうかを確認する必要があります。コマンドを多少変更しなければならない場合もあります。Cisco AXP は preuninstall スクリプトをサポートしません。

RPM コンテンツの点検

この例では、RPM コンテンツの多くを再利用します。httpd は Fedora Core 6 ディストリビューションでは動作しないので、RPM の実行可能ファイルの依存関係が解決されていることを確認する必要があります。

依存関係を解決するには、RPM が提供する各スクリプトおよび実行可能ファイルを調べ、スクリプトにバイナリ、ライブラリ、コンフィギュレーション ファイルなど、新しい Cisco AXP インストール パッケージとしてパッケージ化する、あらゆる依存ソフトウェアが含まれていることを確認します。

バンドルするライブラリの特定

「アプリケーションでのライブラリのバンドリング」を参照してください。

httpd 実行可能ファイルで「strace」を実行したあとで、ロードされてシスコのディレクトリ構造にコピーされたライブラリを特定しました。シスコのディレクトリ構造にあるこれらのライブラリを参照するリンクを再作成することも重要です。下記に、組み込むライブラリおよびシンボリック ライブラリの一覧を示します。

この他にも必要な libc 関連ライブラリがあります。後に続く項を参照してください。

From /lib:

libcom_err.so.2->libcom_err.so.2.1

libcrypto.so.0.9.8b

libcrypto.so.6->libcrypto.so.0.9.8b

libdb-4.3.so

libdistcache.so.1->libdistcache.so.1.0.1

libexpat.so.0->libexpat.so.0.5.0

libexpat.so.0.5.0

libgcc_s.so.1->libgcc_s-4.1.1-20061011.so.1

libnal.so.1->libnal.so.1.0.1

libpcre.so.0->libpcre.so.0.0.1

libselinux.so.1

libsepol.so.1

libssl.so.4->libssl.so.0.9.8b

libssl.so.6->libssl.so.0.9.8b

libuuid.so.1->libuuid.so.1.2

/usr/lib:

libapr-1.so.0->libapr-1.so.0.2.7

libaprutil-1.so.0->libaprutil-1.so.0.2.7

libaspell.so.15->libaspell.so.15.1.3

libbz2.so->libbz2.so.1.0.3

libbz2.so.1->libbz2.so.1.0.3

libcurl.so->libcurl.so.3.0.0

libcurl.so.3->libcurl.so.3.0.0

libgmp.so->libgmp.so.3.3.3

libgmp.so.3->libgmp.so.3.3.3

libgssapi_krb5.so->libgssapi_krb5.so.2.2

libgssapi_krb5.so.2->libgssapi_krb5.so.2.2

libidn.so->libidn.so.11.5.19

libidn.so.11->libidn.so.11.5.19

libk5crypto.so->libk5crypto.so.3.0

libk5crypto.so.3->libk5crypto.so.3.0

libkrb5.so->libkrb5.so.3.2

libkrb5.so.3->libkrb5.so.3.2

libkrb5support.so->libkrb5support.so.0.1

libkrb5support.so.0->libkrb5support.so.0.1

liblber-2.3.so.0->liblber-2.3.so.0.2.15

liblber.so->liblber-2.3.so.0.2.15

libldap-2.3.so.0->libldap-2.3.so.0.2.15

libldap_r-2.3.so.0->libldap_r-2.3.so.0.2.15

libldap.so->libldap_r-2.3.so.0.2.15

libperl.so

libpq.so.4->libpq.so.4.1

libpspell.so.15->libpspell.so.15.1.3

libpython2.4.so->libpython2.4.so.1.0

librt.so.1->librt-2.5.so

libsasl2.so->libsasl2.so.2.0.22

libsasl2.so.2->libsasl2.so.2.0.22

libselinux.so.1->../../lib/libselinux.so.1

libsqlite3.so->libsqlite3.so.0.8.6

libsqlite3.so.0->libsqlite3.so.0.8.6

libstdc++.so.6->libstdc++.so.6.0.8

libutil.so.1->libutil-2.5.so

libxml2.so->libxml2.so.2.6.26

libxml2.so.2->libxml2.so.2.6.26

libz.so->libz.so.1.2.3

libz.so.1->libz.so.1.2.3

Postinstall スクリプト

RPM パッケージを抽出すると、RPM にバンドルされているインストール関連スクリプトが抽出ツールによって報告されます。RPM システムがインストール関連スクリプトを開始するためにサポートするフックは、Cisco AXP の場合と異なります。Cisco AXP がサポートするのは、postinstall スクリプトだけです。

元の RPM パッケージにバンドルされていたすべてのインストール スクリプトを検証し、Cisco AXP ポストインストール スクリプトに「ポーティング」して、それらが Cisco AXP で動作し、正常にセットアップ手順が実行されることを確認します。インストール手順はパッケージのニーズ固有です。

たとえば、インストール手順にユーザの作成、権限の設定、ディレクトリの作成、および基本設定を含めることができます。postinstall スクリプトで、元の各スクリプトの機能を模倣し、Cisco AXP 環境で postinstall スクリプトをテストします。

rpm_extractor ツールによって作成されたスクリプト ディレクトリには、ファイル httpd-2.2.3-5.i386.rpm.scripts があります。このファイルには RPM ファイルから抽出したスクリプトが含まれています。

Cisco AXP 上で各スクリプトを手動でテストし、コマンドがサポートされることを確認する必要があります。必要なコード変更を行い、Cisco AXP SDK パッケージ ツールを使用して、ファイルを再パッケージ化します。

スクリプトの例

次に preinstall、postinstall 、および preuninstall スクリプトの例を示します(Cisco AXP は postuninstall スクリプトをサポートしません)。

preinstall スクリプトレット(/bin/sh を使用)

# Add the "apache" user
/usr/sbin/useradd -c "Apache" -u 48 \
-s /sbin/nologin -r -d /var/www apache 2> /dev/null || :
 

) preinstall スクリプトをテストすると、Cisco AXP がシステム アカウント(-r オプション)の作成をサポートしないことがわかります。また、ビット バケットに stderr をリダイレクトする必要はありません。


postinstall スクリプトレット(/bin/sh を使用)

# Register the httpd service
/sbin/chkconfig --add httpd
 

) postinstall スクリプトをテストすると、Cisco AXP が chkconfig コマンドをサポートしないことがわかります。したがって、通常は /etc/rc.d/rc3 および rc6 ディレクトリで start および kill のシンボリック リンクを独自に作成し、リンクがフォルダ etc/rc.d/init.d の httpd 起動スクリプトに接続するようにする必要があります。


Apache は、id が 48 で「apache」という名前のグループが存在していることを要求します。

preuninstall スクリプトレット(/bin/sh を使用)

if [ $1 = 0 ]; then
/sbin/service httpd stop > /dev/null 2>&1
/sbin/chkconfig --del httpd
fi
 
/bin/postinstall.sh
 
#!/bin/bash
 
#add group
/usr/bin/groupadd -g 48 apache
 
#add user
/usr/bin/useradd -c "Apache" -u 48 -s /sbin/nologin -d /var/www apache
 

トラブルシューティング:脱落コンフィギュレーション ファイル

ネットワーク モジュール上で httpd を起動したときに、httpd が /etc/mime.types ファイルがないことを示す場合があります。このファイルは、依存パッケージではない mailcap パッケージのものです。この場合は、 mailcap パッケージからファイルを組み込みます。

Cisco AXP パッケージ コンテンツの特定

ライブラリ

ソース コードからの httpd ソフトウェアの再コンパイルを避けるために、Fedora Core 6 システム ライブラリを組み込みます。これが必要なのは、RPM 実行可能ファイルが仮想マシンのライブラリではなく、Fedora システム ライブラリに対してコンパイルされているためです。

Fedora Core 6 には libc-2.5 および NPTL(Native POSIX Thread Library)がサポートされているのに対し、vserver が提供する libc-2.3.5 は NPTL サポート なし でコンパイルされます。この問題を解決するには、httpd アプリケーションに必要なすべてのライブラリをインストレーション パッケージに含める必要があります。

パッケージをインストールする際に、ワークステーション(FC6 が稼働)からコピーしなければならないライブラリを特定します。すべてのライブラリを組み込むと、不要なライブラリも含まれ、不必要に大量のディスク スペースを使用してしまいます。

必要なライブラリを特定するには、下記を使用します。

ldd checker

pkg_check.sh

これらを使用すると、Cisco AXP インストール パッケージに不足していて、仮想インスタンスが提供しないライブラリがわかります。


) 上記のチェックでは、脱落として識別されないライブラリもいくつかありますが、これらのライブラリも vserver の場合と同様、インストール パッケージに含める必要があります。これは、パッケージのライブラリと Fedora Core 6 の libc-2.5 との互換性を維持するためです。パッケージのライブラリは vserver が提供するライブラリより優先的に使用されます。


「ldd」ツールを使用し、実行可能ファイルおよび実行可能ファイルが依存するライブラリ上で実行すると、実行可能ファイルに必要なライブラリを特定できます。または、RPM をインストールし、「strace」ユーティリティを使用して httpd を実行することによって、ワークステーションに httpd をインストールすることもできます。

アプリケーションでのライブラリのバンドリング

バンドルするライブラリの特定

重要な手順の 1 つが、アプリケーションとともにパッケージ化するライブラリを特定することです。これが重要なのは、アプリケーションをネットワーク モジュールにインストールした時点でライブラリが脱落していると、アプリケーションが動作しないためです。

ライブラリを特定するには、次のいずれかのオプションを使用します。

1)Cisco AXP ldd-checker -- 脱落ライブラリを検出するツールです。このツールは、アプリケーション パッケージ、およびゲスト OS が提供するライブラリのリストを調べます。これは、脱落ライブラリを特定する場合の推奨方法です。

2)ldd ツール -- ldd ツールを直接使用することもできます。

3)「strace」ユーティリティの使用 -- このツールの場合は多少異なり、実際にはブレード上で動作して、ロードされているライブラリとライブラリが置かれているシステム上の位置を伝えます。これは、ライブラリの問題のトラブルシューティングに便利です。

libc ファイル

Cisco AXP にポーティングするバイナリ ソフトウェアが異なるバージョンの libc に依存する場合(たとえば、Fedora Core 6 は libc 2.5 を使用)、システムから libc をコピーしてアプリケーションにバンドルする必要があります。さらに、libc に関連するライブラリをコピーすることも必要です。この作業を怠ると、実行時に Cisco AXP ゲスト OS に付属しているライブラリとの不一致が生じます。

アプリケーションに libc をバンドルするときに組み込む必要のあるソフト リンク、およびソフト リンクが指すファイルの一覧は、次のとおりです。

ld.so.1 -> ld-2.5.so(ライブラリ ローディング)

libc.so.6 -> libc-2.5.so

libcrypt.so.1 -> libcrypt-2.5.so(暗号化)

libdl.so.2 -> libdl-2.5.so(ダイナミック リンカー)

libm.so.6 -> libm-2.5.so(数学ライブラリ)

libnsl.so.1-> libnsl-2.5.so(ネーム サービス ライブラリ)

libnss_dns.so.2 -> libnss_dns-2.5.so

libnss_files.so.2 -> libnss_files-2.5.so

libpthread.so.0 -> libpthread-0.10.so(POSIX スレッド サポート)

libresolv.so.2 -> libresolv-2.5.so(名前解決)

librt.so.1 -> librt-2.5.so(リアルタイム拡張)

libthread_db.so.1 -> libthread-1.0.so(linuxthreads)

libutil.so.1 -> libutil-2.5.so(ユーティリティ)

** ゲスト OS が提供する、これらのライブラリ関連のすべてのソフトウェア リンクのすべてがパッケージ ライブラリを指すように上書きされているかどうかを確認する必要があります。

ライブラリの検索および LD_LIBRARY_PATH


) ライブラリは LD_LIBRARY_PATH 環境変数に基づいて検索されます。この環境変数が正しいかどうかを確認してください。


アプリケーション内部の /usr/lib 下でライブラリがバンドルされている場合、LI_LIBRARY_PATH を調整して /usr/lib パスを含める必要があります。

新しいライブラリを(/usr/lib ではなく)「/lib」に置いて、ゲスト OS のライブラリを上書きします。

付録 B:ゲスト OS のコマンド

 

/bin/awk
/bin/basename
/bin/bash
/bin/cat
/bin/chgrp
/bin/chmod
/bin/chown
/bin/cmp
/bin/col
/bin/colrm
/bin/cp
/bin/curl
/bin/date
/bin/dd
/bin/df
/bin/dir
/bin/dirname
/bin/dmesg
/bin/du
/bin/echo
/bin/egrep
/bin/env
/bin/expr
/bin/false
/bin/find
/bin/free
/bin/getopt
/bin/grep
/bin/gunzip
/bin/gzip
/bin/head
/bin/hostname
/bin/id
/bin/ipcs
/bin/kill
/bin/ln
/bin/ls
/bin/md5sum
/bin/mkdir
/bin/mktemp
/bin/more
/bin/mv
/bin/netstat
/bin/nice
/bin/nohup
/bin/notty
/bin/pgrep
/bin/pkill
/bin/pmap
/bin/ps
/bin/pwdx
/bin/python
/bin/rename
/bin/renice
/bin/rm
/bin/rmdir
/bin/sed
/bin/setsid
/bin/setterm
/bin/sh
/bin/sha1sum
/bin/skill
/bin/sleep
/bin/snice
/bin/sort
/bin/strace
/bin/stty
/bin/tac
/bin/tail
/bin/tar
/bin/telnet
/bin/tftp
/bin/top
/bin/touch
/bin/tr
/bin/true
/bin/tty
/bin/uname
/bin/uptime
/bin/vi
/bin/vmstat
/bin/wc
/bin/whoami
/bin/xargs
# From /usr/bin
/usr/bin/cksum
/usr/bin/dig
/usr/bin/expect
/usr/bin/groupadd
/usr/bin/groupdel
/usr/bin/groupmod
/usr/bin/groups
/usr/bin/hdparm
/usr/bin/hexdump
/usr/bin/host
/usr/bin/ip
/usr/bin/kill
/usr/bin/killall
/usr/bin/open
/usr/bin/passwd
/usr/bin/ping
/ /usr/bin/scp
/usr/bin/sftp
/usr/bin/sftp-server
/usr/bin/ssh
/usr/bin/sshd
/usr/bin/syslog_ng
/usr/bin/tc
/usr/bin/tcpdump
/usr/bin/traceroute
/usr/bin/useradd
/usr/bin/userdel
/usr/bin/usermod
/usr/bin/which

付録 C:ゲスト OS のライブラリ

 

/lib/ld-2.3.5.so
/lib/ld-linux.so.2
/lib/ld.so
/lib/libblkid.so
/lib/libblkid.so.1.0
/lib/libcom_err.so
/lib/libcom_err.so.2.1
/lib/libc-2.3.5.so
/lib/libc.so.6
 
/lib/libcares-1.2.0.so
/lib/libcares.so
/lib/libcares.so.1
 
/lib/libcrypt-2.3.5.so
/lib/libcrypt.so
/lib/libcrypt.so.1
 
/lib/libcrypto.so
/lib/libcrypto.so.0.9.8
/lib/libcrypto.so.0.9.8a
/lib/libdecrypt_lib.so
/lib/libdecrypt_lib.so.0.9.8
/lib/libdecrypt_lib.so.0.9.8a
# Curl Related
/lib/libcurl-7.15.2.so
/lib/libcurl.so
#
# glibc-2.3.5 Related
#
/lib/libdl-2.3.5.so
/lib/libdl.so
/lib/libdl.so.2
#
/lib/libe2p.so
/lib/libe2p.so.2.3
#
# Expat
/lib/libexpat.so
/lib/libexpat.so.1
/lib/libexpat.so.1.95.8
#
# Expect
/lib/libexpect.so
/lib/libexpect.so.5.43.0
# ncurses
/lib/libform.so
/lib/libform.so.5
/lib/libform.so.5.4
/lib/libform.so
/lib/libform.so.5
/lib/libform.so.5.4
 
#
/lib/libpanel.so
/lib/libpanel.so.5
/lib/libpanel.so.5.4
 
# Bind related
/lib/libisc.so
/lib/libisc.so.8.6.1
#
/lib/libjavautil.so
/lib/libjavautil.so.1
/lib/libjavautil.so.1.0.0
#
/lib/libm-2.3.5.so
/lib/libm.so
/lib/libm.so.6
#
# ncurses
/lib/libmenu.so
/lib/libmenu.so.5
/lib/libmenu.so.5.4
/lib/libncurses.so
/lib/libncurses.so.5
/lib/libncurses.so.5.4
# Net-tools
/lib/libnet-tools-1.60.so
/lib/libnet-tools.so
/lib/libnsl-2.3.5.so
/lib/libnsl.so
/lib/libnsl.so.1
/lib/libnss_dns-2.3.5.so
/lib/libnss_dns.so
/lib/libnss_dns.so.2
/lib/libnss_files-2.3.5.so
/lib/libnss_files.so
/lib/libnss_files.so.2
# Libpcap
/lib/libpcap.so
/lib/libpcap.so.0
/lib/libpcap.so.0.9.3
# PCRE
/lib/libpcre.so
/lib/libpcre.so.0.0.1
/lib/libpcreposix.so
/lib/libpcreposix.so.0.0.0
# Procps
/lib/libproc-3.2.5.so
/lib/libproc.so
/lib/libpthread-0.10.so
/lib/libpthread.so
/lib/libpthread.so.0
/lib/libresolv-2.3.5.so
/lib/libresolv.so
/lib/libresolv.so.2
 
#
/lib/librt-2.3.5.so
/lib/librt.so
/lib/librt.so.1
/lib/libss.so
/lib/libss.so.2.0
/lib/libssl.so
/lib/libssl.so.0.9.8
/lib/libssl.so.0.9.8a
# Tar utility
/lib/libtar.so
/lib/libtar.so.1.15.1
# Java Util udppacer
/lib/libudppacer.so
/lib/libudppacer.so.1
/lib/libudppacer.so.1.0.0
#
/lib/libutil-2.3.5.so
/lib/libutil.so
/lib/libutil.so.1
#
/lib/libuuid.so
/lib/libuuid.so.1.2
# Zlib
/lib/libzlib.so
/lib/libzlib.so.1.2.3
# mx4j-libs
/usr/lib/java/bcel-5.1.jar
/usr/lib/java/commons-logging.jar
/usr/lib/java/jakarta-oro-2.0.6.jar
# Log4j
/usr/lib/java/log4j.jar
# MX4J
/usr/lib/java/mx4j-impl.jar
/usr/lib/java/mx4j-jmx.jar
/usr/lib/java/mx4j-remote.jar
/usr/lib/java/mx4j-rimpl.jar
/usr/lib/java/mx4j-rjmx.jar
/usr/lib/java/mx4j-tools.jar
/usr/lib/java/mx4j.jar
# net-snmp 5.1.2 library /lib/libsnmplib.so /lib/libsnmplib.so.5 /lib/libsnmplib.so.5.1.2

通告

次に、このソフトウェア ライセンスに関連する通告を示します。

OpenSSL/Open SSL Project

This product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit ( http://www.openssl.org/ ).

This product includes cryptographic software written by Eric Young (eay@cryptsoft.com).

This product includes software written by Tim Hudson (tjh@cryptsoft.com).

License Issues

The OpenSSL toolkit stays under a dual license, i.e. both the conditions of the OpenSSL License and the original SSLeay license apply to the toolkit. See below for the actual license texts. Actually both licenses are BSD-style Open Source licenses. In case of any license issues related to OpenSSL please contact openssl-core@openssl.org.

OpenSSL License:

Copyright © 1998-2007 The OpenSSL Project. All rights reserved.

Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:

1. Redistributions of source code must retain the copyright notice, this list of conditions and the following disclaimer.

2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions, and the following disclaimer in the documentation and/or other materials provided with the distribution.

3. All advertising materials mentioning features or use of this software must display the following acknowledgment: "This product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit ( http://www.openssl.org/ )".

4. The names "OpenSSL Toolkit" and "OpenSSL Project" must not be used to endorse or promote products derived from this software without prior written permission. For written permission, please contact openssl-core@openssl.org.

5. Products derived from this software may not be called "OpenSSL" nor may "OpenSSL" appear in their names without prior written permission of the OpenSSL Project.

6. Redistributions of any form whatsoever must retain the following acknowledgment:

"This product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit ( http://www.openssl.org/ )".

THIS SOFTWARE IS PROVIDED BY THE OpenSSL PROJECT "AS IS"' AND ANY EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE OpenSSL PROJECT OR ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

This product includes cryptographic software written by Eric Young (eay@cryptsoft.com). This product includes software written by Tim Hudson (tjh@cryptsoft.com).

Original SSLeay License:

Copyright © 1995-1998 Eric Young (eay@cryptsoft.com). All rights reserved.

This package is an SSL implementation written by Eric Young (eay@cryptsoft.com).

The implementation was written so as to conform with Netscapes SSL.

This library is free for commercial and non-commercial use as long as the following conditions are adhered to. The following conditions apply to all code found in this distribution, be it the RC4, RSA, lhash, DES, etc., code; not just the SSL code. The SSL documentation included with this distribution is covered by the same copyright terms except that the holder is Tim Hudson (tjh@cryptsoft.com).

Copyright remains Eric Young's, and as such any Copyright notices in the code are not to be removed. If this package is used in a product, Eric Young should be given attribution as the author of the parts of the library used. This can be in the form of a textual message at program startup or in documentation (online or textual) provided with the package.

Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:

1. Redistributions of source code must retain the copyright notice, this list of conditions and the following disclaimer.

2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.

3. All advertising materials mentioning features or use of this software must display the following acknowledgement:

"This product includes cryptographic software written by Eric Young (eay@cryptsoft.com)".

The word ‘cryptographic' can be left out if the routines from the library being used are not cryptography-related.

4. If you include any Windows specific code (or a derivative thereof) from the apps directory (application code) you must include an acknowledgement: "This product includes software written by Tim Hudson (tjh@cryptsoft.com)".

THIS SOFTWARE IS PROVIDED BY ERIC YOUNG "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

The license and distribution terms for any publicly available version or derivative of this code cannot be changed. i.e. this code cannot simply be copied and put under another distribution license [including the GNU Public License].