「Linux」カテゴリーアーカイブ

Linux関連情報

nagios入れたけど、SSHがCRITICALになってるよ( ゚Д゚)

nagiosが起動して、良し!見てみよう!!とログインした。

あれ?CGI動かない?

なぜなぜ?

ということで、cgi.cfgをnagiosadminのIDで設定されている項目がズラズラ~と

# grep nagiosadmin cgi.cfg
cgi.cfg:authorized_for_system_information=nagiosadmin
cgi.cfg:authorized_for_configuration_information=nagiosadmin
cgi.cfg:authorized_for_system_commands=nagiosadmin
cgi.cfg:authorized_for_all_services=nagiosadmin
cgi.cfg:authorized_for_all_hosts=nagiosadmin
cgi.cfg:authorized_for_all_service_commands=nagiosadmin
cgi.cfg:authorized_for_all_host_commands=nagiosadmin

これじゃあ、動くものも動かんわなぁ~ということで、過去の記事を修正しなくちゃいけないんだけど・・・先に、passwdファイルを元に戻してやった。
もしくは、passwdファイルを再構築してやることで解消。

# htpasswd -c /etc/nagios/passwd nagiosadmin

パスワード自体はなんでもOKなのですが、ユーザIDを変更すると面倒だということが判明しました。
取り敢えず、これで治ったということは、cgi.cfgのnagiosadminのユーザIDも変更しておく必要があったということですね。
後で、修正するということで。。。

さて、ここから本題の、SSHがCRITICALエラーになってしまう件について記載する。

理由は簡単で、SSHのデフォルトポートは22番です。
当該サーバにおけるポート番号はセキュリティを強化するためにデフォルトポートを使用しておりません。
そういったサーバは随所に存在するので、参考までに。
SSHのデフォルトポートは以下で確認することが可能です。

# grep Port /etc/ssh/sshd_config
Port 1234
#GatewayPorts no

ここでは、1234ポートが使用されていることが解ります。
(1234ポートはダミーです)

このポート番号をnagiosでSSHを監視する際のポートとして指定する必要があります。

define service{
use local-service ; Name of service template to use
host_name localhost
service_description SSH
# check_command check_ssh
check_command check_ssh! -p 1234
# notifications_enabled 0
notifications_enabled 1
}

こんな感じです。
ついでに、notifications_enabledも0→1に設定しておきます。

notifications_enabledの意味は以下の通りです。
このディレクティブはこのホストの通知を有効にするか無効にするか決定します。値: 0 = ホスト通知無効、1 = ホスト通知有効。

ホストへの通知を無効にするか有効にするかを設定しています。
ローカルホストなので、必要なのかどうか解りませんが、多分1にする方が良さそうなので、1に設定しておきます。
監視対象としてして見た場合には設定した方が良さそうです。

誰かローカルホストの場合でも設定するべきなのかどうか解る人はコメント入れてください。

ちなみに、コメント入力時のメールアドレスは、ダミーでも入力できます。(xxxx@yyyyでも入るんじゃないかな?この世に存在しなくても大丈夫です。)メールアドレスは実際には管理しておらず、単に迷惑な書き込みを抑止するためだけに設定しています。

 

nagiosの日付表示フォーマットを変更する。

nagiosの日付表示フォーマットは、以下のファイルで定義されている。
 /etc/nagios/nagios.cfg

ファイル中には以下の記載があり、変更することが出来る。

# DATE FORMAT OPTION
# This option determines how short dates are displayed. Valid options
# include:
# us (MM-DD-YYYY HH:MM:SS)
# euro (DD-MM-YYYY HH:MM:SS)
# iso8601 (YYYY-MM-DD HH:MM:SS)
# strict-iso8601 (YYYY-MM-DDTHH:MM:SS)
#

date_format=us
 ↓date_format=iso8601       <== YYYY-MM-DD HH:MM:SSにした例

