タグ「Linux」が付けられているもの


rspamd の Web GUI にアクセスしてみる

rspamd をアップデートしたことで、使えるようなった機能があるので、いろいろと試してみよう

アップデートだけで結構な分量になってしまったので、フィルタについては別エントリーにて。バージョン上がったことで追加された機能もあるようなので、そのあたりの話もおいおい書いてきたいですね〜。

[From rspamd と rmilter をアップデート - Soukaku's HENA-CHOKO Blog]

ということで、まずは Web GUI から

Web GUI を有効にしてみる

と言っても、実際のところデフォルトの設定の状態でも、Web GUI は待受ポート 11334 で起動していて、下のような形で待ち受けしています。ただ、そのままでは localhost からの接続要求しか受け付けてくれないので、外部からも見れるように設定を変える必要があるというわけです。

root@vps2:~# lsof -i:11334
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
rspamd 13943 root 9u IPv4 905829 0t0 TCP localhost:11334 (LISTEN)
rspamd 13943 root 10u IPv6 905830 0t0 TCP localhost:11334 (LISTEN)
rspamd 13945 _rspamd 9u IPv4 905829 0t0 TCP localhost:11334 (LISTEN)
rspamd 13945 _rspamd 10u IPv6 905830 0t0 TCP localhost:11334 (LISTEN)
rspamd 13946 _rspamd 9u IPv4 905829 0t0 TCP localhost:11334 (LISTEN)
rspamd 13946 _rspamd 10u IPv6 905830 0t0 TCP localhost:11334 (LISTEN)
rspamd 13948 _rspamd 9u IPv4 905829 0t0 TCP localhost:11334 (LISTEN)
rspamd 13948 _rspamd 10u IPv6 905830 0t0 TCP localhost:11334 (LISTEN)
rspamd 13949 _rspamd 9u IPv4 905829 0t0 TCP localhost:11334 (LISTEN)
rspamd 13949 _rspamd 10u IPv6 905830 0t0 TCP localhost:11334 (LISTEN)

手っ取り早いのは、 rspamd 自身が待ち受けしている 11334/tcp を localhost 以外からアクセスできるよう設定することなんだけど、それはそれで芸がないし、無制限にアクセスを許可するのもよろしくないので、rspam の FAQ の中にある WebUI questions の部分に記述されている httpd からリダイレクトさせる方法で。

ところが、実際 Apache に対して設定してみたのだけど 500 Internel Server Error が出て上手く行かなかったので、結局 rspamd 側の設定でポート開放して、 iptables でアクセス元を絞る形に。

rspamd と rmilter をアップデート

ここ 2 年半ぐらい、rspamd を使い続けているサーバ、動作上特に不満があるわけでもなかったのだけど、

以前、インストールメモをエントリーとしてあげていた、 rspamdrmilter の組み合わせ、なかなか調子良く動作してくれている。

[From rspamd + rmiter の組み合わせに、ClamAV を連携させてみた - Soukaku's HENA-CHOKO Blog]

2週間ほど前から、そのサーバが受信・配送したメールに Spam がチラホラ紛れ込んでくるようになったので、「こりゃ自前でフィルタ書かんと駄目かな~」と思いつつ、公式サイトをチェックしてしてみたら…。

Rspamd is also available in some versions of Debian and Ubuntu. However, we are looking for an active maintainer for rspamd in these ‘official’ repos, as now rspamd is terribly outdated there.

Please DO NOT use those packages, as they are no longer supported.

[From Downloads]

「パッケージ、アップデートされねぇなぁ、 sid なのに…」とは感じてたんですけどね、「メンテナ探してるんだけど、 Debian/Ubuntu の公式サイトで配布してるのは古いんで使わないでね。」という状況だったはつゆ知らず…。

ということでフィルタを書く前に、公式サイトに書いてある手順を元に、最新バージョンの rspamd / rmilter にアップデートしてみた。

ということで、以下作業手順とログ

まず、現時点で、インストール済みのバージョンは、以下の通り。

root@vps2:~# dpkg -l rspamd rmilter
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name               Version        Architecture   Description
+++-==================-==============-==============-=========================================
hi  rmilter            1.6.3          amd64          Another sendmail milter for different mai
hi  rspamd             0.9.9+b1       amd64          Rapid spam filtering system

公式サイトで見ると、 rspamd は 1.4.4 、rmilter は 1.10 が最新のようなので、随分とバージョンが上がってますね…。

OpenDKIM が起動していなかったので、 systemd の設定を直した

何気なくサーバのログ眺めているときに、 /var/log/mail.info に気になるものを発見。

May  5 13:53:50 nexus01 postfix/smtpd[25332]: warning: connect to Milter service inet:[127.0.0.1]:54321: Connection refused
May  5 13:53:50 nexus01 postfix/smtpd[25332]: lost connection after CONNECT from nexus01.downtown.jp[127.0.0.1]
May  5 13:53:50 nexus01 postfix/smtpd[25332]: disconnect from nexus01.downtown.jp[127.0.0.1] commands=0/0

OpenDKIM が起動していなくて、メール処理時の DKIM による認証処理が、ここしばらくずっと止まっていた模様。(おそらく、数ヶ月単位で…。orz)

まずは切り分け

原因を突き止めねばらなんということで、まずは OpenDKIM の起動を試みるも、下のようなメッセージを吐くだけで、起動せず。

nexus01:~# service opendkim start
Job for opendkim.service failed because the control process exited with error code. See "systemctl status opendkim.service" and "journalctl -xe" for details.

メッセージ中にある通り、systemctl で OpenDKIM のステータスを見ると、 opendkim の起動がうまくいってないのが明らか。

nexus01:~# systemctl status opendkim.service | more
● opendkim.service - DomainKeys Identified Mail (DKIM) Milter
   Loaded: loaded (/lib/systemd/system/opendkim.service; enabled; vendor preset: enabled)
   Active: failed (Result: exit-code) since 木 2016-05-05 14:05:41 JST; 3s ago
     Docs: man:opendkim(8)
           man:opendkim.conf(5)
           man:opendkim-genkey(8)
           man:opendkim-genzone(8)
           man:opendkim-testadsp(8)
           man:opendkim-testkey
           http://www.opendkim.org/docs.html
  Process: 779 ExecStart=/usr/sbin/opendkim -x /etc/opendkim.conf -u opendkim -P /var/run/opendkim/opendkim.pid -p $SOCKET $DAEMON_OPTS (code=exited, status=64)
  Process: 776 ExecStartPre=/bin/chown opendkim.opendkim /var/run/opendkim (code=exited, status=0/SUCCESS)
  Process: 773 ExecStartPre=/bin/mkdir -p /var/run/opendkim (code=exited, status=0/SUCCESS)
 5月 05 14:05:41 nexus01 systemd[1]: Starting DomainKeys Identified Mail (DKIM) Milter...
 5月 05 14:05:41 nexus01 systemd[1]: opendkim.service: Control process exited, code=exited status=64
 5月 05 14:05:41 nexus01 systemd[1]: Failed to start DomainKeys Identified Mail (DKIM) Milter.
 5月 05 14:05:41 nexus01 systemd[1]: opendkim.service: Unit entered failed state.
 5月 05 14:05:41 nexus01 systemd[1]: opendkim.service: Failed with result 'exit-code'.

OpenDKIM 起動時に付与される $SOCKET や $DAEMON_OPTS は /etc/default/opendikim で定義されているので、

nexus01:~# grep -E "(DAEMON_OPTS|SOCKET)" /etc/default/opendkim
#DAEMON_OPTS=""
#SOCKET="local:/var/run/opendkim/opendkim.sock" # default
SOCKET="inet:54321" # listen on all interfaces on port 54321
#SOCKET="inet:12345@localhost" # listen on loopback on port 12345
#SOCKET="inet:12345@192.0.2.1" # listen on 192.0.2.1 on port 12345

その内容に従ってコマンドラインで直接起動すると

nexus01:~#/usr/sbin/opendkim -x /etc/opendkim.conf -u opendkim -P /var/run/opendkim/opendkim.pid -p inet:54321

問題なく起動することが確認できたので、OpenDKIM 自身の設定がおかしいということではなくて、systemd 周りに原因がありそうだ、と。

zabbix-2.4.7+dfsg ベースに Zabbix 3.0 のビルドをしようとしてハマる

Zabbix 、人柱も兼ねて、このところずっと rc 付きとか 3.0 系とかを自前でパッケージングして使っていたんですが、最近になって zabbix-agent がビルドできなくなり、なんでだろうと、ずっと思っていたんですが、そもそも 3.0.0 においては zabbix-agent は削除されたということで、ビルドできなくて正解だった模様。

:: Dropped support of zabbix_agent binary
Dropped support of Inetd version of Zabbix Agent.

[From Zabbix :: The Enterprise-Class Open Source Network Monitoring Solution]

となると、ビルドする中で zabbix-agent の処理を止めなくちゃいけないわけですが、それをどの部分で制御しているのかが判るまでに、結構時間取られたんで、念のためメモ的に残しておく。

ハマリポイントは、実は二つ

一つ目は JavaScript ファイルのコピー先がない、といってビルドが止まるというもの。こちらは、コピー先のディレクトリを dpkg-buildpackage コマンドの実行前に作る、ということで比較的楽に回避できたんですが。

make[1]: ディレクトリ '/usr/local/src/zabbix-3.0.0beta2.dev.58103' に入ります
DEB_BUILD_OPTIONS=parallel=4
I: zabbix_3.0.0+dfsg
Replacing sourceless (minified) bundled libraries...
cp -vfH debian/missing-sources/jquery.js  frontends/php/js/jquery/jquery.js
'debian/missing-sources/jquery.js' -> 'frontends/php/js/jquery/jquery.js'
cp: 通常ファイル 'frontends/php/js/jquery/jquery.js' を作成できません: そのようなファイルやディレクトリはありません
debian/rules:90: ターゲット 'override_dh_autoreconf' のレシピで失敗しました
make[1]: *** [override_dh_autoreconf] エラー 1
make[1]: ディレクトリ '/usr/local/src/zabbix-3.0.0beta2.dev.58103' から出ます
debian/rules:76: ターゲット 'binary' のレシピで失敗しました
make: *** [binary] エラー 2
dpkg-buildpackage: error: fakeroot debian/rules binary gave error exit status 2

で、二つ目が、zabbi-agent の削除に伴うもので、こっちを解消するのに、かなり手間取りまして…。

make[1]: Entering directory '/usr/local/src/zabbix-3.0.0beta2.dev.58100'
DEB_BUILD_OPTIONS=parallel=4
I: zabbix_3.0.0+dfsg
dh_install
dh_install: zabbix-agent missing files: debian/tmp-build-MYSQL/src/zabbix_agent/zabbix_agent
dh_install: missing files, aborting
debian/rules:127: recipe for target 'override_dh_install' failed
make[1]: *** [override_dh_install] Error 255
make[1]: Leaving directory '/usr/local/src/zabbix-3.0.0beta2.dev.58100'
debian/rules:76: recipe for target 'binary' failed
make: *** [binary] Error 2
dpkg-buildpackage: error: fakeroot debian/rules binary gave error exit status 2

メッセージから行けば、" zabbix_agent がねぇよ" というわけですが、まぁソースレベルで削除されてるんで当然なわけですが、この zabbix-agent に関する操作をどこでやっているのかが、最初全く見当がつかなくて悪戦苦闘していた、と…。

VirtualBoxのEFI有効な仮想マシンにインストールしたLinuxを一発で起動する 〜その後〜

さて、四苦八苦していた VirtualBox で EFI を有効にした仮想マシン上にインストールした Debian を一発で起動させる件。
前のエントリーで書いた通りではあるんですが。もっと簡単に解決できるのが判りまして…。

起動してきたら、次のような操作を、 root 権限で行います。

[From VirtualBoxのEFI有効な仮想マシンにインストールしたLinuxを一発で起動する - Soukaku's HENA-CHOKO Blog]

/boot/efi/EFI の下にブートローダを配置することには変わりがないのだけど、その方法はもっとシンプルでした。

なんのことはない、インストールの最終段階のブートローダの設定のところ。
以下の画面のメッセージの「 EFI リムーバブルメディアに GRUB インストールを強行しますか?」で "いいえ" を、ずっと選択していたわけなんでですが、ここを "はい" で抜けると…。

VirtualBoxのEFI有効な仮想マシンにインストールしたLinuxを一発で起動する

さて、うまいくかない、と思っていた VirtualBox 上の EFI 有効な仮想マシンでの jessie の起動の件ですが、

#結局、 jessie が、 VirtualBox の EFI 有効な仮想マシンで正しく起動しない件は、解消できずにいたり。

[From jessie と EFI/UEFI と VirtualBox と… - Soukaku's HENA-CHOKO Blog]

うまくいく方法が見つかったというか、どうも調べ足りなかったらしく、既に方法があったので、落ち穂拾い的エントリーを書いておく。

仮想マシンでEFIを有効化

そもそも、VirtualBox の場合、 EFI を有効化した仮想マシンの NVRAM にインストールした OS (この場合は、Debian )が用意する EFI 用のブートローダの在り処が記録されないという不具合?があるようで、 NVRAM にブートローダ情報がない場合に強制的に読みに行く場所に指定した名前でブートローダを置けば解消する、と。

1. NVRAMが読み込めない、又は読み込めてもNVRAMにOSの登録がない場合は、ESPの EFI/boot/bootx64.efi ファイルを読みに行く。
ubuntuのインストールでは作成されないディレクトリであり、当然ながら bootx64.efi ファイルも無い。

[From Ubuntu日本語フォーラム / ubuntuでのUEFIについて]

#目を通した記憶はあるんですよね、この情報…。う〜ん…。

apache 2.4.17以降でmod_http2有効にすると、送信バイト数が正しく記録されない?

HTTP/2 対応させてから 10 日ほど経過したわけですが…。

続いては HTTP/2 対応。これは、SSLが有効であることと、Apache HTTP Server の 2.4.17 がインストールされているのが前提です。

[From 自分んとこのWebサイトを常時SSL対応にして HTTP/2 にも対応させてみた - Soukaku's HENA-CHOKO Blog]

特に大きな問題もないなぁ~、と思っていたのだけど、ログを流し見していて気になる点、発見。
HTTPステータスコードに続けて、本来であればレスポンスとして送信したデータのバイト数が記録されるはずが、 "0" になっている。

203.0.113.60 - - [24/Dec/2015:00:39:58 +0900] "GET /~soukaku/images/eyecatch0002.jpg HTTP/2" 200 0 "https://www.downtown.jp/~soukaku/archives/2014/0217_004838.html" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_2) AppleWebKit/601.3.9 (KHTML, like Gecko) Version/9.0.2 Safari/601.3.9"

HTTP/1.1 であれば、下のログのように送信バイト数には "0" 以外の数値が入っている。

198.51.100.20  - [24/Dec/2015:10:28:42 +0900] "GET /~soukaku/images/eyecatch0002.jpg HTTP/1.1" 200 44068 "https://www.downtown.jp/~soukaku/archives/2015/0711_171147.html" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5) AppleWebKit/600.8.9 (KHTML, like Gecko) Version/8.0.8 Safari/600.8.9"

Web サーバとしてのサービス自身が止まっているわけではないし、HTTP/2 自体のアクセス比率もそう高くはないので、困った状況になっているわけではないけど、HTTP/2 でなければ "0" とはなっていないのだから、やはり動作としておかしい。
#awststs のようなアクセス統計ツールでの集計結果が正確なものでなくなる、という点では困るな…。

ドキュメント自体をチェックしてみると、

httpd 2.0 では 1.3 とは異なり、%b と %B フォーマット文字列はクライアントに送信されたバイト数そのものではなく、 HTTP レスポンスのバイト数です (これらは異なるもので、たとえば、 コネクションが途中で破棄された場合や、SSL 使用時に一致しません) 。 mod_logio で提供されている %O フォーマット文字列で、ネットワーク経由で実際に転送されたバイト数を 記録できます。

[From mod_log_config - Apache HTTP サーバ バージョン 2.4]

となっており、確かに実際の設定ファイルでも LogFormat ディレクティブの送信バイト数の位置には "%O" が指定されている。

root@vps2:~# grep ^LogFormat /etc/apache2/apache2.conf
LogFormat "%v:%p %h %l %u %t \"%r\" %>s %O \"%{Referer}i\" \"%{User-Agent}i\"" vhost_combined
LogFormat "%h %l %u %t \"%r\" %>s %B \"%{Referer}i\" \"%{User-Agent}i\"" combined
LogFormat "%h %l %u %t \"%r\" %>s %O" common
LogFormat "%{Referer}i -> %U" referer
LogFormat "%{User-agent}i" agent

Zabbix 3.0 のカスタムインターバルを試してみたのだけど…

さて、前のエントリーで、最初考えていたのとは、違う方法で実現したところがあったりします。

スクリプト内で処理をしている HTTP/2 でのアクセス比率の計算、最初は各バージョンのアクセス数をカウントした値を使って、 Zabbix 側の計算アイテムを使う予定だったのですが…。

アクセス比率のデータは、スクリプトの計算結果が小数点以下5桁の数値が送られくるので、それに合わせてデータ形式を浮動小数点型を選択し、Zabbix 側でパーセンテージ変換するために、単位 (Units) と乗数 (Use custom multiplier) の設定も合わせて行います。

[From HTTP/2 でのアクセス比率を Zabbix で蓄積&グラフ化 - Soukaku's HENA-CHOKO Blog]

当初案は、計算アイテム と カスタムインターバルの組み合わせ

最初の目論見では、HTTPバージョンのアクセス数だけスクリプト側で集計して zabbix_sender で送信して、アクセス比率は計算アイテムにして、その計算アイテムをカスタムインターバルで設定してみよう、と。(3.0 で実装された機能なので、どう動くのかを見てみたかった、というのもありましたし。)

It is possible to create custom rules regarding the times when an item is checked. The two methods for that are Flexible intervals, which allow to redefine the default update interval, and Scheduling, whereby an item check can be executed at a specific time or sequence of times.

[From 2 Custom intervals [Zabbix Documentation 3.0]]

カスタムインターバル自体は、データの取得やポーリングを決められた時刻や特定のタイミングでで実行させたい時などに有用な設定なんで、これが実装されるのを待っている人もいると思うのですが、実行タイミングをかなり細かく制御(といっても秒単位まで)出来るようで、「毎時 0 分 0 秒に実行」という指定も可能になっています。
下の例の "m/5s10" だと 毎時 0 分 10 秒、5分 10 秒、10 分 10 秒、15 分 10 秒(以下略)というタイミングで実行するという設定になります。(細かいパラメータは、マニュアルページ参照。)

カスタムインターバルの設定

HTTP/2 でのアクセス比率を Zabbix で蓄積&グラフ化

常時 SSL 化 & HTTP/2 対応したのはいいのだけど、実際自サイトへのアクセスが、どれだけ HTTP/2 で来ているのかを定常的にチェックする仕組みを考えてみた。

自分のところは、HTTP も HTTPS も同じ /var/log/apache2/access.log にアクセスログを出力しているので、そのログに記録されている HTTP バージョンを集計すれば出来るな、ということで、

  • logtail2 コマンドを使って、アクセスログの増分を取得
  • HTTP/1.0 、 HTTP/1.1 、 HTTP/2 それぞれでのアクセス回数のカウントと、HTTP/2 でのアクセス比率を計算
  • その結果を全て zabbix_sender で、Zabbixサーバに送信
という動作を行うスクリプトを Web サーバ上に用意してすることに。
スクリプトで利用している、 logtail2 コマンド( logtail パッケージに含まれる)と zabbix_sender のインストールについては、ここでは言及しません。
#HTTP と HTTPS でアクセスログを分離しているのであれば、 HTTPS 側だけ集計すればいいんですけど…。

下は実際に動作させているスクリプト。見てもらえれば、特に小難しいことをやってないのは判るんじゃないかと思います。

root@vps2:~# more bin/HTTP_Ver.sh
#!/bin/bash
item=()
# アクセスログの増分から、HTTPバージョンごとのアクセス数をカウント
/usr/sbin/logtail2 -f /var/log/apache2/access.log -o /tmp/apache2.offset > /tmp/apache2.diff
for i in 1.0 1.1 2 ; do
    verCount=`/bin/grep -c HTTP/${i} /tmp/apache2.diff `
    /usr/bin/zabbix_sender -z 127.0.0.1 -s vps2.downtown.jp -k HTTP.ver.${i} -o $verCount
    item+=($verCount)
done
# HTTP/2でのアクセス比率を計算
if [ ${item[2]} -eq 0 ]; then
    ratio=0.00000
else
    ratio=`echo "scale=5 ; ${item[2]} / (${item[0]} + ${item[1]} + ${item[2]})" | bc`
fi
/usr/bin/zabbix_sender -z 127.0.0.1 -s vps2.downtown.jp -k HTTP2.ratio -o $ratio

for 文の繰り返し回数の制御を HTTP のバージョン番号である " 1.0 1.1 2" (実際にアクセスログ中に出てくるもの)で行うようにして、この値を zabbix_sender で指定するアイテムのを識別するための key の識別に使う、というような工夫はしていますけどね。

次に、Zabbix サーバ側に、このスクリプトが送信するデータを受け付けるためのアイテムを作成します。

jessie でも Let's Encrypt & HTTP/2 実現のため apt-pinning を設定する

ということで、前のエントリーで表明したとおり、jessie で Let's Encrypt と HTTP/2 に対応する手順を纏めました。

# jessie 対応は、別途書きますかね…。

[From 自分んとこのWebサイトを常時SSL対応にして HTTP/2 にも対応させてみた - Soukaku's HENA-CHOKO Blog]

基本的には、パッケージのインストールに関する問題をクリアしてあげれば良い話で、インストールできてしまえば、あとは前のエントリーとほぼ同じ、なわけですが。

sid のパッケージを「借りる」ための apt-pinning の設定をする

Debian のパッケージングシステムである apt では、一部分のパッケージとその依存関係にあるものだけをインストールすることが、容易にできるような仕組みとして、 apt-pinning という機能が用意されています。 → apt-pinning に関する詳細

この仕組みを使うことで、 今回のように「基本 jessie だけど apache2 周りだけ sid 向けのパッケージを使う」とか「どうしても Let's Encrypt 対応したいけど jessie にはパッケージがない」といったニーズにも対応できるようになるわけです。
#このエントリー書いている時点で、という話であって、この先状況が変わることはあり得る。

まず、パッケージの借り元となるリリースバージョンを指定するために、/etc/apt/preferences.d/priority というファイルを作成します。(実際ファイル名は、拡張子がなければ何でも良いらしい。)
中身自体は、以下の様な3行だけ。

root@jessie:~# more /etc/apt/preferences.d/priority
Package: *
Pin: release a=unstable
Pin-Priority: 90

合わせて /etc/apt/sources.list に sid のパッケージのダウンロード先となるパッケージミラーの URL を記述します。
今回は、さくらインターネットが持っている Debian ミラーを指定。

# sid
deb http://debian-mirror.sakura.ne.jp/debian sid main non-free contrib
deb-src http://debian-mirror.sakura.ne.jp/debian sid main non-free contrib

この 2 つのファイルの作成と修正が終わったら、 "apttude update" でパッケージ情報をアップデートしておきましょう。

自分んとこのWebサイトを常時SSL対応にして HTTP/2 にも対応させてみた

Web 周りも、新しい技術を試してみようと思うと、サーバとクライアントの間の SSL 化が前提となってたり、無料でサーバ証明書を提供する Let's Encrypt というプロジェクトも正式サービスに向けてのベータテストが始まったりと、いいタイミングでもあるので、SSL 化と HTTP/2 対応を試みてみたので、そのログを残しておく。

まずは、常時 SSL 対応に

ツールのインストールから証明証の発行までは有志による Let's Encrypt 総合ポータルが参考になるので、そちらも参照しつつ、差分となるところを中心に書いていきます。

まず専用のクライアントソフトをインストールして〜、という話から始めなくちゃと思ったら、 Debian の sid 向けにはパッケージが提供されているので、それをインストール。
#最初試した時(11月の中頃)は、パッケージとして取り込まれてなかった記憶が…。
# jessie 対応は、別途書きますかね…。

いつもどおりというか、 "aptitude install letsencrypt" 一発で関連パッケージもインストールされるので、それで終わり。

root@vps2:~# aptitude install letsencrypt
以下の新規パッケージがインストールされます:
letsencrypt python-acme{a} python-configargparse{a} python-configobj{a} python-dialog{a}
python-funcsigs{a} python-letsencrypt{a} python-mock{a} python-parsedatetime{a}
python-pbr{a} python-psutil{a} python-pyicu{a} python-rfc3339{a} python-werkzeug{a}
python-zope.component{a} python-zope.event{a} python-zope.hookable{a}
python-zope.interface{a}
更新: 0 個、新規インストール: 18 個、削除: 0 個、保留: 20 個。
1,013 k バイトのアーカイブを取得する必要があります。展開後に 5,225 k バイトのディスク領域が新たに消費されます。
先に進みますか? [Y/n/?]

とりあえず、ここまででサーバ証明書を取得する準備が完了。

これ以降は、Let's Encrypt 総合ポータルの Let's Encrypt の使い方を参照しながら、行きます。
クライアントのインストール部分はすっ飛ばして、証明書の取得のパートからで OK。但し、Debian のパッケージではコマンド自体の名前が変更されている( letsencrypt-auto → lets encrypt )ので、その部分は読み替えが必要なのと、この時点で apache が起動しているときは一度終了しておくこと、実際にサービスを提供するサーバの上で実行しないとハマるので、その点には注意。

Zabbixのトリガーをtweetしたついでに吊る!

Zabbix のトリガーと連動して検知内容を tweet する方法は、前二つのエントリー通りで、こちらは期待通りに動いてくれている。

いま通知を tweet するようにしているサイト、実際に見に行って某クラスターお馴染みの即吊♥キャプチャーを使って、アーカイブを作っているのだけど、サイトの更新確認と同時に archive.is でのアーカイブ取得と Twitter への取得通知を自動化しちゃおう、というのが今回のミッション。

即吊♥キャプチャー|WEBキャプチャーをTwitterに投稿しちゃうアプリケーション

tweepyを使って、Zabbixのトリガーをtweetする(その2)

で、前のエントリーの続き。

tweet しようとしてハマる…

さて、Zabbix 側も設定が終わって、実際にトリガーに連動して tweet されるかをチェックするために、 zabbix-agent の停止で上がるトリガー使ってテストをしていたのだけど、一向に tweet されない。スクリプトを CLI で実行すれば任意のメッセージで tweet 出来るわけだから、スクリプト本体に問題がある可能性は低いだろう、ということで、 Zabbix Server でログレベルを debug に変更してログを採取。

すると、zbx2tw.py が呼びだされたタイミングで、以下のようなメッセージが出ていることを発見。

 17336:20151128:195521.400 zbx2tw.py output:
Traceback (most recent call last):
  File "/usr/lib/zabbix/alertscripts/zbx2tw.py", line 15, in 
    api.update_status(sys.argv[2])
IndexError: list index out of range

"IndexError: list index out of range" でググってみると、「リスト(配列)に対して存在しないインデックを指定した際に発生する例外」ということで、Zabbix が zbx2pw.py を呼び出す際に渡そうとしている引数の内容やその順番がおかしいのかもしれない、というところまでは判ったのだけど…。

zbx2tw.py の呼び出し方を変えてみる

まぁ、まだリリースされてもいない Zabbix 3.0.0alpha3 使っているんで、もしかしたらスクリプトに渡す引数に関する仕様が 2.0 や 2.4 と変わっていたりするかもしれないし、あんまり追求する気力もなかったのだけど、色々考えてみたわけですが…。

トリガー検知時の処理内容を変更

Zabbix ではアクションの設定の中で任意のコマンドを実行するように設定することも可能なので、「 zbx2tw.py をコマンドとして扱うように設定を変更してみたらどうだろう?」ということで、設定を変えてみたところ…。

なんと、ビンゴ!トリガーの内容が、tweet されるようになったじゃないですか!

具体的には、設定で、処理タイプをメッセージ送信からリモートコマンドへ。実行タイプにカスタムスクリプト、実行先として Zabbix Server を選択。
そして、コマンド欄に実行したい内容を記述、という感じ。


tweepyを使って、Zabbixのトリガーをtweetする(その1)

Zabbix 使って、 Web ページの更新をチェックしているところがいくつかあって、更新されたらメールが飛ぶようにはしているのだけど、それを tweet させられないか、ということで調べてみると、やはり先人は居るものですね。

A continuación, vamos a explicar cómo configurar de forma sencilla las alertas en Zabbix para enviarlas a Twitter.

[From Zabbix: Alertas a Twitter ~ El mundo en bits]

今回は、このスペイン語で書かれたサイトの情報を元に、やってみたというわけです。

tweepy をインストールする

まずは、 tweepy をインストール。

ここで軽くひとハマり。
上記で引用しているサイトに書かれた手順どおり、 tweepy を github から取得してセットアップしようしたら、以下の様なメッセージが出てセットアップが中断される。

root@vps2:~/tweepy# python setup.py install
Traceback (most recent call last):
  File "setup.py", line 5, in <module>
    from pip.req import parse_requirements
ImportError: No module named pip.req

あんまり時間かけたくなかったのと、原因調べるの面倒だったので、配布物に含まれる README.md を参照してみたところ、 pip というコマンドを使う方法も記述されていたので、そちらを試してみることに。
まず、 pip 自体をインストールする必要があるわけですが、これは Debian sid 向けに python-pip というパッケージがあるので、こいつをインストール。

root@vps2:~# aptitude install python-pip
以下の新規パッケージがインストールされます:
  python-cffi-backend{a} python-colorama{a} python-cryptography{a} python-distlib{a} python-enum34{a}
  python-html5lib{a} python-dina{a} python-ipaddress{a} python-ndg-httpsclient{a} python-openssl{a}
  python-pip python-pyasn1{a} python-requests{a} python-urllib3{a} python-wheel{a}
更新: 0 個、新規インストール: 15 個、削除: 0 個、保留: 202 個。
1,030 k バイトのアーカイブを取得する必要があります。展開後に 5,550 k バイトのディスク領域が新たに消費されます。
先に進みますか? [Y/n/?] 

Debian の常で、インストールしたいパッケージを指定して上げれば、依存関係は自動的に解決されて関連パッケージも一纏めにインストール完了。

続く pip のインストールも、コマンド一発で関連するモジュール群まで、無事インストール完了。

root@vps2:~# pip install tweepy
Downloading/unpacking tweepy
  Downloading tweepy-3.5.0-py2.py3-none-any.whl
Requirement already satisfied (use --upgrade to upgrade): requests>=2.4.3 in /usr/lib/python2.7/dist-packages (from tweepy)
Requirement already satisfied (use --upgrade to upgrade): six>=1.7.3 in /usr/lib/python2.7/dist-packages (from tweepy)
Downloading/unpacking requests-oauthlib>=0.4.1 (from tweepy)
  Downloading requests_oauthlib-0.5.0-py2.py3-none-any.whl
Requirement already satisfied (use --upgrade to upgrade): urllib3==1.12 in /usr/lib/python2.7/dist-packages (from requests>=2.4.3->tweepy)
Downloading/unpacking oauthlib>=0.6.2 (from requests-oauthlib>=0.4.1->tweepy)
  Downloading oauthlib-1.0.3.tar.gz (109kB): 109kB downloaded
  Running setup.py (path:/tmp/pip-build-ViGwji/oauthlib/setup.py) egg_info for package oauthlib
Installing collected packages: tweepy, requests-oauthlib, oauthlib
  Running setup.py install for oauthlib
Successfully installed tweepy requests-oauthlib oauthlib
Cleaning up...

で、ここまでで準備の第一弾が完了。
あとから気づいたのだけど、最初に tweepy のインストールに失敗したメッセージに "ImportError: No module named pip.req" とあるので、 python-pip も必要だった模様。

改訂版:Apache Traffic Server 〜実運用に向けての設定

Apache のログとか眺めてると、 Apache Traffic Server (以下、 ATS )について取り上げたエントリーへのアクセスがそれなりにあるのだけど、4 年も前の内容だし、ATS 自身もバージョンが上がっていて、ちょっと現状とあってなさそうな感じもしたので、新しいエントリーを起こしておきます。
4 年前は、バージョンが 2.1.9 とか 3.0.0 が出たばかりだとかって時期ですから。

アップデート対象のエントリーは、以下の 3 本。

インストール

インストールの対象とするとは Debian なんですけど、 wheezy には含まれていたのに、 jessie では外されたようですね…。(詳しいパッケージ情報
jessieでも、wheezy-backports のでも sid のでもパッケージは使えるのだけど、jessie と sid を混在状態にすると、後々めんどくさいことになるので、今回は jessie に wheezy-backports のものをインストールすることにします。ちなみに、wheezy-backports は 5.0.1 、 sid は5.2.0 なので、より新しい物を使いたいのであれば sid のものを、ということになりますね。

/etc/apt/sources.list に、以下のような行を追加。

# wheezy-backports
deb http://ftp.jp.debian.org/debian/ wheezy-backports main non-free contrib

"aptitude update" でパッケージ情報を更新した後、"aptitude install trafficserver" と実行すればインストールが行われます。

# aptitude install trafficserver
以下の新規パッケージがインストールされます:
  libaio1{a} libtcl8.5{a} tcl8.5{a} trafficserver
更新: 0 個、新規インストール: 4 個、削除: 0 個、保留: 0 個。
5,383 k バイトのアーカイブを取得する必要があります。展開後に 14.7 M バイトのディスク領域が新たに消費されます。
先に進みますか? [Y/n/?]

rspamd + rmiter の組み合わせに、ClamAV を連携させてみた

以前、インストールメモをエントリーとしてあげていた、 rspamd と rmilter の組み合わせ、なかなか調子良く動作してくれている。
せっかくなので、以前書いていたけど連携させていなかった clamav との連携についてもまとめておきます。

rspamd は rmilter を使うことで ClamAv とも連携出来るようだし、DKIM 対応も rspam 側に取り込めるみたいだし、個別にフィルタ書いたりと色々と弄りどころが多そうなので、しばらく様子見て調子が良ければ、全部 rspamd を使うようにしちゃおうかな?とか思い始めていたりします。

[From rspamd + rmilter をセットアップ - Soukaku's HENA-CHOKO Blog]

一応、英語ではインストールから設定まで解説してくれているページはあるので、そちらを見れば設定出来ると思いますが。

Rmilter is a milter-daemon by the same author of Rspamd. You can use it to integrate clamav (Anti Virus) scanning for your emails on postfix, and you will also need it if you want to integrate postfix with Rspamd itself. Click here for the compile & install how to of Rspamd under Debian Wheezy.

[From Perl Hipster: How to compile & install rmilter + clamav under Debian Wheezy]

インストールとセットアップ

rspamd と rmilter は、既に動作している事が前提なので、その部分の説明は省略。必要であれば、以前のエントリーを参照のこと。
イントールのターゲットは、 Debian なので、それ以外の Linux ディストリビューションの場合は、インストールの部分を適宜読み替えてくださいね。
#jessie では rspamd 、 rmilter ともに取り込まれていますね。

jessie と EFI/UEFI と VirtualBox と…

さて、先のエントリーをアップしたことを Twitter に流した時に

というようなことを合わせて書いていたんですが、その後何度か "EFI を有効"にした状態の仮想マシンに対して、 jessie のインストールを試行してみた限りでは、特段問題も起きておらず、GRUB ブートローダも正常にインストールでき、jessie 自体の起動も問題ないようです。
VertualBox 自体も、Mac 版の 4.3.6 、Windows 版の 5.0.0 beta2 それぞれで jessie をインストールしてチェックしてみましたけど、大丈夫でした。

ダメだった時は、ブートローダのインストールの直前に、何故かインストールメティアが認識されなくなるという事象も起きていたので、インストールそのものも挙動がおかしくなっていた、というのもあったりするので何が悪かったのかは、既に闇の中…。

" EFI を有効" にした仮想マシンと、そうではない場合の差分は?

EFI なマシンに jessie インストールした際のパーティショニングの確認画面

ということで、" EFI を有効"にしていない仮想マシンと" EFI を有効"にした仮想マシン、それぞれに jessie をインストールした時の手順の差分ですが、具体的には

  • ディスクのパーティション設定時に、EFI System Partition を作成するか、しないか
  • ブートローダのインストール先の選択の有無

の二点ぐらいでしょうか。(あとは、 d-i 起動時のメニュー画面での、UEFI の記述の有無ぐらい。)

EFI System Partition ( ESP )に関しては、インストールガイドの第 6 章に記述されているように、EFI でのブートローダを格納する領域として、FAT32 形式のパーティションを作成する必要がある、と…。

If you have booted in EFI mode then within the guided partitioning setup there will be an additional partition, formatted as a FAT32 bootable filesystem, for the EFI boot loader. This partition is known as an EFI System Partition (ESP). There is also an additional menu item in the formatting menu to manually set up a partition as an ESP.

[From 6.3. それぞれのコンポーネントの使用法]

d-i では対応しているので、ガイドに従ってパーティションを作成するときには、 ESP を確保するようになっているのですけど、手動でパーティションを設定する時には忘れないようにしないと、ハマる要因になりそうです。

Debian 8.0 をインストールしてみる:基本編

先週末にリリースされた "jessie" こと Debian 8.0 。

After almost 24 months of constant development the Debian project is proud to present its new stable version 8 (code name Jessie), which will be supported for the next 5 years thanks to the combined work of the Debian Security team and of the Debian Long Term Support team.

[From Debian -- News -- Debian 8 "Jessie" released]

とりあえず、VirtualBox 上の仮想マシンに対してインストールしてみたので、エントリーを起こしてみた。

jessieインストール用の仮想マシンの設定

対象とした仮想マシンの設定ですが、

  • チップセットを ICH9 に

としています。


debian installer の起動画面

VirtualBoxでの仮想マシンの設定が終わったら、インストールイメージ( debian-8.0.0-amd64-i386-netinst.iso )を使って起動するようにして、仮想マシンを起動すると、 debian installer の画面が表示されます。
カーソルキーの上矢印、下矢印で選択肢を選べるので、今回は "64 bit graphical install" を選択してから Enter 。

なお、これ以降の手順やスクリーンショットは、人手による選択や入力を必要とするところだけで、途中自動的に処理される部分の説明は省きます。


syslog-ng で名前付きパイプにログを出力する

以前 rsyslog で名前付きパイプにログを吐き出す設定の仕方を書いておいたのだけど、syslog-ng での設定の仕方も最近仕事でやったのでメモ的にエントリーしとく。

rsyslog の omsnmp モジュールでは、やりたいことには微妙に足りない感じなので、何か代替案はないかとドキュメントを漁ったりググってみた結果、名前付きパイプ経由でやればいいのでは、という結論に達したので、実際に試してみた。

[From rsyslog から名前付きパイプ経由で出力したログを snmptrap で飛ばす - Soukaku's HENA-CHOKO Blog]

インストールについては、今回の本題でないので、以下のところを参考にどうぞ。( CentOS/RHEL の場合)

CentOS 6 標準の syslogd は rsyslog なんだけど、CentOS 5 の頃に syslog-ng を使ってたので、それに切り替える手順。番号が連続してないけど気にしない。

[From CentOS 6.2 の syslog を syslog-ng にする - ..たれろぐ..]

さて設定ですが、syslog-ng の場合は /etc/syslog-ng/syslog-ng.conf に、ログの出力先とログ出力時のフィルタを決めて上げればいいわけですが、名前付きパイプに facility の local5 のログを出力するだけの最低限の設定は以下のとおり。
#今使っている設定に、 destination と filter と log を追加でも、勿論大丈夫。

options {
flush_lines (0);
time_reopen (10);
log_fifo_size (1000);
long_hostnames (off);
use_dns (no);
use_fqdn (no);
create_dirs (no);
keep_hostname (yes);
};
source s_sys {
file ("/proc/kmsg" program_override("kernel: "));
unix-stream ("/dev/log");
internal();
# udp(ip(0.0.0.0) port(514));
};

destination d_pipe { pipe("/tmp/log2pipe.log"); };

filter f_pipe { facility(kern); };

log { source(s_sys); filter(f_pipe); destination(d_pipe); };

あとは、"mkfifo /tmp/log2pipe.log" を実行して名前付きパイプを作成 → syslog-ng 起動( or 再起動)と。

"cat /tmp/log2pipe.log" で想定通りのログが出力されていることが確認出来たら、あとはスクリプトで出力結果を操作するなりなんなりと、ご自由に。

fail2ban の設定を見直し

fail2banを使い始めて暫く経ったのだけど、どうもアップデートをしたタイミングで、うまく動いていないようだったので、設定を見直してみた。

設定ファイルが更に細分化

0.8.13 から 0.9.1 へパッケージの変更が行われたタイミングで、設定ファイルの細分化が行われたようで、フィルタの有効化を制御するための設定ファイルが増えていました。

従来通り、/etc/fail2ban/jail.conf を修正してもよいようですが、

使いたいものがあれば、フィルタの方を必要に応じて修正した後に、/etc/fail2ban/jail.conf にある該当するフィルタの "enabled = false" を ”enabled = true” に書き換えて、再起動すれば、OK。

[From fail2ban を導入 - Soukaku's HENA-CHOKO Blog]

/etc/fail2ban/jail.d/defaults-debian.conf で利用したいフィルタの有効化やフィルタ毎の細かい設定を書く形になっていました。
#設定ファイルの名前から行くと、 Debian 独自の変更?