Redmineのチケット一覧画面なのだが、デフォルトだと親子関係のあるチケットの関係がわかりやすく表示されているとは言えない状態になっている。

できればツリー状に出力させたいと思い調べたところ、やはりそういったプラグインがあるようだ。
『Redmine Issues Tree』というプラグインを見つけた。

というわけで、早速入れてみよう。
なお、gitのブランチはRedmineのバージョンによって異なるので、自身のRedmineのバージョンにあったものを選択すること。

cd /var/www/redmine/plugins/
git clone -b 3.2.x https://github.com/Loriowar/redmine_issues_tree.git
bundle install
rake redmine:plugins:migrate RAILS_ENV=production
chown www-data. -R /var/www/redmine
service apache2 restart

これで、プラグインのインストールが行われたはずだ。

プロジェクトのチケットページに行くと、右上に「Tree View」というボタンがあるので、ツリー表示させる場合はそれをクリックする。

無事、ツリー表示ができた。
タイトル横の▽のトコをクリックすることで、子チケットを表示・非表示にすることができる。

とりあえず、これでだいぶ見やすくなった。

Redmine実践ガイド 理論と実践、事例で学ぶ新しいプロジェクトマネジメント

時折、Slackにコマンドから通知を出したいことがある。
面倒だし、標準出力から渡せたらなぁ…と思って調べたところ、まさにそれを行える『slackcat』というコマンドがあるようだ。
これは使えそうということで、早速試してみる。

1.インストール

インストールはかなり簡単なようで、以下のコマンドで実行できる。

●Linuxの場合

wget https://github.com/vektorlab/slackcat/releases/download/v1.1/slackcat-1.1-linux-amd64 -O slackcat
sudo mv slackcat /usr/local/bin/
sudo chmod +x /usr/local/bin/slackcat

●Mac OS Xの場合

brew install slackcat

2.設定

次に、通知するSlackの設定を行う。
以下のコマンドを実行し、URLを表示させる。

slackcat --configure

blacknon@BS-PUB-UBUNTU-01:~$ slackcat --configure
slackcat Creating token request for Slackcat
slackcat Use the below URL to authorize slackcat if browser fails to launch
slackcat http://slackcat.chat/configure

出力されたURLにアクセスすると、ブラウザからSlackとslackcatを連携するかどうか聞かれる。
許可をすると、以下のような画面が表示されるので、出力されているコマンドを実行してやる。

これで設定は終わり。

3.コマンドを実行する

さて、それでは実際にコマンドを実行してみよう。

コマンド | slackcat --channel チャンネル名
コマンド | slackcat --tee --channel チャンネル名 # コンソール上にも表示させる場合

blacknon@BS-PUB-UBUNTU-01:~$ echo ABC | slackcat --channel general
slackcat connected to blacknon as blacknon
slackcat file 1475194489 uploaded to general (0.395s)
blacknon@BS-PUB-UBUNTU-01:~$ echo AAA | slackcat --tee --channel general
slackcat connected to blacknon as blacknon
AAA
slackcat file 1475194500 uploaded to general (0.335s)

で、Slackの画面がこちら。

確かに、標準出力で渡した内容がSlack側に通知されている。
手軽だし、設定も簡単なので良さそう。

ただ、サーバ側でcronで回すと行った使い方なら、ちゃんとWebHookを使ったスクリプト書いたほうが良いだろう。

はじめてみようSlack 使いこなすための31のヒント

先日、Twitterで『Windowsで更新日が◯日前のファイルを削除する方法』について見かけたので、そういえばどのくらいあるんだろう？と思って調べてみた。
もともとPowerShellではできるであろうとは認識してたので、他にもお手軽な方法があるのかなと。

1.PowerShellの場合

まぁ、PowerShellでやる方法についてはMicroSoftでも公式で例を出してるので…。
PowerShellの2と3で、以下のようなやり方があるようだ。

●PowerShell2

Get-ChildItem パス名 –Recurse | Where-Object{$_.CreationTime –lt (Get-Date).AddDays(-日数)} | Remove-Item

●PowerShell3

Get-ChildItem パス名 –Recurse | Where-Object CreationTime –lt (Get-Date).AddDays(-日数) | Remove-Item

まぁ、PowerShell2の書き方であれば大体の環境で動作するので、そちらを使うと良いだろう。

2.cmd(コマンドプロンプト)の場合

cmd(コマンドプロンプト)で古いファイルを削除する場合、以下のようにする。
1行目のコマンドで対象のファイルを抽出、2行目で削除している。

forfiles -p パス名 -s -m *.* -d -日数 -c "cmd /c echo @path"
forfiles -p パス名 -s -m *.* -d -日数 -c "cmd /c del @path"

3.Explorerからファイルを検索して削除する場合

最後に、PowerShellもコマンドプロンプトもちょっと…全部GUIからやりたいという人の場合は、Explorerから対象のファイルを検索して削除すればいいだろう。
Explorerで削除を行う対象のパスに移動して、右上の検索バーに以下のように入力してやれば良い。

< 日付
もしくは
datemodified < 日付

これで、その日付よりも前のファイルだけを抽出できるので、あとはすべて選択して削除すればよい。

まぁ、普通に定期的に実行するならPowerShellかbatchでスクリプト作ってタスクマネージャで定期実行させるのをおすすめするけど…
世の中、誰もがスクリプト書けたりするわけでも無いので、お好みで。

Windowsネットワーク上級リファレンス Windows 10／8.1／7完全対応

Redmineで、雑多なノウハウやらをタグ付けやカテゴリ分けして管理する方法(ナレッジベースとして使うような)が無いかと調べていたところ、そのものズバリでそういった用途のためのプラグインとして『knowledgebase』というものがあるようだ。
Redmine 2系の頃はRedmine全体でのナレッジベースとして動いたようだが、3系になってからはプロジェクトごとに分けて動作するらしい。全体用のナレッジを格納する場合は、それ用のプロジェクトを別途作れとのこと。

Redmineのプラグインなので、インストールは簡単。
以下のようにコマンドを実行するだけだ。

cd /var/www/redmine/plugins
git clone git://github.com/alexbevi/redmine_knowledgebase.git
chown www-data. -R ./
bundle install
rake redmine:plugins:migrate RAILS_ENV=production

あとは、Webサーバのプロセスを再起動し、対象のプロジェクトでモジュールを有効にするだけだ。

これでプラグインのインストールができた。
あとはカテゴリを作り、その下に各ナレッジを入力してってやればよい。タグ付けもできるので、手順書などを格納するなら有用だろう。

Redmine超入門 増補改訂版 (日経BPムック)

ドキュメントの管理について、通常のファイルサーバだと管理が煩雑になったり間違えて上書きする人も出てきたりして、色々と面倒なことがある。
履歴管理についてはこちらにあるような方法を取ればなんとか行えるけど、端末がWindows以外だとシンボリックリンクを別途用意したり、面倒が多い。

で、ドキュメント管理システムとしてわざわざサーバを新たに作るのも面倒(権限管理とか)だったりなのだが、Redmineにあるドキュメント管理のプラグイン「DMSF」を使えば、そのあたりを大体クリアできる。プロジェクトごとに管理されるので、権限管理はそこに依存させればいいし。
Redmineのバージョンは最新版での確認をしているようで、2016年10月現在は3.3以降しか対応していないようだ。今回は3.2なので、バージョンを指定してインストールする。

インストールもRedmineプラグインだから簡単。以下のコマンドを実行する。

cd /var/www/redmine/plugins
git clone -b v1.5.6 https://github.com/danmunn/redmine_dmsf
bundle install
rake redmine:plugins:migrate RAILS_ENV=production
chown www-data. -R ../

あとは、Webサーバのプロセスを再起動すればプラグインのインストールが適用される。
プロジェクトで有効にしてやれば、あとはフォルダやファイルのアップロードをするだけだ。

チーム開発実践入門 ~共同作業を円滑に行うツール・メソッド (WEB+DB PRESS plus)

個人的に仮想基盤のソフトでDebianベースのProxmox VEと言うものを使っているのだが、Vulsでこれの脆弱性について検出できるかどうかやってみる事にする。
基本はDebianベースだからいけると思うのだけど…ちょっと微妙な結果になった。

1.ユーザ作成・鍵ファイルの設定

