このページでは、さまざまな GroundWork Monitor 運用操作上のハウツーについて説明します。各リファレンスのタイトルをクリックすると、詳しい説明表示が切り替わり(表示/隠す)ます。このハウツーのリストは継続的に追加開発されますので、上のメールアイコンをクリックして、コメントや提案を行ってください。特定の GroundWork Monitor ポータルページと運用操作の詳細は、ブックシェルフのナビゲーションツリーのアプリケーションの使い方 を参照してください。
ハウツー: 計画停止時間(scheduled downtime)のキャンセル
[このウィンドウを閉じるには、ハウツーのリンクを再クリックしてください]
以下の手順に従って、Nagios インタフェースを介して計画停止時間をキャンセルします。
1. Nagios ページを選びます。
2. Scheduled Downtime(計画停止時間)を選びます。
3. 問題のホスト/サービスを探し、停止時間のスケジュールを削除するため、Actions(アクション)カラムの右側にある、対応するゴミ箱をクリックします。
4. Commit(コミット)と Done(完了)をクリックします。
図: ホストやサービスのための計画停止時間をキャンセルする
ハウツー: 実行中の GroundWork Monitor のバージョンを確認する
[このウィンドウを閉じるには、ハウツーのリンクを再クリックしてください]
GroundWork Monitor にログインすると、デフォルトのダッシュボードが表示されます。 このダッシュボードは、一般的な情報のお知らせや、インストレーション名や日付。コンポーネントのバージョンなどの GroundWork のインストレーションレポートを表示します。NetworkServicePlugin ポートレットインスタンスがこのダッシュボードに使用されています。
図: GroundWork Monitor のバージョン
ハウツー: Nagios と Monarch のどのバージョンが実行されているかを調べる
[このウィンドウを閉じるには、ハウツーのリンクを再クリックしてください]
以下の手順に従って、現在の Nagios と Monarch のバージョンを表示します。
1. Configuration(コンフィグレーション)アプリケーションタブを選択します。
2. Control(コントロール)オプションを選びます。
3. Setup(セットアップ)オプションを選びます。 現在の Monarch と Nagios バージョンが表示されるでしょう。
図: コンフィグレーションのセットアップ
ハウツー: GroundWork Monitor サービスの開始と停止
[このウィンドウを閉じるには、ハウツーのリンクを再クリックしてください]
注意: gwservices あるいは 他の GroundWork Monitor サービスをリスタートすると、ブラウザ内の UI コンポーネントが応答しなくなる可能性があります。
ほとんどの場合、どれかしらのサービスを停止と開始を行うことは推奨しません。これらのサービスは相互に依存関係にあります。本リリースにおいては、gwservices は、さまざまのフィーダ、データ統合エンジンおよび UI をドライブする Web サービスレイヤーを含む、ミドルウェア全体を実行しコントロールします。 UI コンポーネントが Web サービスを未知の状態にしてしまい、そのコンポーネントがブラウザに対して応答しなくなってしまう可能性があるので、gwservices サービスをリスタートすることは推奨しません。これらのコンポーネントの例は、Status(ステータス)、Dashboards(ダッシュボード)と Event Console(イベントコンソール)です。
これらのサービスがランダムに開始された場合、他のサービスは未知の状態になるでしょう。もし、これらのサービスの内のひとつを停止して開始する必要があるならば、まず、すべてのユーザがログアウトする必要があります。さらに、ほとんどの場合、管理者がこれらのサービスを停止と開始しなければならない場合、最も安全な方法は、すべてのサービスを停止してから再開始することです。それにより、すべての GroundWork Monitor サービスが相互に再同期するでしょう。
(Community Edition については、後述)
Apache2 の停止
/usr/local/groundwork/ctlscript.sh stop apache
SNMP Trap Translator の停止
/usr/local/groundwork/ctlscript.sh stop snmptt
Nagios の停止
/usr/local/groundwork/ctlscript.sh stop nagios
Foundation の停止
/usr/local/groundwork/ctlscript.sh stop gwservices
syslog-ng の停止
/usr/local/groundwork/ctlscript.sh stop syslog-ng
ネットワークサービスの停止
/usr/local/groundwork/ctlscript.sh stop network-service
mysql の停止
/usr/local/groundwork/ctlscript.sh stop mysql
snmptrapd の停止
/usr/local/groundwork/ctlscript.sh stop snmptrapd
Apache2 の開始
/usr/local/groundwork/ctlscript.sh start apache
SNMP Trap Translator の開始
/usr/local/groundwork/ctlscript.sh start snmptt
Nagios の開始
/usr/local/groundwork/ctlscript.sh start nagios
Foundation の開始
/usr/local/groundwork/ctlscript.sh start gwservices
syslog-ng の開始
/usr/local/groundwork/ctlscript.sh start syslog-ng
ネットワークサービスの開始
/usr/local/groundwork/ctlscript.sh start network-service
mysql の開始
/usr/local/groundwork/ctlscript.sh start mysql
snmptrapd の開始
/usr/local/groundwork/ctlscript.sh start snmptrapd
Apache2 の停止
/usr/local/groundwork/ctlscript.sh stop apache
Nagiosの停止
/usr/local/groundwork/ctlscript.sh stop nagios
Foundationの停止
/usr/local/groundwork/ctlscript.sh stop gwservices
syslog-ngの停止
/usr/local/groundwork/ctlscript.sh stop syslog-ng
ネットワークサービスの停止
/usr/local/groundwork/ctlscript.sh stop network-service
mysqlの停止
/usr/local/groundwork/ctlscript.sh stop mysql
nscaの停止
/usr/local/groundwork/ctlscript.sh stop nsca
Apache2 の開始
/usr/local/groundwork/ctlscript.sh start apache
Nagios の開始
/usr/local/groundwork/ctlscript.sh start nagios
Foundation の開始
/usr/local/groundwork/ctlscript.sh start gwservices
syslog-ng の開始
/usr/local/groundwork/ctlscript.sh start syslog-ng
ネットワークサービスの開始
/usr/local/groundwork/ctlscript.sh start network-service
mysql の開始
/usr/local/groundwork/ctlscript.sh start mysql
nsca の開始
/usr/local/groundwork/ctlscript.sh start nsca
ハウツー: Nagios WAP インタフェースをアクセスできるよう GroundWork Monitor を構成設定する
[このウィンドウを閉じるには、ハウツーのリンクを再クリックしてください]
GroundWork の導入時に、Nagios CGI へのアクセスは、 GroundWork ポータルで最初に認証されたユーザに制限されます。
これは、WAPが使用できる携帯電話からのシステムへのアクセスを試みる場合、問題となります。ポータルが WAP をサポートしないため、 WAP デバイスを認証する方法がありません。
下記で参照しているスクリプトは、GroundWork Monitor の構成設定を適切に行うために nagios や root ユーザとして実行することができ、ポータルの認証から statuswml.cgi(WAP インタフェースをコントロールする Nagios CGI)を削除して、外部からアクセスできるようにします。
1. ダウンロード: WAP インタフェースのインストールスクリプト
2. スクリプトを実行後、root ユーザとして Apache をリスタートする必要があります:
/etc/init.d/httpd restart
3. 最後に、 WAP インタフェースへの認証をするため、最低限ひと組のユーザ名とパスワードを設定する必要があります。既存のデフォルトユーザがすでに作成されています。あなたがする必要のあることのすべては、下記のコマンドを入力してプロンプト表示後に新しいパスワードを入力することで、nagios や root ユーザのパスワードを更新することです::
cd /usr/local/groundwork/apache2/bin
./htpasswd /usr/local/groundwork/nagios/etc/htpasswd.users nagiosadmin
4. ここにおいて、あなたの GroundWork サーバ上で下記の URL から情報を引き出すことができるでしょう:
/exposed/cgi-bin/statuswml.cgi
5. デフォルトで構成設定されている .htaccess メソッドを使って試すことができるでしょう。その CGI は WAP 準拠のブラウザでのみ表示可能です。
6. 当然、あなたが WAP インタフェースを保護するために、この機能を使いたい場合、Nagios のドキュメントに記述されているように cgi.cfg と .htpasswd ファイルにユーザを追加できます。
7. モバイル機器からアクセスができるようにするためには、この URL をインタネットへ露出する必要がありますが、そのこと自体は GroundWork とはかかわりません。
ハウツー: Monarch の Commit(コミット)操作を監査する
[このウィンドウを閉じるには、ハウツーのリンクを再クリックしてください]
複数のお客様が Nagios の構成設定への変更をログに残すことを必要としています。 Monarch ツールは Nagios の構成設定への変更を行うのに使用され、 Monarch のユーザがそれらの変更を Nagios にプッシュしたい場合コミット操作が行われます。コミット操作の一環として、そのコミットが行われた時点のタイムスタンプとコミットを行ったユーザの名前がメインの Nagios 構成設定ファイルに書き込まれます。 これは、インスタンスのビルドが行われた際の Monarch グループの場合でも行われます。
GroundWork は、タイムススタンプと、コミットやビルドインスタンス操作を行ったユーザ名をイベントコンソールにロギングすることで、お客様がコミット操作の監査(オーディット)を追加することができるよう、このドキュメントを提供します。
新しいアプリケーションタイプ AUDIT がイベントコンソールの中に生成され、すべての監査イベントを一覧にするために、GroundWork Reports の Event History (gw-event-history) レポートがお客様によって使えるようになります。
これらの手順は GroundWork Monitor Professional や Enterprise 5.2.0 以降のインストレーションで使用できます。
GroundWork Monitor サーバ上の nagios ユーザとして、下記の手順を実行します:
1. Appendix A で示されている内容を下記のファイルに入れます:
/usr/local/groundwork/core/migration/add_audit_application_type.pl
2. ディレクトリを移ります:
cd /usr/local/groundwork/core/migration
3. 下記のコマンドを投入します:
chmod 744 add_audit_application_type.pl
4. 下記のコマンドを投入します:
./add_audit_application_type.pl
5. Appendix B で示されている内容を下記のファイルに入れます:
/usr/local/groundwork/foundation/feeder/audit-nagios.pl
6. ディレクトリを移ります:
cd /usr/local/groundwork/foundation/feeder
7. 下記のコマンドを投入します:
chmod 744 audit-nagios.pl
8. 下記を入力します:
/usr/local/groundwork/common/bin/mkservice nagios nagios /usr/local/groundwork/core/services/feeder-audit-nagios
9. Appendix C で示されている内容を下記のファイルに入れます:
/usr/local/groundwork/core/services/feeder-audit-nagios/run
10. Appendix D で示されている内容を下記のファイルに入れます:
/usr/local/groundwork/common/etc/syslog-ng.conf
GroundWork サーバ上の root ユーザとして、下記の手順を実行します:
syslog をリスタートします:
/usr/local/groundwork/ctlscript.sh restart syslog-ng
GroundWork サービスをリスタートします:
/usr/local/groundwork/ctlscript.sh restart gwservices
#!/usr/local/groundwork/perl/bin/perl --
#
# Database updater for audit logging within GroundWork Monitor
#
# Written by Dr. Dave Blunt (dblunt@groundworkopensource.com)
#
# Last modified: 2008-05-15
#
# Usage: add_audit_application_type.pl
#
# Description:
#
# This script will access the GWCollageDB database based on the settings
# determined with the CollageQuery methods. Thus, the script must be run
# on the relevant GroundWork server.
# It will add rows to the ApplicationType, ConsolidationCriteria and
# ApplicationEntityProperty tables to support delivery and reporting on
# audit messages supplied by an external script 'audit-nagios.pl' that
# watches for commit operations on the Monarch database.
use strict;
use CollageQuery;
my ($Database_Name,$Database_Host,$Database_User,$Database_Password) = CollageQuery::readGroundworkDBConfig("collage");
my $dbh = DBI->connect("DBI:mysql:$Database_Name:$Database_Host", $Database_User, $Database_Password) or die "Can't connect to database $Database_Name. Error:".$DBI::errstr;
my $query;
my $sth;
# Add the AUDIT application type and get back the ApplicationTypeID for
# later reference
$query = "insert into ApplicationType values('','AUDIT','Audit logs for GroundWork Monitor','Device')";
$sth = $dbh->prepare($query);
$sth->execute() or die $@;
$query = "select ApplicationTypeID from ApplicationType where Name='AUDIT'";
$sth = $dbh->prepare($query);
$sth->execute() or die $@;
my $appID;
while (my $row=$sth->fetchrow_hashref()) {
$appID = $$row{ApplicationTypeID};
}
# Add the Consolidation criteria for AUDIT messages
$query = "insert into ConsolidationCriteria values('','AUDIT','OperationStatus;Device;MonitorStatus;ipaddress;ErrorType;SubComponent')";
$sth = $dbh->prepare($query);
$sth->execute() or die $@;
# Add the ApplicationEntityProperty settings that control what is displayed
# in the NOC Console
$query = "select EntityTypeID from EntityType where Name='LOG_MESSAGE'";
$sth = $dbh->prepare($query);
$sth->execute() or die $@;
my $enttypeID;
while (my $row=$sth->fetchrow_hashref()) {
$enttypeID = $$row{EntityTypeID};
}
$query = "select PropertyTypeID,Name from PropertyType";
$sth = $dbh->prepare($query);
$sth->execute() or die $@;
my %proptypeID;
while (my $row=$sth->fetchrow_hashref()) {
$proptypeID{$$row{Name}} = $$row{PropertyTypeID};
}
$query = "insert into ApplicationEntityProperty values('','".$appID."','".$enttypeID."','".$proptypeID{"SubComponent"}."','2')";
$sth = $dbh->prepare($query);
$sth->execute() or die $@;
$query = "insert into ApplicationEntityProperty values('','".$appID."','".$enttypeID."','".$proptypeID{"ErrorType"}."','3')";
$sth = $dbh->prepare($query);
$sth->execute() or die $@;
$query = "insert into ApplicationEntityProperty values('','".$appID."','".$enttypeID."','".$proptypeID{"ipaddress"}."','1')";
$sth = $dbh->prepare($query);
$sth->execute() or die $@;
$sth->finish();
$dbh->disconnect();
print "Database update completed.\n";
exit 0;
#!/usr/local/groundwork/perl/bin/perl
my $check_interval=60;
my $last_check_time=time;
while(1) {
# build a list of nagios.cfg files to stat
my @files=();
my @files=`find /usr/local/groundwork/nagios/etc -name nagios.cfg`;
foreach $file (@files) {
my $message='';
chomp $file;
my $result=`/usr/bin/stat -c %Y $file`;
chomp $result;
if ($result gt $last_check_time ) { # if file has changed
my $line = `/bin/grep "nagios.cfg generated" $file`;
chomp $line;
my ($date,$user) = $line=~/generated\s(\d\d\d\d-\d\d-\d\d\s\d\d:\d\d:\d\d)\sby\s(\S+)\sfrom/;
$message="File $file updated by user $user at $date.";
log_audit_message($file,$message);
}
}
$last_check_time=time;
sleep $check_interval;
}
exit 0;
sub log_audit_message {
my $file = shift;
my $message = shift;
my $result = `/usr/bin/logger -p local4.info $message`;
}
#!/bin/sh
# Script for Supervise : Audit Nagios Feeder
exec /usr/local/groundwork/common/bin/setuidgid nagios /usr/local/groundwork/foundation/feeder/audit-nagios.pl
filter f_audit-nagios { (match("updated by user")); };
template t_gw_audit-nagios_feeder
{
template("<GENERICLOG MonitorServerName='localhost' Device='$HOST' ApplicationType='AUDIT' MonitorStatus='WARNING' ReportDate='$YEAR-$MONTH-$DAY $HOUR:$MIN:$SEC' Severity='WARNING' ipaddress='$HOST' SubComponent='$PROGRAM' TextMessage='$MSGONLY' />\n");
};
destination d_gw_audit-nagios_feeder { tcp("localhost" port(4913) template(t_gw_audit-nagios_feeder)); };
log { source(src); filter(f_audit-nagios); destination(d_gw_audit-nagios_feeder); };
ハウツー: アクティブディレクトリ、OpenLDAP および LDAP を統合する
[このウィンドウを閉じるには、ハウツーのリンクを再クリックしてください]
Groundwork Monitor は、外部認証ソースを介してのシングルサインオンをサポートします。認証サービスは、 Microsoft アクティブディレクトリや標準準拠の LDAP サーバによって提供することができます。ほとんどのユーザアカウントは、事前に GroundWork Monitor 内で定義する必要があります。
まだユーザアカウントにシステム固有のロールと権限をアサインする必要があり、後は、認証に LDAP を使用する変更だけで終わりです。LDAP のために GroundWork の JBoss Portal を構成設定することで、ユーザパスワードや外部ディレクトリサービスで管理されるロールのメンバーシップなど、他の詳細を管理することができるようになります。ログインの際、ユーザアカウントは GroundWork の JBoss Portal と同期し、ユーザはデフォルトのロールに割り当てられます。
実際には、LDAP ユーザには、GroundWork の JBoss Portal 内のロール割り当ては何の影響も有りません。ポータルにサインインするユーザのためのロールを割り当てるために、このようにして LDAP ディレクトリを使用しなければなりません。これは、GroundWork Monitor の以前のバージョンと比べると、大きな変化です。このハウツーは、セットアップ、構成設定、ユーザへのロール割り当ての例を通しで実施します。
その他の代替構成と同様に、LDAPS や LDAP over SSL を有効にすることも可能です。さまざまのオプションや GroundWork Monitor の LDAP セットアップをカスタマイズしたい場合、ここで参照できる JBoss LDAP コンフィギュレーションの参考文献をご覧ください。
また、LDAP と アクティブディレクトリのインストールの仕方を BarCAMP Webcast :http://www.groundworkopensource.com/resources/webcasts/barCAMP/で見ることができます。
アクティブディレクトリとの統合
始める前に、下記の点を明確にする必要があります:
LDAP ユーザはポータル管理アプリケーションを使用するロールにアサインすることができません。
LDAP ユーザはポータル内で定義する必要がありません(これは GroundWork Monitor 5.x と異なります)。
LDAP パラメータの構成設定はユーザインタフェースの外で行われ、 gwservices のリスタートが必要です。
GroundWork Monitor は LDAP サーバ名、管理ユーザ名とパスワード、およびアクセスを許すユーザを含む特定のコンテナや組織ユニットで構成設定される必要があります。管理ユーザは、単なる通常のユーザである--特別の権限が必要ない--ことに注意してください。
これらの値は、特定のロケーションにある XML 構成ファイルへの入力され、GroundWork JBoss Portal はその構成を有効にするためのリスタートされる必要があります。
この手順は、実施例で示すのが最適です。下記は、Microsoft アクティブディレクトリ認証のために GroundWork Monitor を構成設定する実施例です。 LDAP の構成設定は同様で、その後の実施例で説明します。
[必須]あなたがアクセスできるアクティブディレクトリのドメインコントローラ
[必須]あなたがユーザを保存したコンテナをブラウズ権限を持つアカウン
例: ldapauth, context:
cn=ldapauth,ou=GTWUsers,dc=demo,dc=com
[任意]望ましいアクセスレベルのためのポータル内のロール
[任意]ポータル内のロールにマッチしたコンテナとグループセットアップ
[便利]adsiedit.msc utility
cn=ldapauth,ou=GTWUsers,dc=demo,dc=com
デフォルトでは、アクティブディレクトリシステムは、下記のようにシステムで定義されたコンテナの中にすべてのユーザを登録します::
cn=Users,dc=<myorganization>,dc=<com>
上記の <myorganization> は、あなたのインプリメンテーションでのドメイン名、 <com> は一般的なデフォルトのサフィックス(添え字)です。つまり、アクティブディレクトリのドメインが groundworkers.com であれば、ユーザは下記のように保存されます:
cn=Users,dc=groundworkers,dc=com
アクティブディレクトリ内のすべてのユーザが GroundWork サーバにログインできるようにしたい場合、このコンテナを使用できます。これは実際には推奨しません。その代わり、GroundWork は、その目的のために新しい組織ユニットを作り、あなたの GroundWork ユーザとグループをそこに置くことをお勧めします、
注意: アクティブディレクトリがユーザのためにコンテナを使い、そこで新しい組織ユニットを作成した場合、 cn= 文字列 を ou= に調整する必要があることを意識してください。たとえば、GWUsers という新しい組織ユニットを作成した場合、あなたのドメイン文字列は下記のようになるでしょう:
ou=GWUsers,dc=groundworkers,dc=com
下記のようにはなりません
cn=GWUsers,dc=groundworkers,dc=com
この例は、あなたが組織ユニット GWUsers を作成し、あなたのユーザをこの ou に追加するという前提です。 アクティブディレクトリで認証されたユーザへのロールの割り当ては、アクティブディレクトリ内のグループへのユーザ追加によって行われるので、この例では、あなたが GWUsers コンテナの中に Operator と Admin グループを作成し、GroundWork ポータル の Operator ロールのメンバーは Operator グループ、GroundWork ポータル の administrators になるユーザは Admin グループであることを前提としています。
1. アクティブディレクトリ認証を有効にするため、root か同等の権限でコマンドラインでログインし、下記を修正します:
/usr/local/groundwork/foundation/container/webapps/jboss/jboss-portal.sar/conf/login-config.xml
2. このファイルには、下記の置き換えを行った、後述の内容を持つ必要があります:
my_ad_domain_controller を、あなたのアクティブディレクトリのドメインコントローラのホスト名か IP アドレスに。
Administrator を、groundwork ユーザが格納されている ou の管理ユーザのユーザ名に。
adminpassword を、上記で指定した管理ユーザのパスワードに。
GWUsers,dc=groundworkers,dc=com を、あなたが使用するドメインと ou 名に。
<?xml version='1.0'?>
<!DOCTYPE policy PUBLIC
"-//JBoss//DTD JBOSS Security Config 3.0//EN"
"http://www.jboss.org/j2ee/dtd/security_config.dtd">
<policy>
<!-- For the JCR CMS -->
<application-policy name="cms">
<authentication>
<login-module code="org.apache.jackrabbit.core.security.SimpleLoginModule" flag="required"/>
</authentication>
</application-policy>
<application-policy name="portal">
<authentication>
<login-module code="org.jboss.portal.identity.auth.SynchronizingLDAPExtLoginModule" flag="sufficient">
<module-option name="synchronizeIdentity">true</module-option>
<module-option name="synchronizeRoles">false</module-option>
<module-option name="preserveRoles">true</module-option>
<module-option name="additionalRole">Authenticated</module-option>
<module-option name="defaultAssignedRole">User</module-option>
<module-option name="userModuleJNDIName">java:/portal/UserModule</module-option>
<module-option name="roleModuleJNDIName">java:/portal/RoleModule</module-option>
<module-option name="membershipModuleJNDIName">java:/portal/MembershipModule</module-option>
<module-option name="userProfileModuleJNDIName">java:/portal/UserProfileModule</module-option>
<module-option name="java.naming.factory.initial">com.sun.jndi.ldap.LdapCtxFactory</module-option>
<module-option name="java.naming.provider.url">ldap://my_ad_domain_controller:389</module-option>
<module-option name="java.naming.security.authentication">simple</module-option>
<module-option name="bindDN">Administrator</module-option>
<module-option name="bindCredential">adminpassword</module-option>
<module-option name="baseCtxDN">ou=GWUsers,dc=groundworkers,dc=com</module-option>
<module-option name="baseFilter">(sAMAccountName={0})</module-option>
<module-option name="rolesCtxDN">ou=GWUsers,dc=groundworkers,dc=com</module-option>
<module-option name="roleFilter">(sAMAccountName={0})</module-option>
<module-option name="roleAttributeID">memberOf</module-option>
<module-option name="roleAttributeIsDN">true</module-option>
<module-option name="roleNameAttributeID">cn</module-option>
<module-option name="searchScope">ONELEVEL_SCOPE</module-option>
<module-option name="allowEmptyPasswords">false</module-option>
</login-module>
<login-module code = "org.jboss.portal.identity.auth.DBIdentityLoginModule" flag="sufficient">
<module-option name="dsJndiName">java:/PortalDS</module-option>
<module-option name="principalsQuery">SELECT jbp_password FROM jbp_users WHERE jbp_uname=?</module-option>
<module-option name="rolesQuery">SELECT jbp_roles.jbp_name, 'Roles' FROM jbp_role_membership INNER JOIN jbp_roles ON jbp_role_membership.jbp_rid = jbp_roles.jbp_rid INNER JOIN jbp_users ON jbp_role_membership.jbp_uid = jbp_users.jbp_uid WHERE jbp_users.jbp_uname=?</module-option>
<module-option name="hashAlgorithm">MD5</module-option>
<module-option name="hashEncoding">HEX</module-option>
<module-option name="additionalRole">Authenticated</module-option>
</login-module>
</authentication>
</application-policy>
</policy>
3. ファイルを保存します。
4. ここで GroundWork ポータルを再起動します。すべてのユーザがログアウトされるので、これは必ず停止時間の範囲で行ってください。
/etc/init.d/groundwork stop gwservices
/etc/init.d/groundwork start gwservices
この時点で、 GWUsers ou 内のユーザは、ログインすることができる筈です。ログインした人がポータル内のロールと同じ名称のグループのメンバーでない場合、デフォルトの User ロールにマッピングされます。これで、彼らは、Status(ステータス)ビューアを含む、ポータルスクリーンの参照のみのアクセスができるようになります。
ログインした人が Operator グループのメンバーの場合、Event Console(イベントコンソール)や Nagios 画面、また、Status(ステータス)画面の Actions(アクション)メニューへのアクセス権を持ちます。
ログインした人が Admin グループのメンバーの場合、GroundWork ポータルへの完全なアクセス権を持ちます。
この時点では、ポータルでのみ定義されたユーザ(たとえば、 admin ユーザなど)とアクティブディレクトリで定義されたユーザがログインすることができます。これは便利で、アクティブディレクトリ・サーバーの障害が発生した場合にアクセス継続を保証するのに必要です。しかしながら、セキュリティリスクがあります。GroundWork は、LDAP/アクティブディレクトリのアクセスが稼動したことを確認したら、内部ユーザのアクセスは閉鎖することを推奨します。これを行うには、下記のファイルを変更します:
/usr/local/groundwork/foundation/container/webapps/jboss/jboss-portal.sar/conf/login-config.xml
下記の行を:
<login-module code="org.jboss.portal.identity.auth.SynchronizingLDAPExtLoginModule" flag="sufficient">
下記のように変更します
<login-module code="org.jboss.portal.identity.auth.SynchronizingLDAPExtLoginModule" flag="required">
そして、下記のようにして、下記の行をコメントアウト( <!-- と --> 文字ではさむ)します:
<!--<login-module code = "org.jboss.portal.identity.auth.DBIdentityLoginModule" flag="sufficient">
<module-option name="dsJndiName">java:/PortalDS</module-option>
<module-option name="principalsQuery">SELECT jbp_password FROM jbp_users WHERE jbp_uname=?</module-option>
<module-option name="rolesQuery">SELECT jbp_roles.jbp_name, 'Roles' FROM jbp_role_membership INNER JOIN jbp_roles ON jbp_role_membership.jbp_rid = jbp_roles.jbp_rid INNER JOIN jbp_users ON jbp_role_membership.jbp_uid = jbp_users.jbp_uid WHERE jbp_users.jbp_uname=?</module-option>
<module-option name="hashAlgorithm">MD5</module-option>
<module-option name="hashEncoding">HEX</module-option>
<module-option name="additionalRole">Authenticated</module-option>
</login-module>-->
ここであなたが行っているのは、認めらたたログインモジュールのひとつ(DBIdentityLoginModule)を削除し、残ったひとつを sufficient(十分)からrequired(必須)に変え、今後 GroundWork ポータル内のみのユーザ ID とパスワードは認めないことを示すことです。緊急なポータルアクセスのためこの手順を元に戻す必要がある場合、完全に DBIdentityLoginModule を削除せず、コメントアウトするのは良い考えです。元に戻すこと必要な場合、コメント文字を削除して SynchronizingLDAPExtLoginModule フラグをsufficient に確実に戻してください。
LDAP/アクティブディレクトリを無効にする場合、 DBIdentityLoginModule を enabled(有効)にしたまま(あるいは元に戻す)でない限り、 GroundWork ポータルにログインできなくなります。 DBIdentityLoginModule が enabled(有効)であれば、LDAP/アクティブディレクトリからのユーザを無効化(あるいは削除)しても、効果はありません。この場合、 GroundWork ポータルの中で別々にユーザを削除したり無効化する必要があります。
GroundWork からデフォルトで提供されているロール名と異なるグループを使用したい場合、まず、GroundWork 内にそのロールを作成し、それらのロールにアプリケーションを割り当て、そして、LDAP/アクティブディレクトリ内に GroundWork ポータル内のロールと同じ名前(同じ Display Name:表示名ではありません)を作成します。これで、これらのグループにユーザを追加することができ、ユーザがログインしたときにそのロールが割り当てられます。
ロールは追加型です。ひとつ以上のロールを持つユーザは、それらのロールすべてのアクセス権の上位集合を有します。
I始める前に、下記の点を明確にする必要があります;
OpenLDAP は構成設定が難しいです。
OpenLDAP はデフォルトで匿名のブラウジングを許容しています。これは良くないことです。常に コンテナをアクセスするよう GWME ユーザを構成設定してください。
ユーザは User と Role コンテンツのコンテナ内のツリーをブラウズするアクセス権を持つ必要があります。
[必須]1台の OpenLDAP サーバ
[必須]OpenLDAP への管理アクセス(Users と Roles のセットアップのため)
[必須]Users と Roles のためのコンテナをスキャンする権限を有するユーザアカウント
[便利]LDAP ブラウザ
OpenLDAP 構成設定は、アクティブディレクトリと同様です。要求条件も同様です、主な違いは LDAP 自体の構成設定にあり、アクティブディレクトリではポータルのロールへのアクセスがグループのメンバーシップでコントロールされるのに対して、 ロールオブジェクトのためのコンテナの作成となります。
OpenLDAP は、(アクティブディレクトリができるように)クエリに対して匿名(anonymous)アクセスを認めるよう構成設定できます。これは推奨しませんが、サポートされています。
この例では、OpenLDAP サーバが GWUsers というユーザコンテナを持ち、GWRoles というロールコンテナを持つよう構成設定されていることを前提とします。ここに、ldapadmin での設定例のスクリーンショットがあります( http://ldapadmin.sourceforge.net/)。
図: Role と User コンテナ
図: ユーザ
はじめるには OpenLDAP サーバにログインし、 Users コンテナ(デフォルトは ou=People)をセットアップし、そして Roles コンテナをセットアップして、Users コンテナにユーザを追加して、ユーザにロールを追加します。あなたの LDAP ユーザにログインをブラウジングのためにテストするのは良い考えです。注: root ユーザはデフォルトでは cn=manager で、 uid=root オブジェクトは People コンテナの中にあり、デフォルトのコンテクストはたとえば右のようになります: cn=manager,dc=groundworkers,dc=com
アクティブディレクト認証を有効にするため、コマンドラインで root か同等権限でログインし、下記を変更します(内容の置き換えについては、後述):
/usr/local/groundwork/foundation/container/webapps/jboss/jboss-portal.sar/conf/login-config.xml
OpenLDAP 認証を有効にするため、コマンドラインで root か同等権限でログインし、下記を変更します:
/usr/local/groundwork/foundation/container/webapps/jboss/jboss-portal.sar/conf/login-config.xml
このファイルがアクティブディレクトリの例と同じ内容を持つようにします。例外として、位置設定と管理ユーザが異なること、、ロールのいくつかのオプションも変更します。特に、匿名アクセスが無効(推奨設定です)であれば、下記のセクションを入れます(もちろん、ldapadmin と ldapadminpassword は、LDAP ツリーのブラウズを認められたユーザのユーザ名とパスワードで置き換えられるでしょう):
<module-option name="bindDN">cn=ldapadmin,dc=mycompany</module-option>
<module-option name="bindCredential">ldapadminpassword</module-option>
これらのユーザとロール設定を使って、適切なロケーションにを置き換えてください:
<module-option name="baseCtxDN">ou=GWUsers,dc=mycompany</module-option>
<module-option name="baseFilter">(uid={0})</module-option>
<module-option name="rolesCtxDN">ou=GWRoles,dc=mycompany</module-option>
<module-option name="roleFilter">(memberUid={0})</module-option>
<module-option name="roleAttributeIsDN">true</module-option>
<module-option name="roleAttributeID">cn</module-option>
<module-option name="roleNameAttributeID">cn</module-option>
ファイルを保存し、下記のコマンドでポータルをリスタートする必要があります。すべてのユーザがログアウトされるので、これは必ず停止時間の範囲で行ってください。
/etc/init.d/groundwork stop gwservices
/etc/init.d/groundwork start gwservices
必ずアクティブディレクトリの例、特にバックドアアクセスの無効化について読んでください。
GroundWork ポータルへのアクセスを調整のため、手順はアクティブディレクトリの例と同様です。主な違いは下記の通り:
通常 AD はユーザと同じコンテナにグループをおきますが、 OpenLDAP は、ロール(技術的にはグループです)のために異なるコンテナを使います。
セットアップするために、AD のためにと同様、GWME 内のロールを OpenLDAP 内のロールに一致させ、 OpenLDAP 内のロールにユーザを追加します。
LDAPs は LDAP over ssl です。
始める前に、下記の点を明確にする必要があります;
LDAPs は認証および暗号キーを必要とします。
アドミニストレータは、おそらく、これをどこか安全な場所でテキストファイルとして持っているでしょう。
この手順は、証明書の抽出を実施しますので、この手順の正確な部分を使う際に注意が必要です。
[必須]LDAP がON にされた1台の OpenLDAP サーバ
[必須]login-config.xml を編集する必要があるので、OpenLDAP の設定が完了しているが、あなたがポータルサービスをリスタートする前には停止していること。
LDAPS (secure LDAP)を有効にしたい場合、login-config.xml ファイルに追加パラメータを修正し、LDAPS からそれが使用される Jboss にキーストア(証明書)を入手してインポートすることですることで実施できます。
変更するパラメータは下記です。これらを org.jboss.portal.identity.auth.SynchronizingLDAPExtLoginModule セクションの中に置き、同じ名前のパラメータを置き換えます
<module-option name="java.naming.provider.url">ldaps://my_ldaps_server:636</module-option>
<module-option name="java.naming.security.protocol">ssl</module-option>
下記のコマンドで証明書を読み出しで、まずキーストアをインポートし、host.domain.com をあなたの LDAPS サーバ名で置き換えます:
openssl s_client -connect host.domain.com:ldaps
そして、その証明書をデフォルトのキーストア、パスワード内にインポートします:changeit (デフォルトの java keystore のパスワード):
keytool -import -file ~/ldaps.pem -alias ldaps.groundwork.groundworkopensource.com \
-keystore /usr/local/groundwork/java/jre/lib/security/cacerts
xml ファイルを編集して文字を間違えない、または誤植しないことは、難しいことです。残念ながら login-config.xml はきわめて敏感であり、このファイルが正確でない場合、認証は完全に壊れてしまいます。エラーを見つけるためのひとつの方法は、gwservices をリスタートしている時にフレームワークのログファイルの tail を見ることです:
tail ?f /usr/local/groundwork/foundation/container/logs/framework.log
これにより、深刻なエラーがあるかどうか分かります。しかしながら、一時的にデバッギングを有効にしたくなるかもしれません。ファイル /usr/local/groundwork/config/log4j.xml 内に下記の行を挿入してみて下さい: /usr/local/groundwork/config/log4j.xml:
<category name="org.jboss.security">
<priority value="DEBUG"/>
</category>
<category name="org.jboss.portal.identity">
<priority value="DEBUG"/>
</category>
<category name="org.jboss.portal.core.identity">
<priority value="DEBUG"/>
</category>
これにより framework.log ファイルにより多くのロギングが行われます。注意: これをそのまま放置しないでください! システムの性能に影響を及ぼします。
log4j.xml 内でデバッグロギングを有効や無効にした場合、gwservices のリスタートは必要ありません。
ハウツー: MySQL の root ユーザパスワードをリセットする
[このウィンドウを閉じるには、ハウツーのリンクを再クリックしてください]
注意: この手順は、システムへのアクセスを中断します。
1. gwservices の停止:
/usr/local/groundwork/ctlscript.sh stop gwservices
2. httpd の停止:
/usr/local/groundwork/ctlscript.sh stop apache
3. mysqld の停止と、--skip-grant-tables --user=root オプションを使っての再起動::
/usr/local/groundwork/ctlscript.sh stop mysql
/usr/local/groundwork/mysql/bin/mysqld --skip-grant-tables --user=root &
4. mysqld サーバへの接続:
/usr/local/groundwork/mysql/bin/mysql -u root
5. mysql クライアントの中で、下記の命令を発行:
mysql> UPDATE mysql.user SET Password=PASSWORD('newpwd') WHERE User='root';
mysql> FLUSH PRIVILEGES;
(上記の newpwd をあなたが付けたい実際の root パスワードで置き換えて行ってください)
6. mysql のコマンドライン・インタフェースを抜ける:
mysql> quit
7. 上記で起動した mysql のスタンドアロンプロセスを KILL :
killall mysqld
8. 稼動 mysql インスタンスの再起動:
/usr/local/groundwork/ctlscript.sh restart mysql
9. gwservices の再起動:
/usr/local/groundwork/ctlscript.sh restart gwservices
10. httpd の再起動:
/usr/local/groundwork/ctlscript.sh restart apache
11. ここで新しいパスワードを使ってコネクトできるようになるでしょう。
ハウツー: monarch データベースのバックアップをリストアする
[このウィンドウを閉じるには、ハウツーのリンクを再クリックしてください]
1. 誰もシステムにログインしていないことを確認します:
gwservices の停止:
/usr/local/groundwork/ctlscript.sh stop gwservices
Nagios デーモンの停止:
/usr/local/groundwork/ctlscript.sh stop nagios
httpd の停止:
/usr/local/groundwork/ctlscript.sh stop apache
テンポラリのセッションファイルを削除:
rm -rf /tmp/sess*
rm -rf /tmp/tpl*
2. ターミナルセッションを開き、root としてログインします。
3. デイレクトリを移動します:
cd /usr/local/groundwork/core/monarch/backup
4. 下記の名前のファイルがあることを確認します:
monarch_backup_<timestamp>.sql
5. 現在の Monarch データベースをドロップします:
mysqladmin -u root -p drop monarch
6. Monarch データベースを再生成します:
mysqladmin -u root -p create monarch
7. システムプロンプトに下記のコマンドを投入して、古いデータベースをリストアします:
mysql -u root -p monarch < monarch_backup_<timestamp>.sql
8. gwservices をリスタートします:
/usr/local/groundwork/ctlscript.sh start gwservices
9. httpd をリスタートします:
/usr/local/groundwork/ctlscript.sh start apache
10. Nagios をリスタートします:
/usr/local/groundwork/ctlscript.sh start nagios
11. ブラウザを再度立ち上げた後、ブラウザのキャッシュをクリアしてください。
12. 次に、リストアした構成を参照して確認するために、Web インタフェースを使い、以下の手順でリストアした monarch データベースをコミットします:Configuration(コンフィギュレーション)アプリケーションのタブ、Control(コントロール)オプション、 Pre flight test(プリフライトテスト)、Commit(コミット)、Backup(バックアップ)、そして、Commit(コミット)の順で選択します。
[このウィンドウを閉じるには、ハウツーのリンクを再クリックしてください]
1. nagios.cfg file? ファイル内の以下のパラメータが正しく設定されていますか?
perfdata_timeout = 60
process_performance_data = 1
service_perdata_command = process_service_perfdata_file
service_perfdata_file = /usr/local/groundwork/nagios/eventhandlers/service_perfdata.log
service_perfdata_file_template = $LASTSERVICECHECK$\t$HOSTNAME$\tSERVICEDESC$\t$SERVICEOUTPUT$\t$SERVICEPERFDATA$
service_perfdata_file_mode = w
service_perfdata_file_processing_interval = 300
service_perfdata_file_processing_command = process_service_perfdata_file
2. ディレクトリ/usr/local/groundwork/nagios/eventhandlers 内に、ファイル service_perfdata.log がありますか? そして、そのファイルに現在の日付と時間から過去10分以内のタイムスタンプが付いていますか?
3. ディレクトリ /usr/local/groundwork/nagios/eventhandlers 内に、ファイル process_service_perf_db_file.pl がありますか? そして、それには正しいオーナーとパーミッションが付いていますか?
4. ディレクトリusr/local/groundwork/rrd 内の RRD ファイルに、ほぼ現在時間のタイムスタンプが付いていますか?
5. Configuration(コンフィギュレーション)> Performance(パフォーマンス)のアプリケーション内に、サービスフィールドがあなたがグラフ化しようとするサービスの名称と一致するエントリがありますか?
ハウツー: パフォーマンスのイベントハンドラのロギングを有効(enable)にする
[このウィンドウを閉じるには、ハウツーのリンクを再クリックしてください]
1. 右記のファイルを編集します: /usr/local/groundwork/nagios/eventhandlers/process_service_perf_db_file
2. 右記の行を: my $debug = 0
3. 右記のように変更します: my $debug = 3
注意: トラブルシュートが終了したら、これを "0" に戻すことをお忘れなく。
4. おおよそ5分後に、ファイル /usr/local/groundwork/nagios/eventhandlers/process_service_perf.log が作られます。
5. 次に、このログファイルの中でトラブルシューティングしているサービスの名前を探します。
[このウィンドウを閉じるには、ハウツーのリンクを再クリックしてください]
下記がパフォーマンス画面からホストを削除する簡便な手順です。
1. コマンドラインから mysql を起動します: # mysql
2. root ユーザとしてログインし、GroundWork Monitor のインストール時にパスワード設定をしていればパスワードを入力します。
3. monarch のデータベースを選びます: mysql> use monarch
4. host_service テーブルから、除きたいエントリを削除します。例えば:
ホスト "foo" のための全エントリを削除するには:
mysql> delete from host_service where host like 'foo'
サービス "foo_service" のための全エントリを削除するには
mysql> delete from host_service where service like 'foo_service'
ホストから個別のサービスを削除し、他を残すには:
mysql> delete from host_service where host like 'foo' and service like 'foo_service'
ハウツー: インストール後、可用性レポート(Availability Reports)のデータを見る
[このウィンドウを閉じるには、ハウツーのリンクを再クリックしてください]
GroundWork Monitor のインストール後すぐには可用性レポート(Availability Reports)のデータは表示されません。これらのレポートのデータは通常、一日に一度、夜間に cron ジョブとして実行される dashboard_data_load.plと dashboard_avail_load.plスクリプトによって作成されます。
これは期待通りの動きです。必要であればデータを作成するためこれらのスクリプトを手動で動かすことができます。ふたつのスクリプトは、下記のディレクトリにあります:
/usr/local/groundwork/reports/utils
ユーザ nagios の crontab 内に、その cron ジョブがあります。下記のコマンドを投入することで参照できます::
crontab -l -u nagios
下記のように表示されるはずです:
50 23 * * * /usr/local/groundwork/reports/utils/dashboard_data_load.pl > /usr/local/groundwork/reports/utils/log/dashboard_data_load.log 2>&1 0 1 * * * /usr/local/groundwork/reports/utils/dashboard_avail_load.pl > /usr/local/groundwork/reports/utils/log/dashboard_avail_load.log 2>&1
ハウツー: 構成設定後、ログレポート(Log Reports)のデータを見る
[このウィンドウを閉じるには、ハウツーのリンクを再クリックしてください]
ログファイルレポートは Reports(レポート)アプリケーションのタブを使って見ることができます。ログファイルレポートを設定した後すぐにはそれらのデータは表示されません。このデータは通常、一日に一度、夜間に cron ジョブとして実行される importer.pl スクリプトで作成されます。これは期待通りの動きです。必要であれば、早くデータを生成するために、このスクリプトを手動で実行することができます。
このスクリプトは、下記のディレクトリのエントリから毎日実行されます:
/var/spool/cron/nagios
そのスクリプトへの全パスが使用されるべきです。実行するコマンドは下記のようになります::
/usr/local/groundwork/log-reporting/bin/importer.pl
ハウツー: Apache の HTTPS (SSL) サポートを有効にする
[このウィンドウを閉じるには、ハウツーのリンクを再クリックしてください]
GroundWork Monitor は、Web ブラウザから Apacte へのコネクションを暗号化する SSL の使用をサポートしていますが、この機能はデフォルトでは無効になっています。この機能を有効にしたい場合、まず最初に Apache が使うための SSL 認証を作成もしくはインポートし、該当する Acpache 構成ファイル内の SSL サポートを有効にする必要があります。 SSL サポートを有効にするのに必要なバイナリーとライブラリーは、GroundWork Monitor ディストリビューションに含まれます。下記の手順は Apache Web サーバーのために SSL を有効にする方法を概説します。
詳しくは、右の Apache のサイトを参照ください: http://httpd.apache.org/docs/2.2/ssl/
GroundWork Monitor 内の SSL サポートの有効化:
1. あなたが再使用しようとする Web サーバに既存の SSL 認証とキーファイルがある場合、それらのファイルを参照するよう /usr/local/groundwork/apache2/conf/extra/httpd-ssl.conf ファイルを編集する必要があります。そのファイルは、起動時に Apache サーバーによって読むことができるパーミッションを持つ必要があります。外部認証局から認証を得たものであれば、既存のファイルを使用することは、普通のことでしょう。
2. あなたが、新らたに自分で付与した認証とキーファイルを作成したい場合、ターミナルセッションから、システムに root ユーザとしてログインして下記のコマンドを使用してください。これにより、適切な当なデフォルトのファイル名と認証設定が使用されることが保証され、正しいパーミッションが使用されることが保証されるでしょう。
cd /usr/local/groundwork/apache2/conf
openssl genrsa -out server.key 2048
openssl req -new -x509 -key server.key -out server.crt -days 1095 -set_serial `date +%s`
注意: バッククォートで囲まれている date コマンド実行(`date +%s`)は、その出力を捕捉して、コマンドラインの中で使用するために使われます。
このコマンドでは、作成された日付から3年間有効(-days 1095)な認証を作成されます。 期限切れの日付をより将来に、たとえば、10年間(-days 3653)よりも長い期間を指定したいかもしれません。
-set_serialオプションは、この認証のために、願わくはユニークなシリアル番号、あるいはその逆に、固定デフォルトの 0 を指定してください。認証を作成する毎に、このオプションに異なる値を使用すると、いくつかのブラウザで発生する問題を起こさないようにできます。上述の date コマンドによるタイムススタンプの整数は、この意味で、十分なユニーク性を提供する一般的な手法です。
上述の最後のコマンドからの質問に回答してください。 Common Name のプロンプトに対しては、二つの選択が有ります。あなたのドメインの外からシステムにアクセスするユーザがいる場合、あなたの Web サーバの完全修飾ホスト名(fully qualified hostname)を回答してください。ドメイン内からのみのアクセスの場合、完全修飾でないあなたの Web サーバのホスト名を使ってもよいでしょう。
You are about to be asked to enter information that will be incorporated into your
certificate request. What you are about to enter is what is called a Distinguished Name
or a DN. There are quite a few fields but you can leave some blank. For some fields
there will be a default value. If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [GB]:
State or Province Name (full name) [Berkshire]:
Locality Name (eg, city) [Newbury]:
Organization Name (eg, company) [My Company Ltd]:
Organizational Unit Name (eg, section) []:
Common Name (eg, your name or your server's hostname) []:
Email Address []:
3. 下記のファイルを編集します:
/usr/local/groundwork/apache2/conf/httpd.conf
4. 下記の行の # シンボルを削除します(注: Replace my-server は apache が稼動している実際のサーバ名で置き換えます):
#LoadModule rewrite_module modules/mod_rewrite.so
#Include conf/extra/httpd-ssl.conf
#RewriteEngine On
#RewriteCond %{SERVER_PORT} !^443$
#RewriteRule ^/(.*)$ https://my-server/$1 [NE]
5. あなたが行った変更を下記に保存します:
/usr/local/groundwork/apache2/conf/httpd.conf
6. 下記のファイルを編集し、
/usr/local/groundwork/config/status-viewer.properties
下記を変更します。
secure.access.enabled=true
7. 下記のファイルを編集し、
/usr/local/groundwork/config/report-viewer.properties
下記を変更します。
secure.access.enabled=true
8. 下記のファイルを編集し、
/usr/local/groundwork/config/viewer.properties
下記の行の # シンボルを削除します
#base_url=http://127.0.0.1:8080
base_url=https://myserver (web-サーバのホスト名)を変更します。
9. gwservices をストップし、スタートします。
/usr/local/groundwork/ctlscript.sh stop gwservices
/usr/local/groundwork/ctlscript.sh stop apache
/usr/local/groundwork/ctlscript.sh start gwservices
/usr/local/groundwork/ctlscript.sh start apache
10. 下記のサイトを参照します:
https://myserver/
GroundWork Open Source, Inc. c2009