2015年9月22日火曜日

Chinachu のコマンドフックで jq を使って予約変更メールを飛ばしたりする

まず、現時点ではChinachuのdevel-betaが必要なので、そのセットアップをする。


$ git clone https://github.com/kanreisa/Chinachu.git chinachu-test
$ cd chinachu-test

まずはこんな感じでclone。

$ git checkout devel-beta

で、devel-betaブランチに切り替え。元々使っているディレクトリを使いまわしても良いけど、何かあると怖いので、念のため-testにして、再取得しているわけで。

$ ./chinachu installer

Node.jsが4.0.0に上がっていたりするので、使いまわしたときはupdaterで必要ソフトの更新をすること。

必要なものとして、andreyvit/json-diffjq-1.5 と heirloom-mailx を入れよう。json-diff は npm install json-diff するだけ・・・のはずなんだけど、libディレクトリが無くなって上手く動かないので、Issue 投げてある。なんとかするには http://registry.npmjs.org/json-diff/-/json-diff-0.3.1.tgz を拾ってきて中の lib ディレクトリを node_modules/json-diff 以下に置けばなんとかなる。
jqの方はビルドするのもめんどいので、Download jq 1.5 ボタンから linux用の64bitなり32bitなりのバイナリを拾って来よう。heirloom-mailx は apt-get install でOK。heirloom-mailxの設定方法はこちらを参考に。

やっと本題に入れる。これで、PR #214 が入った Chinachu と必要なソフトが準備できたので、予約前/後フックが使える準備が整ったわけだ。(そのうちmasterに入ればこんな手順をふまなくても./chinachu updaterだけで良くなるんだけど)

  • conflictCommand
  • schedulerStartCommand
  • schedulerEndCommand
  • epgStartCommand
  • epgEndCommand
が、config.jsonのキーに追加されている。recordedCommandと同じように、実行可能なスクリプトファイルパスを指定すれば良い。今回はこのうちschedulerStartCommandにreserve_start.shを、schedulerEndCommandにreserve_end.shを設定する。

スクリプトは /home/chnachu/chinachu-scripts/ にまとめておくことにした。ログファイルとかもとりあえずここに放り込む感じで。

まずは reserve_start.sh から。ログ吐いたりしてるけど、やってることは reserves.json をちょっとだけ加工して、id: 予約内容というオブジェクト形式にしている。元々の配列形式だと順番が変わったりすると上手く diff が取れないのでその対策というわけだ。

#!/bin/bash

PID=$1
RULES_FILE=$2
RESERVES_FILE=$3
SCHEDULE_DATA_FILE=$4

LOGDIR=$(dirname $0)/logs
LOG=${LOGDIR}/reserve_start.log
JQ=$(dirname $0)/jq-linux64


RESERVES_BAK=${LOGDIR}/${PID}_old_$(basename $RESERVES_FILE)

date >> $LOG
echo "RULE:$RULES_FILE RESERVES:$RESERVES_FILE SCHEDULE:$SCHEDULE_DATA_FILE" >> $LOG

$JQ 'map({key: .id, value: .}) | from_entries' ${RESERVES_FILE} > ${RESERVES_BAK}

続いて reserve_end.sh で、こっちは start と同じように json の加工をまずやって、加工したもの同士で diff を取る。で、added と deleted を抜き出して、必要に応じてメールする、という処理をしている。TO=はもちろん、通知したいメールアドレスに書き換えること。

diff から抜き出すときに色々加工しているところにあれこれ工夫が入っているので、気になる人は jq のマニュアルを見ながら調べて欲しい。

#!/bin/bash

PID=$1
RULES_FILE=$2
RESERVES_FILE=$3
SCHEDULE_DATA_FILE=$4
MATCHES=$5
DUPLICATES=$6
CONFLICTS=$7
SKIPS=$8
RESERVES=$9

LOGDIR=$(dirname $0)/logs
LOG=${LOGDIR}/reserve_end.log
DATE=$(date +"%Y%m%d-%H%M%S")

RESERVES_MOD=${LOGDIR}/${PID}_new_$(basename $RESERVES_FILE)
RESERVES_BAK=${LOGDIR}/${PID}_old_$(basename $RESERVES_FILE)