まず、Proxmox側にssh接続してvulsユーザの作成をする。

useradd vuls -b /opt -s /bin/bash
mkdir /opt/vuls
chown vuls. /opt/vuls
passwd vuls

次に、Vulsサーバからssh接続する際の鍵ファイルを登録、コンフィグへの追加をする。

ssh-copy-id vuls@Proxmox
cat <<EOF >> config.toml

[servers.Proxmox]
host = "IPアドレス"
port = "22"
user = "vuls"
keyPath = "/opt/vuls/.ssh/id_rsa"
EOF

ただ、この時点でコンフィグ確認を行っても、sudoとかのコマンドが入ってないのでエラーになる。

[vuls@BS-PUB-SEC ~]$ vuls configtest
[Oct  1 20:09:17]  INFO [localhost] Validating Config...
[Oct  1 20:09:17]  INFO [localhost] Detecting Server/Contianer OS...
[Oct  1 20:09:17]  INFO [localhost] Detecting OS of servers...
[Oct  1 20:09:17]  INFO [localhost] (1/2) Detected: Proxmox: debian 8.4
[Oct  1 20:09:17]  INFO [localhost] (2/2) Detected: BS-PUB-SEC: centos 7.2.1511
[Oct  1 20:09:17]  INFO [localhost] Detecting OS of containers...
[Oct  1 20:09:17]  INFO [localhost] Checking sudo configuration...
[Oct  1 20:09:17] ERROR [Proxmox] sudo error on SSHResult: servername: Proxmox, cmd: set -o pipefail; sudo -S apt-get -v, exitstatus: 127, stdout: bash: sudo: command not found
, stderr: , err: %!s()
[Oct  1 20:09:18]  INFO [BS-PUB-SEC] sudo ... OK
[Oct  1 20:09:18] ERROR [localhost] Failed to sudo with nopassword via SSH. Define NOPASSWD in /etc/sudoers on target servers. err: [vuls@172.28.0.30:22: Failed to sudo: SSHResult: servername: Proxmox, cmd: set -o pipefail; sudo -S apt-get -v, exitstatus: 127, stdout: bash: sudo: command not found
, stderr: , err: %!!(MISSING)s()]

2.Proxmox側でapt-get・sudoersの設定

次に、Proxmox側でapt-getが行えるようにし、sudoなどの必要パッケージのインストールを実行する。
まず、Proxmoxにrootユーザでログインして、以下のコマンドを実行しapt-getが利用できるようにする。

echo "# PVE pve-no-subscription repository provided by proxmox.com, NOT recommended for production use" >> /etc/apt/sources.list
echo "deb http://download.proxmox.com/debian jessie pve-no-subscription" >> /etc/apt/sources.list
sed -i '/^deb/s/^/# /' /etc/apt/sources.list.d/pve-enterprise.list

で、sudoなどの必要パッケージをインストールする。

apt-get install sudo

sudoのインストール後、以下のコマンドでsudoersにvulsユーザを追加する。

sed -i.bk '/^root/avuls ALL=(root) NOPASSWD: /usr/bin/apt-get, /usr/bin/apt-cache' /etc/sudoers

この状態でconfigtest、prepareをすれば通るはずだ。

[vuls@BS-PUB-SEC ~]$ vuls configtest
[Oct  1 20:16:10]  INFO [localhost] Validating Config...
[Oct  1 20:16:10]  INFO [localhost] Detecting Server/Contianer OS...
[Oct  1 20:16:10]  INFO [localhost] Detecting OS of servers...
[Oct  1 20:16:10]  INFO [localhost] (1/2) Detected: Proxmox: debian 8.4
[Oct  1 20:16:11]  INFO [localhost] (2/2) Detected: BS-PUB-SEC: centos 7.2.1511
[Oct  1 20:16:11]  INFO [localhost] Detecting OS of containers...
[Oct  1 20:16:11]  INFO [localhost] Checking sudo configuration...
[Oct  1 20:16:11]  INFO [Proxmox] sudo ... OK
[Oct  1 20:16:11]  INFO [BS-PUB-SEC] sudo ... OK
[Oct  1 20:16:11]  INFO [localhost] SSH-able servers are below...
Proxmox BS-PUB-SEC
[vuls@BS-PUB-SEC ~]$ vuls prepare
INFO[0000] Start Preparing (config: /opt/vuls/config.toml)
[Oct  1 20:16:57]  INFO [localhost] Detecting OS...
[Oct  1 20:16:57]  INFO [localhost] Detecting OS of servers...
[Oct  1 20:16:57]  INFO [localhost] (1/2) Detected: Proxmox: debian 8.4
[Oct  1 20:16:57]  INFO [localhost] (2/2) Detected: BS-PUB-SEC: centos 7.2.1511
[Oct  1 20:16:57]  INFO [localhost] Detecting OS of containers...
[Oct  1 20:16:57]  INFO [localhost] Checking sudo configuration...
[Oct  1 20:16:58]  INFO [Proxmox] sudo ... OK
[Oct  1 20:16:58]  INFO [BS-PUB-SEC] sudo ... OK
[Oct  1 20:16:58]  INFO [localhost] Installing...
[Oct  1 20:16:58]  INFO [Proxmox] apt-get update...
[Oct  1 20:16:58]  INFO [BS-PUB-SEC] Ignored: yum-plugin-changelog already installed
[Oct  1 20:17:07]  INFO [Proxmox] Installed: aptitude

3.スキャンを行う

さて、この状態になればあとはスキャンを行うだけだ。

vuls scan -debug -cve-dictionary-dbpath=/opt/vuls/cve.sqlite3 -results-dir=/opt/vuls/results/ -report-text -lang=ja -report-json

で、幾つか(結構多く)のパッケージについてはProxmox独自のものが使われているためエラーになってしまう。
どうやらchangelogからCVE番号が見れないようだ…

で、一応Debianのパッケージについては確認できる、ようなのだけど…

どうも通知系でうまく動かないっぽい。
一応、tuiでは見れるんだけど…

Virtualization Complete: Business PLUS Edition: (Proxmox-freeNAS-Zentyal-pfSense-Artica) (English Edition)

ジョブスケジューラーを導入しようと色々調べていたところ、ワークフローとかが使えるPython製のジョブスケジューラー『Dagobah』というものを見かけたので、ちょっと触ってみる事にする。
なお、インストール先としてはCentOS 7を用いる。

1.インストール

『Dagobah』はpip経由でインストールできるようなので、以下のコマンドでインストールする。

yum -y install python-pip gcc libxml2-devel libxslt-devel python-devel
pip install dagobah
pip install pymongo

これでインストールが完了。
簡単だ。

2.『Dagobah』のサービス起動

次に、インストールした『Dagobah』のサービスを起動する。
とりあえず、まず設定ファイルを作成する。

mkdir -p ~/dagobah/daemon/
cd ~/dagobah/daemon/
wget https://raw.githubusercontent.com/thieman/dagobah/master/dagobah/daemon/dagobahd.yml
sed -i 's/127.0.0.1/0.0.0.0/g' dagobahd.yml
cd

ホームディレクトリに移動後、以下のコマンドを実行するとサービスが起動する。

dagobah

[root@BS-PUB-CENT7-01 ~]# dagobahd
Creating new config file in home directory
Defaulting missing config key Logging.enabled to False
WARNING:root:Defaulting missing config key Logging.enabled to False
WARNING:root:Email.auth_required is True but Email.user is None. Emailing of reports will be disabled.
WARNING:root:SSH config doesn't exist, no remote hosts will be listed
Starting app on 127.0.0.1:9000

以後は、~/.dagobahd.ymlというファイルが設定ファイルになる。

3.ブラウザからアクセスする

とりあえず、ブラウザからアクセスしてみよう。初期パスワードは「dagobah」になる。

ログイン直後の画面。
新しいジョブを作れとの事。

適当に「test」というジョブを作ってみた。

ページ下にある「Add New Task」から適当にタスクを作ってつなげて見たところ。
マウスで普通につなげる事ができる。

最初のタスクを意図的に失敗するようにした結果。
2個めのタスクが実行されていない事がわかる。

確かに、マウスでワークフローをいじってジョブを処理させることができるようだ。
結構お手軽かつわかりやすい感じ。

4.リモートサーバに対してタスクを実行させる