変更された結果は、その内解るでしょう(^^ゞ

まだ、色々と設定をしないと解らないですね。

 

 

nagiosのIDとパスワードを変更する。【すぐに変更するのは辞めた方が良い!!】

前回までにnagiosのインストールが完了していることを前提に作業を進めます。’

まず最初に言っておきたいのが、IDとパスワードの変更です。

デフォルトで
ID      : nagiosadmin
パスワード  : nagiosadmin
となっています。

パスワードの変更は下記のファイルを参照してください。

 > more /etc/nagios/passwd

 nagiosadmin:WxdY3uo4PKyFg

なんとなく、どこかで見かけたような・・・ですね。
htpasswdで作成するBASIC認証のファイルですね。

とういうことで、作り方は以下になります。

後に解ったことですが、

  このタイミングでユーザIDを変更するのはなし!!
  監視が出来なくなってしまいます。
  ユーザIDでCGIの起動を制御している部分があるので、ユーザIDの設定変更は別途タイミングを計ってお知らせします。

 > htpasswd -c /etc/nagios/passwd username
   New password:
   Re-type new password:
   Adding password for user username

コマンドを入力すると、パスワードを聞かれますので、指示に従ってパスワードを入力するだけです。

IDとパスワードを忘れても、書き換えてしまえば大丈夫ですね。

nagiosをインストールしてみる。

前回に引き続き、監視システムとしてnagiosをインストールすることにしてみた。

ネットを検索すると、nagiosをインストールについて幾つかの記事が見つかった。

面倒なので、そこのサイト見て・・・というのも何なので、自分で入れてみたらこうなったということで、メモを残そうと思う。

nagiosのインストール方法は、大別すると2つあるようだ。

  • パッケージをダウンロードしてインストールする方法
  • リポジトリを利用指定インストールする方法

パッケージからインストールする方が、最新版の状態でインストール出来るでしょう。
でも、リポジトリからインストールする方が、問題が発生した際の対処が取り易そうな感じがする。

リポジトリからインストールする場合でも、パッケージが一杯ある感じがする。パッケージからインストールすると嵌りそうなので、リポジトリ様を信頼することにした。

ということで、本資料ではリポジトリからnagiosをインストールする方法について記載する。

1.インストール環境

少し古くなってしまった感がありますが、対象とするシステムは以下です。

CentOS 6.7

多分、CentOS 7でも同じだろうと安易な考えは、ご自身でご判断下さい。

クラウド上のチープな環境にインストールします。

2.インストールの前準備

事前に幾つかのパッケージや設定を行ておく必要があるらしい。

入っていると思ったのだが、取りあえず順番に前準備を進める。

GDの開発環境をインストールする。
多分、画像編集機能が必要なのでしょう。

yum install gd-devel

 次に、nagiosは標準のリポジトリに含まれていないので、リポジトリを追加する。インストール対象のリポジトリは、EPELのリポジトリです。

yum install epel-release

 いずれもroot権限で実施する。

EPELのリポジトリは、上記のインストールを行った状態ではデフォルトで使用できる状態になっています。

でも、リポジトリをやたらと増やすのは嫌だったので、少し設定を変更します。

以下のファイルをviで開きます。

/etc/yum.repos.d/epel.repo

[epel]
name=Extra Packages for Enterprise Linux 6 - $basearch
#baseurl=https://download.fedoraproject.org/pub/epel/6/$basearch
mirrorlist=https://mirrors.fedoraproject.org/metalink?repo=epel-6&arch=$basearch
failovermethod=priority
enabled=1               <<< ここを変更 1→0 に変更する。
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-6

これで、明示的に指定しないと、このリポジトリは利用されなくなります。

3.nagiosのインストール

先の設定で準備が整いました。
EPELリポジトリを明示的に指定してインストールを開始します。

 yum --enablerepo=epel install nagios nagios-plugins-ping nagios-plugins-http nagios-plugins-smtp nagios-plugins-dig nagios-plugins-load nagios-plugins-users nagios-plugins-disk nagios-plugins-ssh nagios-plugins-swap nagios-plugins-procs

4.起動

以下のコマンドを実行し、nagiosを起動します。

 service nagios start

ついでに、自動起動を設定します。

 chkconfig nagios on

5.確認

取り敢えず、きちんとnagiosが起動しているか確認することにします。

ブラウザで以下のURLを指定して、nagiosが起動しているかどうかを確認します。

https://hogehoge.ne.jp/nagios/

ユーザIDとパスワードはデフォルトの状態になっているはずです。

ユーザID       :nagiosadmin
パスワード    :nagiosadmin

 

システム監視ツールどうしよう?

今回は、システム監視ツールをインストールしてみようと思っている。

毎度、分野が異なっている様で、散らかした感があるが、取りあえず無視して・・・備忘録だ!と割り切ろう(^^ゞ

さてさて、本題のシステム監視ツールをまずは調べてみた。
有償・無償を探してみると、たくさんありますね(^^;
何がどうなのかよく解らない。

ということで、今回はシステム監視ツールの選定から始めようかと思う。

1.要件整理

今回の要件整理を行う。つまりゴールを決めようと思う。

最終的に実現したい機能的要件を以下に記す。

① プロセスの死活監視
② ファイルの更新監視
③障害発生時等におけるメールでの通知を行う。
④ハードウェアのリソース監視
⑤インシデントの発行・管理

 ①~④は、システム監視ツールで一般に行えるが、⑤は監視とは少しことなり、問題を管理するために必要となる。

つまり、要件整理を行うことで見えてきたのが、大きく分けて2つの分野を実現しようとしているということである。

システムの運用までを考えると、管理が必要となるということですね。

で、それらが出来るツールって???ということで、次の選定で結論を導き出します。

2.選定

1.要件整理で見えてきた「システム監視」と「システム管理」の両方を統括的に運用することは、良いのだろうか?

システムが動作しているかどうかを確認するためのツールは、監視機能で実現するわけだが、運用はユーザとの接点が発生する。

その為、監視ツールで扱う画面が表に出るような設計はあり得ない。

ということは、システム管理は別途実現する方が良くないかな?

今回求めているシステム管理は、プロジェクト管理と類似している。
であれば、プロジェクト管理で既に使っているRedMineを使いこなせばよいではないか?

まず最初の切り分けを行った結果・・・・

システム管理は、別途準備するRedMineで実現する。

連動性を持たせる意味も少ないと思われるので、RedMineについては別途機会があれば説明することにする。

さて、ここまで色々と悩んできたが、システム監視の機能だけを実現するツールを探してみた。

①nagios

②hobbit(Xymon)

③Zabbix

④hinemos

⑤JP1(商用)

⑥Tivoli(商用)

 ざっとこんな感じでしょうか?他にも色々と探せば出てきたのですが、そうじゃなくても悩みます(^^ゞ

比較サイトの様に各ツールを比較している時間的余裕も乏しいので、ほぼ偏見で・・・・

まず、ざっくりと!これだけ監視ツールがあって、使い勝手の違いはあるものの、監視機能としてはどこもそれなりに使えている訳であり、費用を掛ける必要もない!?ということで、JP1とTivoliはこの時点で却下!!

更に、IPA主導でNTTデータに作らせたhinemosですが・・・・プラグイン拡張の拡張性が乏しいことから敬遠されるケースが多い様な雰囲気。

概ねこの手のツールは、日本企業には向かないのでしょうね。
#色々言いたいことはあるものの、ここはぐっと堪えて(^^ゞ

さて、続いて・・・・

②hobbitは、車売るなら~・・・それはラビットや!?
#ちょっと疲れました(^^ゞ
取り敢えず、日本語の情報が少ないっぽいので保留。

③Zabbixは、すごく興味あります。
GUIで設定が楽っぽい。RDBMSを使用していて管理もしっかりしてる感じですね。ポイント高いです。

①nagiosは、テキストベースの設定で面倒な感じ。
でも日本語情報は豊富で、なんでも出来るらしい。

この時点で①nagiosか③Zabbixの二者択一になりました。

で、GUIの設定で楽な感じがするので、③Zabbixにしようかとも思ったのですが、テキストベースで細かな設定が可能というところが、逆にエンジニアライクな好印象。

客先の細かな要望に対応できることや、出力されるデータもテキストベースなのでいざと成ったら加工しようと思えばできるだろう!?ということで、①nagiosを選択しました。

ということで、長々となりましたが、次からはnagiosのインストールをやってみたいと思います。

 

 

全文検索 Fessのクロールで大失態

情けない設定ミスで、クロールが全く動いてくれなかった。

原因は、クロール対象とするパスの設定をミスった。

クロール対象とするパスに

smb://123.123.123.123/hogehoge

と書いて、hogehogeフォルダーを検索対象にした。。。。つもり。

最後に「/」を付けないと、フォルダーとして検索対象にしてくれない。

正しくは、

smb://123.123.123.123/hogehoge/

これだけのミスで・・・情けない。

 

TigerVNCをLinux上で起動して、Windowsから接続する。

TigerVNCのインストール方法については割愛する。

1.環境

環境としては、

・Linux(CentOS 6.5)側にTigerVNCサーバをインストール済み。
・Windows 8.1側にTigerVNCのサーバーとクライアントをインストール済み

以前にインストール方法の記録を書いたと思ったのだが、書いてなかったみたい(^^ゞ。その内、書くことにして今回はインストール後の使用方法のみとする。

2.VNCサーバー側

2.1 起動方法

時折使う、TigerVNCの起動コマンドを以下に備忘録として書き残す。
勝手に起動していると、セキュリティ上気になるので、個人的には必要な時に必要なだけサーバーやクライアントを起動しているので、よく忘れるw

まず、TeraTermなどのターミナル端末を使って、Linux側で以下のコマンドを実行する。
TigerVNCの起動コマンドはこれだです。

> vncserver :1 -geometry 1600×900

:1はnumberとだけなっておりますが、vncserverが起動されている番号になるのでしょう。ある意味で、VNCのIDの様なものとでも覚えておけば良いと勝手に思っています。

 

2.2 その他の確認コマンド

起動方法以外によく使うコマンドは以下の通りです。

1)Help

vncserver –helpでヘルプ見れます。

# vncserver –help

usage: vncserver [:<number>] [-name <desktop-name>] [-depth <depth>]
[-geometry <width>x<height>]
[-pixelformat rgbNNN|bgrNNN]
[-fp <font-path>]
[-fg]
<Xvnc-options>…

vncserver -kill <X-display>

vncserver -list

2)起動リスト
vncserverの起動状況を一覧で確認することが出来ます。

vncserver -list

TigerVNC server sessions:

X DISPLAY # PROCESS ID
:1 10950
:3 27447

上記の場合は、1と3のX DISPLAYが与えられており、:1もしくは:3でvncserverへアクセスすることが可能であることが判ります。

3)VNCサーバーを個別に殺す

そのままkillです。

vncserver -kill :3
Killing Xvnc process ID 27447
Xvnc process ID 27447 already killed

なんか既に殺された後の様なメッセージが帰ってきましたが・・・
listを確認してみると・・・

vncserver -list

TigerVNC server sessions:

X DISPLAY # PROCESS ID
:1 10950

:3が消えているので、無事殺されていることが判りました。

以上でサーバー側の説明は終わりです。

3.クライアント側

クライアント側はWindows 8.1を使用しています。
Vistaや7でも動いているので同じだと思います。

TigerVNC Viewer  でアクセス先を指定して接続しパスワード入力でログイン完了!ちなみに、TightVNC Viewer for Windowsでもほぼ同じです。

xxx.xxx.xxx.xxxには、もちろんIPアドレスもしくはサーバー名を指定。
:1は、vncserver起動時に指定したパラメタと同じ値を指定する。

これでデスクトップ画面が表示されたら成功です。
画面サイズが小さかったり大きかったりする場合は、サーバー起動時の-geometryオプションのサイズを調整して適当なサイズにします。
なので、適当なサイズが見つかるまでに、Killしたり起動したり繰り返しですねw

取りあえず、本当に備忘録です。

以上

Windows環境にPerlをインストールする!(Strawberry Perl)

Windows環境にPerlをインストールする方法について記述します。

Active Perlが有名ですが、フリー版での商用利用はライセンスに抵触するため、個人利用以外の場合はStrawberry Perl がもう一つの選択肢と判断しました。

Strawberry Perlのライセンスは、GPLもしくはArtistic ライセンスになっているので、Active Perlよりは使い勝手が良さそうです。
また、Active Perlにおける以下の問題も気になった次第です。

  • CPANが標準で使用できない。(現在は改善されているみたいですね)
  • Perl本体のバージョンが詳細までは確認できなかった。
    Perl本体最新バージョン:5.20.1
    Active Perl:Perl本体バージョン 5.20
    Strawberry Perl :Perl本体バージョン 5.20.1.1

ということで、Strawberry Perl をインストールします。

Strawberry Perl のダウンロード

下記URLよりダウンロードします。
https://strawberryperl.com/

インストール

ダウンロードしたファイルをダブルクリックしてインストーラーを起動します。
対象ファイル:strawberry-perl-5.20.1.1-64bit.msi

NEXTで次へ

 ライセンス内容を確認したら、I Accept the terms in the License Agreement にチェックを入れて、NEXTで次へ

Linuxでは/usr/bin/perlなのですが・・・Perlのプログラムで記述する最初の一行目にパスを記述するので、変更してみる。

変更したら、NEXTで
<<<追記>>>
変更しても意味有りませんでした。
実際に作成されるperlの実行モジュール(perl.exe)は、下記のパスに作成されています。
c:\usr\bin\perl\bin\perl.exe

無駄な抵抗でしたという落ちですね。
まあ、気分ということでご勘弁ください。

Installを開始する。しばしお待ちを・・・ユーザアカウント制御の画面が出てきたらOKを押して続けてください。

完了すると以下の画面が表示される。

 README.txtがメモ帳などで開いているはずなので、一応一通り目を通して。。。。コマンドプロンプトを起動します。

コマンドプロンプトで以下のコマンドを実行すると、バージョン情報が表示されます。

perl -v

 以上でStrawberry Perl  のインストールと動作確認は完了です。

この後の使い方などについては、いずれまた。

 

Linuxでプロセスの性能測定を行う。

Linux上でプログラムの実行時間を計測する場合、timeコマンドを使用します。

私の場合、CentOS上で動作させることが多いのですが、その際に使用するのがtimeコマンドなのですが、bashに組み込まれているtimeコマンドが勝手に(当然ですが・・・)使われてしまいます。
そんな愚かな私のために、メモを残しておきます。

timeコマンドは、/usr/bin/timeを使用します。
いっそのこと、aliasで切りなおしたろか!?と思うくらいwww

で、使用方法はmanページに任せるとして、詳細な計測結果を以下のオプション付きコマンドで得ることが可能です。

$ /usr/bin/time -v command

-vオプションを指定することで、詳細な計測結果を出力してくれます。

その際、気になるのが以下の項目です。

Maximum resident set size 直訳すると、最大使用実メモリサイズ?となるのでしょうか?
ps auxで得られるメモリ使用量と比較してみても、大きく値に隔たりがあります。
起動時に使用するメモリが大きいのか?そんなはずはない!・・・ということで調べてみることに・・・・

Voluntary context switches この値が影響しているみたいです。
本当かどうかは微妙ですが、コンテキストスイッチが行われると、使用メモリも移動してしまう?そのために、Voluntary context switchesの値を掛けた値がMaximum resident set sizeになっているようだ。

つまり、Maximum resident set sizeをVoluntary context switchesで割った値が実質的な最大使用メモリサイズになる。

<まとめ>

/usr/bin/time -v command

で計測された結果で実行時間の計測が可能。

実質的な使用最大メモリは、

Maximum resident set size / Voluntary context switches

となる。

ps auxやpmapsで確認すると、概ね正しい結果をえられる。

今時のPCで数キロ単位のメモリ消費が異なっていても誤差にしか過ぎないと考えて、この値を採用することにしよう!

これを見て、間違っているようでしたら、どなたかご指摘してください。

セキュリティの関係上、コメント時にはメールアドレスを入力することになっていますが、実のところ、メールアドレスは存在しないメールアドレスでもOKです。
こうしておくと、下手な人がコメントすることもないので・・・・(^^♪