RouteMagic

製品概要活用事例

製品のご購入は

RouteMagic製品のご購入につきましては、販売パートナーにお問い合わせください。

パートナー一覧製品一覧

お問い合わせ

【 RouteMagic Server 4.2.1 リリースノート (2010/07/11) 】

Routrek Networks, Inc.

 

RouteMagic Server Version 4.2.1 では、Version 4.1.2 から以下の機能追加・仕様変更・不具合修正が行われています。Version 4.2.1 にアップデートする前に、以下の内容をご確認くださいますようお願い致します。

【 機能追加・変更点 (Version 4.2) 】

1.RM-CM400 に対応

V4.2 から RM-CM400 (4 ポートタイプ)に対応しました。CM200/CM1200 と同様の設定手順でご利用いただけます。


 

2.一括登録機能を追加

V4.2. から複数の装置情報設定を一度に行える一括登録系の機能を追加しました。管理メニューに次のメニュー項目が追加されています。

  • 装置一括登録
  • 装置情報一括更新
  • SNMP トラップ通知先一括登録

 

3.権限の名称変更

グローバル権限の「コマンド管理」の名称を「コマンドグループ管理」に変更しました。


 

4.RMS システムログ (rms.log) に関連する変更

RMS システムログファイル (rms.log) に出力されるログイン成功/失敗ログに「組織名」が付加されるように変更しました。

 

5.最新版の JRE (1.6.0_20) に対応

V4.2.0 の製品 CD-ROM に含まれる JRE (Java Runtime Environment) インストーラを最新バージョン (1.6.0_20) に更新しました。

旧バージョンの RMS から V4.2.1 にアップグレードする際には、まず RMS V4.2.1 の製品 CD-ROM に含まれる jre-6u20-linux-i586-rpm.bin をインストールしてください。


 

6.AlaxalA 系の機種に対応

V4.2 から AlaxalA 系の機種に対応しました。RMS 上で管理している装置の装置種別で AlaxalA を選択可能となり、AlaxalA 用のリモートコマンド定義が設定可能です。

 

 

【 不具合修正 】

[V4.2.0]

・「(すべての装置)」のリスト画面から装置の「新規追加」をクリックすると例外エラーが表示される不具合を修正しました。

・権限をもたないユーザがコマンド定義を削除できてしまう不具合を修正しました。

・権限がもたないユーザがコマンドグループを削除できてしまう不具合を修正しました。

・「コマンドグループ管理」権限が付与されているユーザでコマンドグループの新規作成と編集ができない不具合を修正しました。

・RES 鍵交換関連のエラー発生時に rms.log に Java のスタックトレースが出力される不具合を修正しました。

・RM-CM 登録解除時に各種ログデータが削除されない不具合を修正しました。

・RM-CM との通信方法が「メール(プレーン)」の場合にメール内に含まれる不正な文字コードデータを正しく除去しないままデータベースに保存される不具合を修正しました。
(不正な文字コードが含まれたデータがバックアップファイル内に存在すると、データベースのリストア時に PostgreSQL のエラーになる場合がありました。)

・RM-CM を RouteMagic CM 登録画面(未登録 RM-CM リスト画面)から削除できなかった不具合を修正しました。

・インシデントの操作に関連する権限が正しく機能しない不具合を修正しました。
(詳細は下記の「■インシデントに関連する権限について」をご参照ください)


 

【 インシデントに関連する権限について 】

【インシデントの参照に必要な権限】※以下のいずれかが必要
・グローバル権限「組織管理」
・グローバル権限「インシデント管理」
・装置グループ権限「インシデント管理」
(インシデントに関連しているいずれかの装置について「インシデント管理」権限があれば許可する)

 

【インシデントの追加・編集・削除に必要な権限】※以下のいずれかが必要
・グローバル権限「組織管理」
・グローバル権限「インシデント管理」

 

【インシデント対処履歴の追加・編集に必要な権限】※以下のいずれかが必要
・グローバル権限「組織管理」
・グローバル権限「インシデント管理」
・装置グループ権限「インシデント管理」
(インシデントに関連しているいずれかの装置について「インシデント管理」権限があれば許可する)

 

【インシデント対処履歴の削除に必要な権限】※以下のいずれかが必要
・グローバル権限「組織管理」
・グローバル権限「インシデント管理」

 