さて、今時点ではリモートサーバの設定をしてないので、ローカルサーバに対するタスクしか実行できていない。
じゃあ、リモートサーバに対しタスクを実行するにはどんな設定をすればいいのか。

どうやら、「.ssh/config」に接続先の情報を記述することでリモートサーバとして指定できるようになるみたいだ。
とりあえず、以下のようにファイルを作成する。

Host サーバ名
     HostName ホスト名orIPアドレス
     User ユーザ名
     IdentityFile ~/.ssh/id_rsa(鍵ファイルPATH)

ファイル作成後、サーバの再起動をしなくてもリモート先の選択肢に出てくるようになる。

各タスクの返り値に応じて処理を分岐させたり、返り値を次のタスクに渡すような処理はできないみたいだけど、単純なジョブならこれで設定できそう。
小規模、かつ単純なタスクのみをジョブにするなら結構ありかも。トリガーとかが必要になる環境では使えないかな。。。

新しいLinuxの教科書

会社でログ管理にGraylogを使っているのだが、一部に存在しているJSON形式のログを取り込めないか調べたところGraylogにはその機能が標準で組み込まれていることを知った。
例えば、Collector Sidecarでファイルを指定してログ回収した結果、以下のようなログが来ていたとする。

これを、jsonの項目名ごとに分割してやるには、まず対象のログのMessageID(上の画像だと「22ddcf00-8b5d-11e6-b270-623530633165」となっているログのID)とIndex番号(上の画像では「graylog_0」)を控えておき、[System] > [Input]に移動する。

移動後、対象のログが利用しているInputの[Manage extractors]をクリックする。

JSON形式の読み込みの仕方について設定する画面に遷移する。
基本的にはデフォルトのまま進めても問題ない箇所なので、そのまま[Extractor title]だけ入れて[Create extractor]で作成するとよいだろう。設定した結果は[try]ボタンを押下することで見れる。

設定後は、以下のようにログ受信後はJSONを分解して項目ごとに値を取り出せるようになる。

アプリケーションによってはJSON形式でログを出すこともあるので、これは結構便利かも。

サーバ／インフラエンジニア養成読本 ログ収集〜可視化編 [現場主導のデータ分析環境を構築！] Software Design plus

Graylogを社員に開放して、ある程度メンバーの権限で見れるようにするためにActive Directory連携をしたのでその設定の備忘。
設定は簡単で、上部メニューから[System] > [Authentication]を選択し、「3.LDAP/Active Directory」をクリックする。

あとは、LDAP/ActiveDirectoryの設定について各項目の入力をしていけばいい。

基本的には、ふつうに構築したActive Directoryであれば以下の画面のように設定してやれば接続できるようになるだろう。

Active Directoryとの接続テスト、ADユーザのログインテストで問題がなければ[SAVE]で設定完了。
あとはADユーザでそのままログインすればよい。最初に割り当てられる権限は一番下の権限なので、ユーザに応じてロールを設定してやればよいだろう。

Active Directory最強の指南書(日経BPムック) (日経ITエンジニアスクール)

別件の調べものをしてたところ、コンソールで利用できるネットワークモニタリングツール『Mylg』というものを見かけたので、少し触ってみることにした(Githubはこちら)。
とりあえず、イメージをつかむなら公式サイトの動画を見るとよさそう。で、見る限り結構便利そうな印象だ。専用コンソールに入って操作するようだけど、かなり扱いやすそうな感じ。

見ててなんとなく予想がついたかもしれないが、Golangで記述されたツールのようだ。
一応、Mac用のパッケージもCentOSなど用のrpmファイルも提供されているようなのだが、今回はUbuntu Server 16.04 LTSにこのツールをインストールして使ってみる。

1.インストール

まず、以下のコマンドでインストールする。

sudo apt-get install libpcap-dev golang
curl -O http://mylg.io/dl/linux/mylg.amd64.deb && sudo dpkg -i mylg.amd64.deb

これでインストールが完了した。

2.使ってみる

インストールが完了したので、さっそく使ってみよう。
ユーザガイドを見る限り、結構機能があるようなのでいくつか抜粋して使ってみる。

基本的には、まず以下のコマンドでmylgのコンソールに入り、その中でコマンドを実行していく使い方になるようだ。

mylg

2-1.tracerouteをしてみる

コマンド「trace」を実行することで、対象のホストへのtracerouteを行うことができる。

local> trace orebibou.com
trace route to orebibou.com (157.112.152.17), 30 hops max
Get https://stat.ripe.net/data/prefix-overview/data.json?max_related=50&resource=172.28.0.1: net/http: TLS handshake timeout
1  XXX.XXX.XXX.1 0.664 ms 0.801 ms 0.784 ms
2  XXX.XXX.XXX.1 1.077 ms 1.026 ms 1.019 ms
3  r641.tokynt01.ap.so-net.ne.jp. (202.223.117.182) [ASN 2527/SO-NET] 5.503 ms 5.576 ms 6.062 ms
4  maru-02Gi2-9.net.so-net.ne.jp. (202.223.117.181) [ASN 2527/SO-NET] 4.690 ms 4.601 ms 5.344 ms
5  ote-gw7Ae7.net.so-net.ne.jp. (202.213.193.33) [ASN 2527/SO-NET] 5.199 ms 4.791 ms 5.692 ms
6  202.213.193.35 [ASN 2527/SO-NET] 11.180 ms 12.899 ms 13.514 ms
7  tkort2-as2527-10g.bb.sakura.ad.jp. (157.17.131.17) 13.757 ms 15.680 ms 16.418 ms
8  tkwrt1s-ort2.bb.sakura.ad.jp. (157.17.130.26) 8.959 ms 13.193 ms 12.924 ms
9  tkwrt3-wrt1s.bb.sakura.ad.jp. (59.106.247.118) 13.231 ms 9.872 ms 8.734 ms
10 157.17.131.246 16.936 ms 20.237 ms 16.301 ms
11 osnrt1s-nrt3-2.bb.sakura.ad.jp. (157.17.146.162) 14.881 ms 16.747 ms 18.039 ms
12 osnrt1b-nrt1s.bb.sakura.ad.jp. (157.17.146.138) 14.099 ms 17.479 ms 21.093 ms
13 osnrt3c-nrt1b.bb.sakura.ad.jp. (157.17.147.2) 26.285 ms 23.220 ms 20.478 ms
14 210.188.211.188 [ASN 9371/SAKURA-C] 13.934 ms 14.521 ms 13.187 ms
15 sv916.xserver.jp. (157.112.152.17) [ASN 9371/SAKURA-C] 12.231 ms 12.665 ms 12.197 ms

このとき、「-r」オプションを付与することでリアルタイムでの監視ができるようだ。
「1」「2」キーで表示を切り替えることができる。

2-2.パケットキャプチャをしてみる

コマンド「dump」でパケットキャプチャを行える。
オプションはtcpdumpに似ているので、tcpdumpの使い方がわかってればすぐに使いこなせそうだ。

地味に便利な機能として、「-s」オプションで指定したキーワードを含むパケットのみを抽出できる。
以下は、「orebibou」というキーワードを持つパケットのみ監視した結果。