DIFF=${LOGDIR}/${DATE}_${PID}_diff.json
ADD=${LOGDIR}/${DATE}_${PID}_added.txt
DEL=${LOGDIR}/${DATE}_${PID}_deleted.txt
MAIL=${LOGDIR}/${DATE}_${PID}_mail.txt

TO=hogehoge@gmail.com

#DEL_TMP=true
DEL_TMP=false

JSONDIFF=$(dirname $0)/node_modules/.bin/json-diff
JQ=$(dirname $0)/jq-linux64

date >> $LOG
echo "PID:$PID RULE:$RULES_FILE RESERVE:$RESERVES_FILE SCHEDULE:$SCHEDULE_DATA_FILE" >> $LOG
echo "MATCHES:$MATCHES DUP:$DUPLICATES CONFLICTS:$CONFLICTS SKIP:$SKIPS RESERVE:$RESERVES" >> $LOG
echo "***********************************************************************" >> $LOG

$JQ 'map({key: .id, value: .}) | from_entries' $RESERVES_FILE > $RESERVES_MOD

$JSONDIFF -j ${RESERVES_BAK} ${RESERVES_MOD} > ${DIFF}

$JQ -r 'to_entries | map(select(.key | endswith("_added")) | .value) | .[] | ("ID: " + .id, .channel.name, .title + " #" + (.episode|tostring) + " 「" + .subTitle + "」", .detail, (.start/1000+9*3600|todate) + "~" + (.["end"]/1000+9*3600|todate), "********************************************")'  ${DIFF} > ${ADD}

$JQ -r 'to_entries | map(select(.key | endswith("_deleted")) | select(.value.start/1000.0 > now) | .value) | .[] | ("ID: " + .id, .channel.name, .title + " #" + (.episode|tostring) + " 「" + .subTitle + "」", .detail, (.start/1000+9*3600|todate) + "~" + (.["end"]/1000+9*3600|todate), "********************************************")' ${DIFF} > ${DEL}


if [ -s $ADD -o -s $DEL ] ; then
    echo "*********Make mail**********" >> $LOG
    date > $MAIL
    if [ -s $ADD ] ; then
        echo "******以下の予約が追加されました******" >> $MAIL
        cat $ADD >> $MAIL
    fi
    if [ -s $DEL ] ; then
        echo "******以下の予約が削除されました******" >> $MAIL
        cat $DEL >> $MAIL
    fi
    heirloom-mailx -s "Chianchu スケジューラ" "$TO" < $MAIL
fi

if [ "{$DEL_TMP}" == "{true}" ] ; then
    rm -f $DIFF $ADD $DEL $MAIL
fi

スクリプトは gist にも上げておいたので見にくいって人はそっちを見てくださいな。

2015年9月21日月曜日

久々にLinuxマシン組んだ

K31AN-J2900 とゆーデスクトップ機が税抜き\30,500だったのでついつい買ってしまった。

某PT3を使った録画機として、色々すれすれなのだけど、この値段でファンレスPCが手に入るというのは素晴らしい。

スペックがすれすれなのは以下の理由から。

  1. PCI-Expressがx16が1個あるだけ。(しかもデフォで無線LANボードが入っている)
  2. SATAが2つだけ(デフォでDVD-ROMとHDD 500GB)

1.はまあ無線LANボードなんていらないのでさくっと外す。なんかノイズ防止か何かでアルミやら何やらが貼ってあって扱いにくかったけど、目的のブツを挿せたので問題なし。

2.は結構困ったもの。差し替えながらインストールとかをした。

  • HDDを外してSSDにする
  • SSDにUbuntu Server 14.04.3をインストール
  • DVD-ROMのSATAを外して(物理的に外すのが面倒そうだったので付けたまま)、HDD 2TBをくっつける
  • マウントさせる
  そんなこんなであれやらこれやら、 kanreisa/Chinachu を入れて設定完了。色々見てるうちに改造欲がむくむくと沸いてきたので fork して色々やって少しプルリクエスト送ってみた。devel-beta に取り込まれたのでそのうち master にも下りてくるんじゃないかなー。