【インシデント要因データの追加・編集・削除に必要な権限】※以下のいずれかが必要
・グローバル権限「組織管理」
・グローバル権限「インシデント管理」

 

 

【 V4.2.1 へのアップデートを安全に行う手順 】

ここでは、V4.1.1 へのアップデート作業を安全に行うための手順をご説明します。

 

本手順では、アップデート作業中に RM-CM のメール送信機能を一時的に停止して、RMS に対してメールが送られてこないようにした状態で作業を進めます。

 

したがって、アップデート作業中は装置の死活監視やログ収集などが一時的に行えない状態になりますので、運用に支障のない時間帯に行うことをお勧め致します。

 

1.簡易インストールガイドの手順に従って rms4setup.pl スクリプトを実行し、V4.1.1 にアップデートします。(これまでと同様の手順です)

 

※以下、2~12を実行する前に、rmsv データベースのバックアップを取っておくことを強く推奨致します。

 

■RMS 4.0 データベースのバックアップ・リストアの方法(参考)
http://www.routrek.co.jp/support/archives/2008/10/rms_40.html

 

2.V4.2.1 を起動する前に、RM-CM 側で set no mail-service を実行してRMC からのメール送信を停止しておきます。

 

3.ブラウザで RMS 管理者モードでログインします。

 

4.ツリーメニューから[RMS システム設定] を選択して開きます。

 

5.「定時タスク時にログ保存期間を経過したログの自動削除を実行する」オプションが「有効」になっていることを確認します。「有効」なっていない場合は、[編集] リンクをクリックして設定編集画面で「有効」にセットしてください。

 

【 注意 】
「定時タスク時にログ保存期間を経過したログの自動削除を実行する」オプションが有効になっていないと、装置や RM-CM の「ログ保存期間」を設定しても定時タスクでの自動削除処理が行われませんのでご注意ください。

 

6.「定時タスク実行時刻」の右側にある「今すぐ実行する」をクリックします。

 

これによって、次回の定時タスクが「現在時刻より1分後」に強制的にスケジューリングされます。

 

なお、次回の定時タスクが現在時刻より1時間以内にスケジューリングされている場合は、「今すぐ実行する」は実行できない仕様となっております。
(定時タスク処理がバッティングするのを防ぐため)

 

その場合は、定時タスク実行時刻を一時的に別の時刻にずらすことによって解決できます。

 

7.RMS が稼働している Linux のシェルで以下のコマンドを実行し、定時タスクの開始と終了を確認します。

 

# tail -f /opt/rms4/logs/rms.log

(以下のように表示されます)

2009-01-28 03:02:50,497 INFO  [DailyTaskImpl] daily task start.
...
2009-01-28 03:02:52,112 INFO  [DailyTaskImpl] daily task end. 
    next=2009-01-29 03:02:00

【 注意点 】
定時タスク処理では、ログ削除処理要求をログ削除スレッドに送信する処理のみを行っています。そのため、「daily task end.」と表示されて定時タスク処理が完了したあとも、削除するログの量が多い場合はバックグラウンドでログ削除スレッドが削除処理を継続していることがあります。

また、大量のデータを削除しているときは、PostgreSQL のプロセスによってシステムのロードアベレージがかなり高くなりますので、他のプログラムが処理をしていない時間帯に行うことをお勧めします。

ログ削除処理に伴うシステム負荷の確認は、top コマンドなどで行えます。postgres プロセスの CPU 使用率が高い間は削除処理が継続している状態です。

8.削除処理が完了したら、RMS を停止します。

# /etc/init.d/rms4 stop

9.rmsv ユーザに移行して、vacuumdb コマンドを実行し、PostreSQL データベースのシュリンクと最適化を行います。

# su - rmsv
$ vacuumdb -f -z rmsv
$ exit

10.RMS を起動する

# /etc/init.d/rms4 start

11.RM-CM 側で set mail-service コマンドを実行し、メール送信処理を再開します。

12.RMS にログインして、RM-CM 通信ログ画面等で RM-CM からのメールが正常に受信できていることを確認します。

サイトマッププライバシーポリシーお問い合わせ

Copyright (C) 2017 Routrek Networks, Inc. All rights reserved.