会社の設備を何らかの方法で監視するほとんどのシステム管理者は、インフラストラクチャの状態に関するSMSメッセージを送信するためにのみ使用されることが多いsmstoolsパッケージに精通しています。 コインの裏側は、VPN接続が利用できない場合、またはインターネットアクセスゾーンの外にいる場合、エンタープライズインフラストラクチャをリモートで制御する必要があることです。
前述の管理方法には確かに生命権がありますが、単一のサーバーを管理するように設計されており、コマンドを安全に実行する機能は提供されません。 以下のテキストでは、ローカルネットワーク内でsmsコマンドの実行を安全に確認するための動作メカニズムに注目します。
まず、「なぜこれが必要なのですか?」
「適切に構成されたシステムはメンテナンスが不要」というルールに従って、正しいシステム管理者は安定したオペレーティング機器を再構成せず、更新プログラムのインストールのみに制限します。
しかし、サーバーの作業では、ネットワークボールとRPCの動作を保証するスレッドがハングアップする場合があります(LanManServer(一般ユーザーサーバー内))。ハングアップするのはプロセス自体ではなく、何らかのスレッドです。 その結果、リモートコントロールを介して再起動したり、正しく返済できないサーバーがあります。
この問題で何ができますか?
ほとんどすべての最新サーバーには、IPMIと電源管理が搭載されています。 ここから機能を構築します。 サーバーがnagiosまたは同様のパッケージを介してさらに監視されている場合、ほとんどの場合、nrpe-
Nagios Remote Plugin Executorを使用します。これは、システムサービスに依存しないサーバー管理メカニズムがあることを意味します。 再起動、シャットダウン、stop_server、start_serverなどのNSClient ++設定で頻繁に使用されるコマンドを指定し、サーバーで必要なアクションをリモートで実行するだけで十分です。
古いクライアント設定では、外部スクリプトの呼び出しは、新しい
[[/ settings / external scripts / scripts] "の
[[External Scripts] "セクションにあり
ます 。 テキストはどちらの場合も同じです。
reboot=scripts\s_reboot.cmd shutdown=scripts\s_shutdown.cmd stop_server=scripts\stop_server.cmd start_server=scripts\start_server.cmd
スクリプティング
s_reboot.cmd @echo "Reboot initiated" @start cmd /c shutdown -r -f -t 00 @exit 0
s_shutdown.cmd @echo "Shutdown initiated" @start cmd /c shutdown -s -f -t 00 @exit 0
start_server.cmd @start cmd /c net start server @if %ERRORLEVEL% EQU 0 goto ok @echo Some problem with service start @exit 1 :ok @echo Service started @exit 0
stop_server.cmd @start cmd /c net stop server /y @if %ERRORLEVEL% EQU 0 goto ok @echo Some problem with service stop @exit 1 :ok @echo Service stopped @exit 0
これは、リモートで使用できるコマンドの基本リストです。 同様のスクリプトに引数を渡すことにより、サービスを停止または発生させることができます。 たとえば、IISを歪めます。
通常、チームの呼び出しは簡単で、次のようになります。
/usr/local/libexec/nagios/check_nrpe2 -H <HOST> -c <command> -a <arguments>
これはnrpeで整理されているようで、IPMIを提供する必要があります。
IPMIサーバーシステムとの対話には、
ipmitoolパッケージを使用できます。これは、コマンドラインからipmi管理にアクセスするためのインターフェイスです。
必要なコマンドの主なセットは、「power」セクションに関連しています。つまり、
ipmitool -H <host> -U <username> -P <password> power status - ipmitool -H <host> -U <username> -P <password> power up - ipmitool -H <host> -U <username> -P <password> power off - ipmitool -H <host> -U <username> -P <password> power reset - reset
温度センサー、ファンの速度は引き続き読み取ることができますが、実際には必要ありません。
チームのメインセットを整理しました。
管理セキュリティを確保する方法は?
最近、SMS送信者番号の偽造を許可する多くのサービスが登場したという事実により、送信者番号の通常の検証は十分に信頼できなくなりました。
メッセージで直接パスワードを転送することも信頼性の低いことです。 メッセージの傍受により、制御システムへのフルアクセスが可能になります。 どうする?
解決策は驚くほど簡単です。 OTP(ワンタイムパスワード)。 使いやすさと、生成されたパスワードの時間依存性がないという観点から、最適な解決策は
OPIEを使用することです。
OPIEを選ぶ理由
複数のシステム管理者またはサーバーサービスエンジニアがいる場合、全員にパスワードと初期初期化ベクトルを与えることは完全には正しくありません。 サーバーのメンテナンスのために、さまざまなブロックのパスワードのリストを全員に提供することが適切です。
また、パスワードブロックを使用する場合は、サーバーの電源を切った、または再起動した人の手で正確に確認できます。 「1人の」システムを使用するという観点から、Androidの携帯電話では、オンラインパスワード生成のために
OTPDroidパッケージをインストールする方が適切です。 生成されたパスワードの値がすぐにクリップボードにコピーされ、3回クリックするだけでパスワードをsmsでコピーできるという点で素晴らしいです。
「同じパスワードの二重使用はどうですか?」と尋ねます。
答えは簡単です:「SMSで到着した使用済みシーケンスのリストを制御し、維持するだけです」
これをすべて一緒に機能させるには
smsd構成ファイルの最初のステップは、イベントハンドラー呼び出しを追加することです。
eventhandler = /usr/local/etc/smshandlers/smsevent
処理プログラムは、通常のシェルスクリプトです。
次に、多くのシェルコードsmseventを実行します smseventハンドラファイルに関するいくつかのコメント
ファイルの先頭には、構成ファイル、検証および管理プログラムを見つけるための基本変数、およびパスワード検証のためのOPIEパラメーターが設定されています。
設定ファイルでは、電話機とそれらに使用できるコマンドのリスト、サーバーアドレスのリスト、さまざまなホストのIPMIログインとパスワード、およびコマンドを実行するためのテンプレートを指定します。
コマンドテンプレートブロックでは、2番目の引数は0または1であり、コマンドのOPIEチェックをスキップするか、OPIEをチェックします。
最も簡単なSMS要求は、ホストの可用性を確認した結果とともに2つのSMSを交互に返送します。
ALIVE 192.168.54.2 192.168.54.5
フォームのリクエストは、リセットボタンをエミュレートすることにより、ホスト192.168.55.2を再起動し、ホスト192.168.54.5は正常にシャットダウンします:
OPIE 1 COT NORM TILL JILL MOST MESH RESET 192.168.55.2 SHUTDOWN 192.168.54.5
smsを介して実行されるすべてのアクションは、拡張smsdログに書き込まれます。
一般に、それですべてです。 自分で設定を編集し、コマンドを受信するようにサーバーを設定すると、電話で休暇を取ることができます。 突然何かがハングした場合、SMSを介した直接射撃がトリックを行います。
PS:スクリプトは少し湿っていますが、彼らが言うように、「完璧に制限はありません!」。