local> dump -i eth0 -x -s orebibou
Interface: eth0, capture size: 6144 bytes
21:43:39.396 IPv4/TCP BS-PUB-UBUNTU-01.BLACKNON.LOCAL.:47768 > sv916.xserver.jp.:80(http) [P.], win 229, len: 76
00000000 47 45 54 20 2f 20 48 54 54 50 2f 31 2e 31 0d 0a |GET / HTTP/1.1..|
00000010 48 6f 73 74 3a 20 6f 72 65 62 69 62 6f 75 2e 63 |Host: orebibou.c|
00000020 6f 6d 0d 0a 55 73 65 72 2d 41 67 65 6e 74 3a 20 |om..User-Agent: |
00000030 63 75 72 6c 2f 37 2e 34 37 2e 30 0d 0a 41 63 63 |curl/7.47.0..Acc|
00000040 65 70 74 3a 20 2a 2f 2a 0d 0a 0d 0a             |ept: */*....    |

21:43:39.422 IPv4/TCP sv916.xserver.jp.:80(http) > BS-PUB-UBUNTU-01.BLACKNON.LOCAL.:47768 [P.], win 46, len: 504
00000000 48 54 54 50 2f 31 2e 31 20 33 30 31 20 4d 6f 76 |HTTP/1.1 301 Mov|
00000010 65 64 20 50 65 72 6d 61 6e 65 6e 74 6c 79 0d 0a |ed Permanently..|
00000020 44 61 74 65 3a 20 57 65 64 2c 20 31 32 20 4f 63 |Date: Wed, 12 Oc|
00000030 74 20 32 30 31 36 20 31 32 3a 34 33 3a 33 39 20 |t 2016 12:43:39 |
00000040 47 4d 54 0d 0a 53 65 72 76 65 72 3a 20 41 70 61 |GMT..Server: Apa|
00000050 63 68 65 0d 0a 4c 6f 63 61 74 69 6f 6e 3a 20 68 |che..Location: h|
00000060 74 74 70 73 3a 2f 2f 6f 72 65 62 69 62 6f 75 2e |ttps://orebibou.|
00000070 63 6f 6d 2f 0d 0a 43 61 63 68 65 2d 43 6f 6e 74 |com/..Cache-Cont|
00000080 72 6f 6c 3a 20 6d 61 78 2d 61 67 65 3d 31 0d 0a |rol: max-age=1..|
00000090 45 78 70 69 72 65 73 3a 20 57 65 64 2c 20 31 32 |Expires: Wed, 12|
000000a0 20 4f 63 74 20 32 30 31 36 20 31 32 3a 34 33 3a | Oct 2016 12:43:|
000000b0 34 30 20 47 4d 54 0d 0a 56 61 72 79 3a 20 41 63 |40 GMT..Vary: Ac|
000000c0 63 65 70 74 2d 45 6e 63 6f 64 69 6e 67 0d 0a 43 |cept-Encoding..C|
000000d0 6f 6e 74 65 6e 74 2d 4c 65 6e 67 74 68 3a 20 32 |ontent-Length: 2|
000000e0 32 39 0d 0a 43 6f 6e 74 65 6e 74 2d 54 79 70 65 |29..Content-Type|
000000f0 3a 20 74 65 78 74 2f 68 74 6d 6c 3b 20 63 68 61 |: text/html; cha|
00000100 72 73 65 74 3d 69 73 6f 2d 38 38 35 39 2d 31 0d |rset=iso-8859-1.|
00000110 0a 0d 0a 3c 21 44 4f 43 54 59 50 45 20 48 54 4d |...<!DOCTYPE HTM|
00000120 4c 20 50 55 42 4c 49 43 20 22 2d 2f 2f 49 45 54 |L PUBLIC "-//IET|
00000130 46 2f 2f 44 54 44 20 48 54 4d 4c 20 32 2e 30 2f |F//DTD HTML 2.0/|
00000140 2f 45 4e 22 3e 0a 3c 68 74 6d 6c 3e 3c 68 65 61 |/EN">.<html><hea|
00000150 64 3e 0a 3c 74 69 74 6c 65 3e 33 30 31 20 4d 6f |d>.<title>301 Mo|
00000160 76 65 64 20 50 65 72 6d 61 6e 65 6e 74 6c 79 3c |ved Permanently<|
00000170 2f 74 69 74 6c 65 3e 0a 3c 2f 68 65 61 64 3e 3c |/title>.</head><|
00000180 62 6f 64 79 3e 0a 3c 68 31 3e 4d 6f 76 65 64 20 |body>.<h1>Moved |
00000190 50 65 72 6d 61 6e 65 6e 74 6c 79 3c 2f 68 31 3e |Permanently</h1>|
000001a0 0a 3c 70 3e 54 68 65 20 64 6f 63 75 6d 65 6e 74 |.<p>The document|
000001b0 20 68 61 73 20 6d 6f 76 65 64 20 3c 61 20 68 72 | has moved <a hr|
000001c0 65 66 3d 22 68 74 74 70 73 3a 2f 2f 6f 72 65 62 |ef="https://oreb|
000001d0 69 62 6f 75 2e 63 6f 6d 2f 22 3e 68 65 72 65 3c |ibou.com/">here<|
000001e0 2f 61 3e 2e 3c 2f 70 3e 0a 3c 2f 62 6f 64 79 3e |/a>.</p>.</body>|
000001f0 3c 2f 68 74 6d 6c 3e 0a                         |</html>.|

このキーワードサーチだけでもかなり便利な気がする。

2-3.dig+traceをしてみる

digを行い、名前解決について確認する。
NSやMXレコードなど、デフォルトで一発出力してくれるらしい。

local> dig orebibou.com
Trying to query server: 172.28.0.1  your local dns server
;; opcode: QUERY, status: NOERROR, id: 41176
;; flags: qr rd ra;
orebibou.com.   21599   IN      NS      ns2.xserver.jp.
orebibou.com.   21599   IN      NS      ns1.xserver.jp.
orebibou.com.   21599   IN      SOA     ns1.xserver.jp. root.sv0.xserver.jp. 0 10800 3600 604800 3600
orebibou.com.   21599   IN      NS      ns3.xserver.jp.
orebibou.com.   21599   IN      A       157.112.152.17
orebibou.com.   21599   IN      NS      ns4.xserver.jp.
orebibou.com.   21599   IN      NS      ns5.xserver.jp.
orebibou.com.   21599   IN      MX      0 orebibou.com.
;; Query time: 112 ms

;; CHAOS CLASS BIND
version.bind.   0       CH      TXT     "dnsmasq-2.55"

ただ、それよりも注目したいのが「+trace」サブオプション。
どうも名前解決をtraceしてくれてるようだ。状況によっては地味に便利そうな機能だ。

local> dig orebibou.com +trace
.       6439    IN      NS      d.root-servers.net.
.       6439    IN      NS      m.root-servers.net.
.       6439    IN      NS      b.root-servers.net.
.       6439    IN      NS      e.root-servers.net.
.       6439    IN      NS      a.root-servers.net.
.       6439    IN      NS      f.root-servers.net.
.       6439    IN      NS      h.root-servers.net.
.       6439    IN      NS      j.root-servers.net.
.       6439    IN      NS      k.root-servers.net.
.       6439    IN      NS      g.root-servers.net.
.       6439    IN      NS      l.root-servers.net.
.       6439    IN      NS      c.root-servers.net.
.       6439    IN      NS      i.root-servers.net.
from: XXX.XXX.XXX.1#53 in 5 ms
com.    172800  IN      NS      a.gtld-servers.net.
com.    172800  IN      NS      j.gtld-servers.net.
com.    172800  IN      NS      g.gtld-servers.net.
com.    172800  IN      NS      k.gtld-servers.net.
com.    172800  IN      NS      f.gtld-servers.net.
com.    172800  IN      NS      c.gtld-servers.net.
com.    172800  IN      NS      i.gtld-servers.net.
com.    172800  IN      NS      d.gtld-servers.net.
com.    172800  IN      NS      l.gtld-servers.net.
com.    172800  IN      NS      m.gtld-servers.net.
com.    172800  IN      NS      e.gtld-servers.net.
com.    172800  IN      NS      b.gtld-servers.net.
com.    172800  IN      NS      h.gtld-servers.net.
from: d.root-servers.net.#53 in 85 ms
orebibou.com.   172800  IN      NS      ns1.xserver.jp.
orebibou.com.   172800  IN      NS      ns2.xserver.jp.
orebibou.com.   172800  IN      NS      ns3.xserver.jp.
orebibou.com.   172800  IN      NS      ns4.xserver.jp.
orebibou.com.   172800  IN      NS      ns5.xserver.jp.
from: a.gtld-servers.net.#53 in 114 ms
orebibou.com.   86400   IN      SOA     ns1.xserver.jp. root.sv0.xserver.jp. 0 10800 3600 604800 3600
orebibou.com.   86400   IN      MX      0 orebibou.com.
orebibou.com.   86400   IN      NS      ns1.xserver.jp.
orebibou.com.   86400   IN      NS      ns4.xserver.jp.
orebibou.com.   86400   IN      NS      ns3.xserver.jp.
orebibou.com.   86400   IN      A       157.112.152.17
orebibou.com.   86400   IN      NS      ns5.xserver.jp.
orebibou.com.   86400   IN      NS      ns2.xserver.jp.
from: ns1.xserver.jp.#53 in 13 ms

2-4.LAN内で使われているIPアドレスを調べる

前にこちらで、LAN内で利用されているIPアドレスの調査方法について記述したことがあるが、その機能も持っている。
コマンド「disc」で、使われているすべてのインターフェイスが接続しているネットワークのIPアドレスを抽出してくる。
こちらも、地味にキーワードサーチ機能がついているようだ(「disc キーワード」で検索できる)。

2-5.ポートスキャン、IPアドレスの所有者確認を行う

「scan」コマンドで、対象ホストに対しポートスキャンを実施することができる。

local> scan BS-PUB-CENT7-01
+----------+------+--------+-------------+
| PROTOCOL | PORT | STATUS | DESCRIPTION |
+----------+------+--------+-------------+
| TCP      |   22 | Open   |             |
+----------+------+--------+-------------+
Scan done: 1 opened port(s) found in 2.051 seconds
local> scan google.co.jp
+----------+------+--------+-------------+
| PROTOCOL | PORT | STATUS | DESCRIPTION |
+----------+------+--------+-------------+
| TCP      |   80 | Open   |             |
| TCP      |  443 | Open   |             |
+----------+------+--------+-------------+
Scan done: 2 opened port(s) found in 2.039 seconds

IPアドレスの所有者を確認する場合は、「whois」コマンドを実行する。

local> whois 8.8.8.8
+------------+-------+--------------------------+
|   PREFIX   |  ASN  |          HOLDER          |
+------------+-------+--------------------------+
| 8.8.8.0/24 | 15169 | GOOGLE - Google Inc., US |
+------------+-------+--------------------------+

その他、hpingやnms、peeringなどいろいろなコマンドがそろっている。
これ一個で大体のことができると考えると、だいぶよさげなツールではなかろうか。
一応、「mylg」コマンドの後ろに内部コマンドを入れることでそのまま実行できるので、他のコマンドとパイプでつなげて実行するのにも困らない。

blacknon@BS-PUB-UBUNTU-01:~$ mylg dig orebibou.com
Trying to query server: 172.28.0.1  your local dns server
;; opcode: QUERY, status: NOERROR, id: 39603
;; flags: qr rd ra;
orebibou.com.   21599   IN      NS      ns3.xserver.jp.
orebibou.com.   21599   IN      SOA     ns1.xserver.jp. root.sv0.xserver.jp. 0 10800 3600 604800 3600
orebibou.com.   21599   IN      NS      ns5.xserver.jp.
orebibou.com.   21599   IN      MX      0 orebibou.com.
orebibou.com.   21599   IN      NS      ns4.xserver.jp.
orebibou.com.   21599   IN      A       157.112.152.17
orebibou.com.   21599   IN      NS      ns1.xserver.jp.
orebibou.com.   21599   IN      NS      ns2.xserver.jp.
;; Query time: 103 ms

;; CHAOS CLASS BIND
version.bind.   0       CH      TXT     "dnsmasq-2.55"

図解入門 よくわかる最新ネットワーク技術の基本と仕組み

Graylogでは、特定のログに記述されている”特定の項目の値”のみを抜き出し、Graylog側で個別に認識させることができる。
例えば、以下のようなログを受けたとしよう。FortiGateなんかがこんな感じのログだ。

Graylogでは、上の例でいうと「USER」「COMMAND」「ARGS」それぞれの値を抽出してやることができる。
じゃあどうやるのかというと、JSONの時とおなじように対象のログのMessageID、INDEX値を控えて[System] > [Inputs]から対象のインプットの[Manage extractors]を開き、ログを検索。
messageのとこで[Grok pattern]を選択する。

その後、抽出する箇所のGrok patternについて記述してやる。抽出できる項目は一項目につき一つ作成してやる必要がある。
たとえば、”USER”の項目を抽出するなら以下のようにする。このときに指定する変数は「stored pattern」のリンク先にいろいろとあるので、既存のパターンを参考に自分で変数名を作ることをお勧めする(Graylogで扱われる項目名がこの変数名になるので)。各パターンは正規表現を使っており、用意されているパターンだけでも十分使える(IPアドレスやメールアドレスなどの正規表現もすでに用意されている)。

Conditionでは抽出を行うログをどうするか(全部のログで行うのか、特定のキーワードを持つログに絞るのかなど)を指定できるので、環境に合わせて対応するといいだろう。
いろいろなログを一緒のINPUTで取り扱っているなら、そのログだけINPUTを分けるのも手だ。

無事、抽出が必要な項目について作成したら、あとはログを受信するだけだ。

うーむ、結構便利な機能ではなかろうか。

rsyslog 実践ログ管理入門

ジョブスケジューラーについていろいろと物色しているのだが、最近であればやはりRundeckは触っといたほうがいいだろうと思ったのでCentOS 7に入れていじってみることにする。
「Rundeck」は、Webベースのインターフェイスを持つ軽量なエージェントレス(ssh接続)のジョブスケジューラーだ。また、プラグインなどを用いて他のシステムと連携して、特定のログなどをトリガーにジョブをキックさせることもできる(この辺はStackStormのほうが対応数が多いっぽい。その他Apache NifiとかHugginとかのIFTTTに影響を受けたプロジェクトのほうが強いかも？)。
ジョブの記述もcronと同じように記述できるので手軽なようだ。一応、ジョブネットも作成可能らしい。

とりあえず、まずはインストールをしてみよう。
インストール先にはCentOS 7を用いる。なお、お試しなので冗長化はせず、FirewalldやSELinuxも無効化する。

1.インストール

RundeckはJavaで記述されているので、まずはJavaの実行環境から。
以下のコマンドでインストールする。

wget --no-check-certificate --no-cookies --header "Cookie: oraclelicense=accept-securebackup-cookie" http://download.oracle.com/otn-pub/java/jdk/8u101-b13/jdk-8u101-linux-x64.rpm
rpm -ihv jdk-8u101-linux-x64.rpm

次に、Rundeckをインストールする。

rpm -Uvh http://repo.rundeck.org/latest.rpm
yum install -y rundeck
systemctl start rundeckd

これで、Rundeckのインストールおよびサービス起動ができた。

2.初期設定

次に、Rundeckの設定ファイル(/etc/rundeck/rundeck-config.properties)を編集してブラウザから管理コンソールにアクセスできるようにする。

sed -i '/^grails/c grails.serverURL=http://[RundeckのIPアドレスorホスト]:4440' /etc/rundeck/rundeck-config.properties
systemctl restart rundeckd

3.ブラウザからアクセスする

さて、初期設定が完了したらブラウザからアクセスしてみよう。
「http://[RundeckのIPアドレスorホスト]:4440」にアクセスするとログイン画面が表示される。
初期ID/PWは「admin/admin」となっている。

ログイン後のトップページを見るとわかるが、Rundeckではプロジェクトがないとジョブを登録できないので、まずはプロジェクトを作成する。
[New Project]をクリックして、プロジェクトを作成する。
とりあえず、「Project Name」と「SSH Key File path」だけ設定しておけばいいだろう。そのままプロジェクトを作成する。

これで、ジョブが作成できるようになった。

4.Rundeckサーバ自身でのジョブ実行

まずはRundeckサーバ自身でジョブを実行させる。
「Create a new Job …」をクリックし、ジョブ作成画面に遷移する。

ジョブ名およびその説明文について記述する。
オプションについては、今回は設定しない。

次に、ジョブで実行するステップ(コマンドとかスクリプトの流れ)を設定する。
「If a step fails」はジョブ失敗時の挙動(「Stop at the failed step.」は失敗したステップでジョブを停止する、「Run remaining steps before failing.」は失敗したステップをスキップして残りのステップを実行させる)、「Strategy」はジョブの実行時の挙動(「Node-oriented」はノード単位での実行、「Step-oriented」はステップ単位での実行)となる。とりあえず、デフォルトでは「失敗したステップでジョブを停止する」「ノード単位での実行」となる。

「Add a Step」でスクリプトやコマンドなど、実行させるステップについて定義できる。
とりあえず、ここではCommandを選択する。

実行するコマンドの入力画面に切り替わるので、(今回はテストなので適当に)入力する。
コマンドの説明についてもわかるように記述する。

今回はローカルなので、「Execute locally」を選択。

「Send Notification?」の箇所で、ジョブの実行結果の通知設定を行うことができる。
メールの送信にはSMTPサーバなどの設定が必要になるので、今回は設定しない。

ジョブの実行スケジュール設定。
時間等をそのまま指定する方法と、crontabと同じフォーマットで指定する方法がある。

とりあえず、以上でジョブの作成を完了にする。
トップページから「Run Job Now」を実行してジョブを実行してみよう。

実行した結果がこちら。
無事ジョブの実行がされたことが分かる。

5.リモートサーバでのジョブ実行

さて、ローカルだけジョブを実行しててもあまり意味がないので、次にリモートサーバに対しジョブを実行してみよう。
Rundeckでリモートサーバに対して処理を行う場合は、sshログインできるようにする必要がある。プロジェクト作成時に鍵ファイルのPATHを指定している(デフォルトでは「/var/lib/rundeck/.ssh/id_rsa」にある)ので、その鍵ファイルをリモートサーバにコピーしてやろう。
ここでは、事前にリモートサーバ側でユーザ「rundeck」を作成、パスワードを設定しているものとする(鍵のコピー後は「passwd -d rundeck」でパスワードを削除する)。

ssh-copy-id -i /var/lib/rundeck/.ssh/id_rsa.pub rundeck@[リモートサーバ IPorホスト名]

次に、Rundeckにリモートサーバの情報を登録する。
Web管理画面からは登録できないようなので、コンソールから設定ファイルを編集する。
ノードの追加は、「/var/rundeck/projects/プロジェクト名/etc/resources.xml」に記述することで行える。
(以下の例では、イメージしやすいようosVersionなどはとりあえず入れてあるのだが、実際の環境に合わせて書き換えてもらいたい。)

sed '/^<\/project>/i\
  <node name="サーバ名" description="説明" tags="タグ" hostname="IPアドレスorホスト名" osArch="amd64" osFamily="unix" osName="Linux" osVersion="3.10.0-327.el7.x86_64" username="rundeck"/>' \
   -i.bk /var/rundeck/projects/*/etc/resources.xml