2014年12月15日月曜日

GitBucketをWindowsでサービス化する

https://gist.github.com/backpaper0/9092197 参照。色々な方法があるけれど、winswが一番扱いやすいと思った。

2014年9月23日火曜日

OpenLDAPで access to * に迂闊に by self write をつけてはいけない

先日書いた件の詳細です。このダメダメ設定がどのくらい蔓延しているかというと、Qiitaの記事2本中2本ともにダメな設定になっているくらい蔓延しています。それと、今年か去年出た書籍もダメ設定が紹介されていました。

 何がいけないのか

 access to * によって、uidNumber, gidNumber, homeDirectoryあたりのアクセス権を by self write によってユーザに与えてしまっていることです。ログインしたユーザが、自分自身でldapmodifyコマンドや LDAP で通信するプログラムを使ってこれらの属性を書き換えることができるからです。

何がおこるのか

ldap.conf の設定にもよりますが、ローカルユーザが root のパスワードなどを知らなくても root に昇格できます。

どうしてこんなことになるのか

ローカルユーザがLDAPプロトコルを叩けることを忘れているからでしょう。それと OpenLDAP管理者ガイドのACLの節にby self writeの設定例が載っているのも一因でしょうか。LDAPサーバをディレクトリサーバとして使う分には access to * by self write していても問題ないのですが、認証サーバとして使うにはちゃんと ACL を考えないといけないということが抜け落ちているからでしょう。

pam_min_uidとか設定しているし大丈夫だよね・・・

直接 root になることはできません。しかし、sudoers の設定によっては、gidNumber を変えることで sudo  できるグループに自分で勝手に変更できてしまうかもしれません。そもそも他人のuidに変更できる時点で認証システムとしては失格です。

どう設定すれば良いのか

例えば、Debianの設定例のように loginShell, gecos に限定して by self write を付けるのが一つ目の方法です。二つ目の方法としては、uidNumber, gidNumber, homeDirectory などの勝手に変更されては困る属性を先に read-only に設定した上で by self write を付けることです。どちらかといえば前者の方がおススメですかね。

ダメダメ設定で実際に確認してみたい


2014年9月13日土曜日

ipython notebookをWebに上げる

ipythonのnotebookは便利だが,共有する方法が分からなかった。
とりあえず見つけたのは,nbviewerというもので,gistやgithubに上げると表示してくれるらしい。
試しにmatplotlibの派生プロダクトのprettyplotlib, matplotthemeの比較を上げてみる。http://nbviewer.ipython.org/gist/kounoike/c3e585ad21c0184b4708
ふむぅ。

検索してて出てきたAzureでipythonって記事のスクリーンショットがChromeでそこはかとなく笑いを誘ってくれる。

OpenLDAPのダメダメ設定のダメっぷりを示す

余り知られていないようですが、OpenLDAPの設定で迂闊なことをやっていると、ダメダメなこと(ローカルユーザにroot取られる)が起こることを示します。
Vagrant+Berkshelf+Chefを使った再現環境をgithubに公開しました。

が、明日からのPyCon2014に備えて寝ます。詳細は後日ここに書き足します。

追記
新しいエントリに書き足した。

2014年9月11日木曜日

Fluentd on Windows

こんな本 を買って、著者による講演会にも行ってきてログ解析熱が高まっている。

でも、色々な事情で、Windowsで動かしたい。 Windowsで。

調べてみるとFluentdがネックで、講演会の発表でもあったLogStashであれば、Windowsで動くらしい。
で、Windowsでのサービスとしてのインストール方法を調べてみると、こんなページが見つかった。これで、Elasticsearch、LogStash、Kibana3がWindowsでも動くというわけだ。
一方、FluentdはWindowsでも動かすだけなら動くらしい(Qiita Windowsでfluentdを動かす
ん? LogStashのサービス化にNSSMっていう外部ツール使っているんだったら、それFluentdでも使えばサービス化できるんじゃないの? Qiitaの記事にあるCTRL+Cで終了できない問題は解決しているっぽいし。
後で試してみるかー