設定ファイルに追記したら、もう管理画面上からもリモートサーバを指定できるようになる。
今回は、とりあえず先ほどローカル向けに作成したジョブにノードを追加する。

「Nodes」のとこで「Dispatch to Nodes」を選択し、先ほど追記したノード名で検索する(このとき、部分一致で検索する場合は「.*」でちゃんと正規表現を書いてあげる必要がある)。

filterでの検索結果にジョブの実行対象となるノードが出ている状態で保存し、ジョブを実行してみよう。

無事、ジョブの実行ができた。
ノードの追加のとこがちょっと面倒な気はするが、悪くなさそうだ。

いろいろなプラグインもあるので、少しづつ使ってみよう。

【参考】

• ジョブスケジューラ「Rundeck」を試してみる ｜ Developers.IO
• そんなスケジューラで大丈夫か？ Rundeck超入門(基礎編) – くろのて

新人IT担当者のための ネットワーク管理&運用がわかる本

Rundeckでジョブの実行結果をSlackに通知する場合は、プラグインを導入してやる必要がある。
2016年時点では、Slack連携用のプラグインは以下の2個あるようだが、前者は3年ほど更新されていないため、今回は後者のプラグインを利用する。

• bitplaces/rundeck-slack-plugin
• higanworks/rundeck-slack-incoming-webhook-plugin

まず、以下のコマンドでプラグインをダウンロード、所定のディレクトリに配置しサービスを再起動する。
(ダウンロードするjarファイルは、こちらから最新のURLを確認してやるとよいだろう)

cd /var/lib/rundeck/libext/
wget https://github.com/higanworks/rundeck-slack-incoming-webhook-plugin/releases/download/v0.6.dev/rundeck-slack-incoming-webhook-plugin-0.6.jar
chown rundeck. rundeck-slack-incoming-webhook-plugin-*.jar
systemctl restart rundeckd

これで、プラグインの有効化ができた。
Rundeckでのジョブの設定前に、こちらでSlackのWebhookの設定をしておく。
WebhookのURLなどの払い出しを行ったら、あとは対象のジョブで「Send Notification?」の箇所でWebhookのURLを記述するだけだ。

ジョブを実行した結果。
確かに、Slackにジョブの実行結果が出力されるようになった。

現場のインフラ屋が教える インフラエンジニアになるための教科書

ネットワーク機器のコンフィグバックアップを自動化するツールといえば、前に紹介したrancid、rConfigらへんがあるのだが、rancidに影響を受けたツールで『Oxidized』というツールを見かけたので、ちょっと触ってみることにした。
サポートしているNW機器のOSは結構多くて、CiscoのIOSやJuniperのJunOS・ScreenOSはもちろんのこと、VyattaとかRouterOS、FortiOSとかもあるようだ(NetGearェ…)。
Webクライアントもあり、かつ履歴管理はGitで行えるようなので結構便利そう。

今回は、このツールをCentOS 7に入れてみる。

1.インストール

まず、前提パッケージのインストールを行う。

yum install -y cmake sqlite-devel openssl-devel libssh2-devel ruby gcc ruby-devel git

Rubyのインストールができたら、gemでOxidizedのインストールを行う。

gem install oxidized --source http://rubygems.org
gem install oxidized-script oxidized-web --source http://rubygems.org

これでインストール完了。

2.『Oxidized』の設定

さて、それでは設定を行っていこう。
まず、プロセス実行ユーザとして「oxidized」ユーザを作成、スイッチしよう。

useradd oxidized -d /opt/oxidized
su - oxidized

次に、oxidizedコマンドを実行してやる。
コマンドを実行すると、デフォルトの設定ファイルとして「~/.config/oxidized/config」というテンプレートファイルが作成される。

oxidized

[oxidized@BS-PUB-CENT7-01 ~]$ oxidized
edit ~/.config/oxidized/config
/usr/local/share/gems/gems/oxidized-0.18.0/lib/oxidized/config.rb:53:in `load': edit ~/.config/oxidized/config (Oxidized::NoConfig)
        from /usr/local/share/gems/gems/oxidized-0.18.0/lib/oxidized/cli.rb:24:in `initialize'
        from /usr/local/share/gems/gems/oxidized-0.18.0/bin/oxidized:9:in `new'
        from /usr/local/share/gems/gems/oxidized-0.18.0/bin/oxidized:9:in `'
        from /usr/local/bin/oxidized:23:in `load'
        from /usr/local/bin/oxidized:23:in `'
[oxidized@BS-PUB-CENT7-01 ~]$ ls -la ~/.config/oxidized/config
-rw-rw-r--. 1 oxidized oxidized 418 10月 15 15:56 /opt/oxidized/.config/oxidized/config

設定ファイルのテンプレートができたら、一応バックアップだけ取って以下のように編集してしまおう。
今回は、各ノードのコンフィグはすべてgitで差分を管理し、かつその情報をローカルネットワーク内にいるGitlabに連携させるようにする。
なお、以下の例ではインターバル(コンフィグの確認間隔(interval:))を30秒にしているが、これは環境に合わせて適切な値を模索してもらいたい。
※事前にGitlabにはユーザの鍵設定をしておくこと。プロジェクトの鍵だとPUTできないので注意。

●/opt/oxidized/.config/oxidized/config

---
username: oxidized
password: oxidized
model: junos
interval: 30
use_syslog: false
log: "/opt/oxidized/.config/oxidized/logs/oxidized.log"
debug: true
threads: 30
timeout: 20
retries: 3
prompt: !ruby/regexp /^([\w.@-]+[#>]\s?)$/
rest: Webインターフェイス用IPアドレスorホスト名:8888
vars: {}
groups: {}
input:
  default: ssh, telnet
  debug: false
  ssh:
    secure: false
output:
  default: git
  git:
    user: blacknon
    email: blacknon@XXX.com
    single_repo: true
    repo: /opt/oxidized/git/oxidized.git
hooks:
  push_to_remote:
    type: githubrepo
    events: [post_store]
    remote_repo: "git@GitLabサーバのIPアドレス:blacknon/NetworkConfiguration.git"
    publickey: /opt/oxidized/.ssh/id_rsa.pub
    privatekey: /opt/oxidized/.ssh/id_rsa
source:
  default: csv
  csv:
    file: "/opt/oxidized/router.db"
    delimiter: !ruby/regexp /:/
    map:
      name: 0
      model: 1
      username: 2
      password: 3
    vars_map:
      enable: 4
model_map:
  cisco: ios
  juniper: junos
  F5: tmos
  fortigate: fortios
  screenos: screenos
  vyos: vyatta

これで設定ファイルはOK。
次に、コンフィグを持ってくるノードのリストを作成する。
今回は、sourceのvar_mapでenableパスワードがある場合のみ、5列目に記述するように指定している。

●/opt/oxidized/router.db

対象ホスト名:ios:ユーザ名:パスワード:Enableパスワード
対象ホスト名:vyatta:ユーザ名:パスワード:Enableパスワード

設定ファイルを無事作成したら、最後に「oxidized」コマンドでプロセスを起動する。
(できれば、起動スクリプトを作ってやったほうがいいだろう)

oxidized

[oxidized@BS-PUB-CENT7-01 ~]$ oxidized
Puma 2.16.0 starting...
* Min threads: 0, max threads: 16
* Environment: development
* Listening on tcp://172.20.100.118:8888

起動したWeb管理画面がこちら。
今回はVyOSと手元にあったCatalystに対して実行している。

最新のコンフィグの内容は各ノードの右端列の一番左のボタンで見れる。

差分についてもdiffで確認することが可能だ。

今回はHookでGitlabにもデータを連携しているので、そちらでも確認ができる。

GitlabではなくGithubにもデータを連携できるし、インターバルに指定した間隔で自動的にコンフィグを確認、差分があったらちゃんと管理してGitlabやGithubに連携してくれるのでかなり便利だ。
対応しているNW機器が多いのも良い(個人的にVyattaとかpfSenseが対応しているのがポイント高い)。

家の環境のコンフィグバックアップにはこれを使おうかな。

図解入門 よくわかる最新ネットワーク技術の基本と仕組み

GraylogでStreamで定義したログを検知した際、Rundeckの特定のジョブをキックさせるようにさせたい。
そんな時は、Graylog側にこちらのプラグインを導入し諸々の設定をしてやればよい。

今回は、Graylogからログ内の特定の値をRundeckに連携して、任意のジョブを実行させるよう設定してみる。

1.Graylogへプラグインのインストール

まずは、以下のコマンドを実行してGraylogにプラグインのインストールを行う。
ダウンロードするjarファイルのURLについては、こちらで最新のものを確認しておく。

cd /usr/share/graylog-server/plugin/
sudo wget https://github.com/Graylog2/graylog-plugin-rundeck/releases/download/1.1.1/graylog-plugin-rundeck-1.1.1.jar
sudo systemctl restart graylog-server

これで、プラグインのインストール・有効化がされた。

2.Rundeck側での設定

次に、Rundeck側でAPIキーの払い出しや実行するジョブの設定を行う。
まず、ジョブを実行させるユーザ(今回はとりあえずadmin)でログインしProfile画面に遷移し、「API Tokens」からキーを払い出す。

次に、Graylog側から実行させるジョブを作成する。
この際、ステップにはスクリプトを指定してやることで引数を利用できる。
ここでは、既存のスクリプトではなく簡単なスクリプトをRundeck側で記述してやってジョブを作成した。

なお、オプションの変数名にはGraylog側のフィールド名を指定すること(今回は、Graylog側でSplitして作成した項目「TEST_ARGS」を指定している)。
ジョブの作成後、払いだされたUUIDを控えておく。

3.Graylog側での設定

次に、Graylog側の設定を行う。
対象のStreamで[Manage Alerts]をクリックしてalert conditionを定義したら、CallbackでRundeckの設定をする。
※このとき、RundeckのURLは基本的には「http://IPアドレスorホスト名:4440」となる。

また、GraylogからRundeckに値を連携するログの項目名を「Field arguments」に入力してやる(複数渡す場合は,(カンマ)区切りで入力する)。
なお、sourceやmessageといった項目は最初から対応しているので、それらだけ入力してやればRundeck側のオプション変数「source」「message」に連携がされる。

これで、連携設定が完了。

4.ログの検知・ジョブ実行の確認

最後に、実際にログを検知させてジョブがキックされることを確認してみよう。
ログ監視をしているノードで以下のようにコマンドを実行する(Streamの条件が項目「TEST_USER」がrootの場合となっているので、下のログならキックされる。)。

logger USER=\"root\" COMMAND=\"grep\" ARGS=\"aaa_args\"

無事、指定したログの項目が連携されたことが確認できた。
これで、特定のログが来た際には、そのログの値に応じたジョブを自動的に実行させることができる。

［改訂新版］プロのためのLinuxシステム構築・運用技術

RundeckからRedmineにチケット起票をさせるには、こちらのプラグイン(というか、パラメータファイル)を入れればいい。
以下のコマンドで、設定ファイルの配置およびサービスの再起動を行う。

git clone https://github.com/skylost/redmine-notification
cp redmine-notification/src/RedmineNotification.groovy /var/lib/rundeck/libext/

次に、Rundeckの設定ファイルにRedmineへの接続情報を記述しサービス再起動をする。
(下の例だとProxyはfalseなんだけど、ソース見たら先にProxyのURLとかportの代入してて空きだった場合エラーになって処理されないので一応項目は入れている。)

cat <<EOF >> /etc/rundeck/framework.properties
framework.plugin.Notification.RedmineNotification.proxy = false
framework.plugin.Notification.RedmineNotification.proxy_url = 127.0.0.1
framework.plugin.Notification.RedmineNotification.proxy_port = 4440
framework.plugin.Notification.RedmineNotification.redmine_url = http://Redmineサーバ/issues.json
framework.plugin.Notification.RedmineNotification.redmine_apikey = APIキー
EOF
systemctl restart rundeckd

これで、ジョブの「Send Notification?」のとこでRedmineが選択できるようになっているはずだ。

ちなみに、プロジェクトやトラッカー、優先度については数字のIDで指定する必要がある。
普通にRedmineの管理画面から見てもプロジェクトIDなどは数字で表示されないので、以下のURLにアクセスして確認するとよいだろう。

• http://IPアドレスorホスト名/projects.xml
• http://IPアドレスorホスト名/trackers.xml
• http://IPアドレスorホスト名/enumerations/issue_priorities.xml

で、Rundeckからジョブをキックした結果。
以下のように、無事チケットが発行された。

基本は、ジョブがこけた場合にチケットを発行させるようにすればいいだろう。

Redmine実践ガイド 理論と実践、事例で学ぶ新しいプロジェクトマネジメント

Rundeckでは対象のノードに処理を実施する場合、ssh接続してコマンドを実行するのだが、Windowsに対しジョブを実行する場合はWinRMを使うのがよさそうだ。
Windows 10とかならsshサーバも使えるようになったし、それ使えばいいんだろうけど、いかんせんWindows Server 2008/2012 R2などにはsshサーバの機能はない(OpenSSHとか入れればできる)。

できればWindowsとして提供されている機能でアクセスしたいなぁ…ということで、WinRMを用いての接続をする。
プラグインはこちら。なお、触ってみた限りRundeck側でスクリプトを書いて、それを転送して実行する使い方はできなそうだ。
スクリプトを実行する場合は、事前に転送しておいて対象のPATHを指定してキックするようにしよう。

1.Windows側でWinRMの設定

まずは、Windows側でWinRMの設定を行う。

winrm qc

PS C:\Users\Administrator> winrm qc
WinRM サービスは、既にこのコンピューターで実行されています。
WinRM は、管理用にこのコンピューターへのリモート アクセスを許可するように設定されていません。
次の変更を行う必要があります:

ローカル ユーザーにリモートで管理権限を付与するよう LocalAccountTokenFilterPolicy を構成してください。

変更しますか [y/n]? y

WinRM はリモート管理用に更新されました。

ローカル ユーザーにリモートで管理権限を付与するよう LocalAccountTokenFilterPolicy を構成しました。

次に、LinuxからWinRM経由でアクセスできるよう、Basic認証を許可する。

winrm set winrm/config/client/auth '@{Basic="true"}'
winrm set winrm/config/service/auth '@{Basic="true"}'
winrm set winrm/config/service '@{AllowUnencrypted="true"}'

PS C:\Users\Administrator> winrm set winrm/config/client/auth '@{Basic="true"}'
Auth
    Basic = true
    Digest = true
    Kerberos = true
    Negotiate = true
    Certificate = true
    CredSSP = false

PS C:\Users\Administrator> winrm set winrm/config/service/auth '@{Basic="true"}'
Auth
    Basic = true
    Kerberos = true
    Negotiate = true
    Certificate = false
    CredSSP = false
    CbtHardeningLevel = Relaxed

PS C:\Users\Administrator> winrm set winrm/config/service '@{AllowUnencrypted="true"}'
Service
    RootSDDL = O:NSG:BAD:P(A;;GA;;;BA)(A;;GR;;;IU)S:P(AU;FA;GA;;;WD)(AU;SA;GXGW;;;WD)
    MaxConcurrentOperations = 4294967295
    MaxConcurrentOperationsPerUser = 1500
    EnumerationTimeoutms = 240000
    MaxConnections = 300
    MaxPacketRetrievalTimeSeconds = 120
    AllowUnencrypted = true
    Auth
        Basic = true
        Kerberos = true
        Negotiate = true
        Certificate = false
        CredSSP = false
        CbtHardeningLevel = Relaxed
    DefaultPorts
        HTTP = 5985
        HTTPS = 5986
    IPv4Filter = *
    IPv6Filter = *
    EnableCompatibilityHttpListener = false
    EnableCompatibilityHttpsListener = false
    CertificateThumbprint
    AllowRemoteAccess = true

これで、Windows側の設定は完了。

2.Rundeck側の設定

次に、Rundeck側の設定を行う。
まず、以下のコマンドでプラグインのjarファイルを適切なPATHに配置する。

wget https://github.com/rundeck-plugins/rundeck-winrm-plugin/releases/download/v1.3.3/rundeck-winrm-plugin-1.3.3.jar -P /var/lib/rundeck/libext/
chown -R rundeck. /var/lib/rundeck/libext/

次に、リモートノードとして追加するため、「/var/rundeck/projects/プロジェクト名/etc/resources.xml」に以下のように追記する。

<project>
  <node name="localhost" description="Rundeck server node" tags="" hostname="localhost" osArch="amd64" osFamily="unix" osName="Linux" osVersion="3.10.0-327.el7.x86_64" username="rundeck"/>
  ...
  <node name="サーバ名" connectionType="WINRM_NATIVE" node-executor="overthere-winrm" winrm-password-option="winrmPassword" winrm-protocol="https" winrm-auth-type="basic" username="ユーザ名" winrmPassword="パスワード" hostname="IPアドレス:5986"/>
</project>

設定記述後、サービスを再起動する。

systemctl restart rundeckd

3.ジョブの作成

次に、ジョブの作成を行う。
基本的には通常のジョブ作成とたいして変わらないのだが、オプションとして「winrmPassword」という項目を作成して、デフォルト値に接続用のパスワードを入れる必要がある。

設定したら、あとはジョブを実行するだけだ。
とりあえず、hostnameコマンドなどを実行した結果が以下。

無事、ジョブが実行できた。
ほかでWinRMを利用しないのであれば、ファイアウォールなどでRundeckホスト以外からの対象ポートへのアクセスは制限しておくといいだろう。

ひと目でわかる Active Directory WindowsServer 2012 R2版 (TechNet ITプロシリーズ)

Linuxからpywinrmを用いてWinRM経由でWindowsを操作する場合、まず以下のコマンドをWindows側で実行しWinRMを有効にする。

winrm qc
winrm set winrm/config/client/auth '@{Basic="true"}'
winrm set winrm/config/service/auth '@{Basic="true"}'
winrm set winrm/config/service '@{AllowUnencrypted="true"}'

PS C:\Users\Administrator> winrm qc
WinRM サービスは、既にこのコンピューターで実行されています。
WinRM は、管理用にこのコンピューターへのリモート アクセスを許可するように設定されていません。
次の変更を行う必要があります:

ローカル ユーザーにリモートで管理権限を付与するよう LocalAccountTokenFilterPolicy を構成してください。

変更しますか [y/n]? y

WinRM はリモート管理用に更新されました。

ローカル ユーザーにリモートで管理権限を付与するよう LocalAccountTokenFilterPolicy を構成しました。

PS C:\Users\Administrator> winrm set winrm/config/client/auth '@{Basic="true"}'
Auth
    Basic = true
    Digest = true
    Kerberos = true
    Negotiate = true
    Certificate = true
    CredSSP = false

PS C:\Users\Administrator> winrm set winrm/config/service/auth '@{Basic="true"}'
Auth
    Basic = true
    Kerberos = true
    Negotiate = true
    Certificate = false
    CredSSP = false
    CbtHardeningLevel = Relaxed

PS C:\Users\Administrator> winrm set winrm/config/service '@{AllowUnencrypted="true"}'
Service
    RootSDDL = O:NSG:BAD:P(A;;GA;;;BA)(A;;GR;;;IU)S:P(AU;FA;GA;;;WD)(AU;SA;GXGW;;;WD)
    MaxConcurrentOperations = 4294967295
    MaxConcurrentOperationsPerUser = 1500
    EnumerationTimeoutms = 240000
    MaxConnections = 300
    MaxPacketRetrievalTimeSeconds = 120
    AllowUnencrypted = true
    Auth
        Basic = true
        Kerberos = true
        Negotiate = true
        Certificate = false
        CredSSP = false
        CbtHardeningLevel = Relaxed
    DefaultPorts
        HTTP = 5985
        HTTPS = 5986
    IPv4Filter = *
    IPv6Filter = *
    EnableCompatibilityHttpListener = false
    EnableCompatibilityHttpsListener = false
    CertificateThumbprint
    AllowRemoteAccess = true

これでWindows側の準備は完了。
次に、Linux側にpywinrmをインストールする。

yum install epel-release
yum install python-pip
pip install pywinrm
yum install gcc krb5-devel krb5-workstation python-devel
pip install pywinrm[kerberos]

これで、PythonでWinRM経由でコマンドを実行できるようになった。
なお、WinRMへのアクセス用のコマンドとして用意されているわけではないので、以下のようなPythonスクリプトを作成してアクセスする。

import winrm

s = winrm.Session('ホスト名', auth=('ユーザ名', 'パスワード'))
r = s.run_cmd('コマンド', ['引数'])

print r.std_out

[root@BS-PUB-CENT7-01 ~]# cat test.py
import winrm

s = winrm.Session('BS-PUB-WIN2012R2', auth=('Administrator', 'P@ssw0rd'))
r = s.run_cmd('hostname')

print r.std_out
[root@BS-PUB-CENT7-01 ~]# python test.py
BS-PUB-WIN2012R2

退屈なことはPythonにやらせよう ―ノンプログラマーにもできる自動化処理プログラミング

こちらにも記述しているのだが、wgetコマンドでダウンロードしたファイルを配置するディレクトリを指定する場合は、「-P」オプションで指定できる。

wget http://ファイルのURL -P /PATH

[root@BS-PUB-CENT7-01 ~]# wget http://orebibou.com -P /tmp/
--2016-10-12 18:23:59--  http://orebibou.com/
orebibou.com (orebibou.com) をDNSに問いあわせています... 157.112.152.17
orebibou.com (orebibou.com)|157.112.152.17|:80 に接続しています... 接続しました。
HTTP による接続要求を送信しました、応答を待っています... 301 Moved Permanently
場所: https://orebibou.com/ [続く]
--2016-10-12 18:23:59--  https://orebibou.com/
orebibou.com (orebibou.com)|157.112.152.17|:443 に接続しています... 接続しました。
HTTP による接続要求を送信しました、応答を待っています... 200 OK
長さ: 特定できません

`/tmp/index.html’ に保存中

2016-10-12 18:23:59 (815 KB/s) – `/tmp/index.html’ へ保存終了 [389940]

［改訂新版］プロのためのLinuxシステム構築・運用技術

Proxmox VE では、サブスクリプションが無いとログイン時に『No Valid Subscription』という警告が表示される。

これを非表示にするには、以下のコマンドを実行して条件式を書き換えてやればよい。

sed -i.bk "s/data.status !== 'Active'/false/g" /usr/share/pve-manager/ext6/pvemanagerlib.js

これで、ログイン時に上記の警告が表示されないようになった。

KVM徹底入門 Linuxカーネル仮想化基盤構築ガイド