s3cmdでIDCFのオブジェクト・ストレージに接続

IDCFクラウドのテック・ブログで解説済みの内容ですが、2017年8月12日現在で最新版のs3cmdはバージョンが2.0になっており、落とし穴もあったのでまとめます。

動作確認が取れた最終的な設定ファイルは以下のようになりました。

[default]
access_key = [API Key]
secret_key = [Secret Key]
check_ssl_certificate = False
check_ssl_hostname = True
enable_multipart = False
host_base = ds.jp-east.idcfcloud.com
host_bucket = %(bucket)s.ds.jp-east.idcfcloud.com
send_chunk = 32768
signature_v2 = True
use_https = True

s3cmd-1.5以降マルチパート・アップロードがうまく動作しないらしいのでenable_multipartをFalseに設定しています。この設定が無いと、15MBごとに分割されてマルチパート・アップロードとなり、エラーが起きました。

とりあえず、巨大なファイルの転送が必要というわけでもなく、ネットワークも安定しているので、エラートラップをスクリプトにまかせればバッチ処理も可能そうです。

参考URL:
30分でできる！オブジェクトストレージへのログ保存（s3cmd + logrotate編）
30分でできる！オブジェクトストレージへのログ保存（fluentd編）
IDCFクラウドのオブジェクトストレージにWordPressとMySQLのバックアップを保存する
Access denied when uploading multipart that requires --acl bucket-owner-full-control

reportlabで、line.lineBreakがアトリビュートエラー

Ubuntu-12.04上のrst2pdfで、"wordWrap":"CJK"を指定してPDFを作成していたら、reportlabでエラーが。。。

  File "/usr/lib/python2.7/dist-packages/reportlab/platypus/paragraph.py", line 335, in _justifyDrawParaLineX
    simple = last or abs(extraSpace)<=1e-8 or line.lineBreak
AttributeError: FragLine instance has no attribute 'lineBreak'

あちこちさまよって情報を集めてみたのだけど、reportlabの問題らしく、最新版はパッチがあたっているとのこと。

Ubuntu-12.04にはバックポートされないようなので、自力で調整しました。

paragraph.pyの335行目を次のように調整して、エラーが出ないように。。。

    if hasattr( line, 'lineBreak' ):
        simple = last or abs(extraSpace)<=1e-8 or line.lineBreak
    else:
        simple = last or abs(extraSpace)<=1e-8

最新のパッチの内容は確認していないけど、とにかくエラーの抑止を最優先しました。
とりあえずPDFは生成されるようになったので、大きな問題でも出なければ、しばらくこのままで使います。

ALLOWED_HOSTS

Djangoの1.5が出たので、ロクにドキュメントも読まずにアップデートしたら、DEBUG=False の時だけ Internal Server Error が出るようになってしまいました。

DEBUGをTrueにすると現象が出ないので、何が間違っているのか調査のしようがありません。

原因は ALLOWED_HOSTS が宣言されていなかったことでした。

Django-1.4で作成したプロジェクトの settings.py に次の行を追加することで、とりあえず動くようになります。

ALLOWED_HOSTS = [ '*' ]

リリースノートに、ちゃんと書いてあるじゃん！読めよ！みたいな。。。

ALLOWED_HOSTS required in production¶
The new ALLOWED_HOSTS setting validates the request’s Host header and protects against host-poisoning attacks. This setting is now required whenever DEBUG is False, or else django.http.HttpRequest.get_host() will raise SuspiciousOperation. For more details see the full documentation for the new setting.

企業ユースだとセキュリティ的に接続元を限定したくて、Apache の Allow fromを 宣言することが多いのですが、これだと設定ファイルに書けばいいので楽チンですね。オーバーヘッドは気になりますけど・・・。

Wordpressのエラー処理が？？？

個人的には、サイトの作りに注文のほぼ存在しないお客様にはWordpressを、細かく注文をつけてくるお客様にはDjangoもしくは別のミドルウェアを紹介しています。

で、今回はWordpressをご指名で、機能的な調整をしたいという注文が入りました。

調整内容自体は簡単です。単に投稿時の入力内容に文字数制限を付けたいという話です。

でも、すでに地獄の１丁目だったんですね。。。

調べて判ったことですが、そもそもWordpressにはエラーの回復処理が存在していませんでした。
普通の入力フォームだと、入力項目にエラーがあると再度入力画面を表示して、画面の上部とか、エラーの起きた入力項目のそばにメッセージが表示されますよね。
それがWordpressではできないみたいです。

エラーを検出した時はwp_die()を呼び出して、エラーメッセージしか表示されていないページを出して、利用者には戻るボタンで戻ってもらうしかない。ただし、戻った時にはエラーの発生した入力項目は空白になっています。
それがいやなら、JavaScriptでデータのポスト前にチェックを行うか、コアの最深部に手を入れるしかなくなってしまいます。
JavaScriptでの検査は利用者が善人である前提でしか使えませんから、可能な限り回避したいとなると、Wordpressという選択肢自体が危うくなってしまいます。

WordpressにはWP_Errorクラスというのがあります。
フィルター関数内で簡単なチェックを行い、投稿データが保存条件を満たしていないと判断した時点で、このクラスのインスタンスを作成して返す。あとはWordpressまかせ。。。みたいな想像をしていたのですが、実際には何も起きずに、というか壊れた投稿を記録されてしまったため、理由を探してコアの中をさまよった結果判明したことです。(version 3.5.1)

アクションならと思いましたが、こちらも最終的にはフィルターと同じく$wp_filterに格納されて、apply_filters()とかで呼び出されます。アクション関数やフィルター関数からの戻り値は確かに変数に格納されるのですが、実行ループ中にその変数が参照されることはありません。


フィルター内でシステム的にクリティカルな状態になったら、後続のアクションをキャンセルして回復処理を行うとか、そういうプログラマティックな調整は一切受け付けてくれないミドルウェアであるとしたら、ちょっと今後は関わりたくないかも。。。

テーマと権限ロールが最初から設定されているところは良かったんだけどなあ。

gnome-terminalの小技

一度、別ウィンドウにしてしまったコンソールを、また元のウィンドウにタブとして戻す方法。

gnome-terminalでは、ひとつのウィンドウに複数のターミナルを同居させることができるけど、同時に表示させたい時なんかはタブをつまんでウィンドウの外に出すと、別ウィンドウになる。

ここまではいいんだけど、またひとつのウィンドウにまとめたくなった時は。。。

SHIFT+CTRL+Tでさらにタブを作って、必要な方のタブを元のウィンドウにドラッグアンドドロップすればいいだけだった。

どうして今まで気が付かなかったんだろう？そっちの方が不思議だ。

Audio CDから直接mp3にエンコード

知人からCDを数十枚預かりました。iPhoneに入れたいのだけど、枚数が多くて面倒になったとか。。。

預かったのが、仕事が忙しかった時期なので数週間放置してしまいましたが、そろそろマズいかなー？と思って、mp3エンコード用のスクリプトをpythonで作ってみました。

使い方は、これだけ。
rip -d /media/cdrom -o music/album

これで、mp3がmusic/albumディレクトリに生成されます。
いくつかオプションも用意されていて、-hで表示されます。
-oで出力先ディレクトリを指定しなければ、カレントディレクトリにmp3が生成されます。

https://docs.google.com/open?id=0By0Jpi03LH1HN0ltd0FteG5BTmM
上のリンク先がスクリプトファイルになっています。
適当な名前で保存して、実効ビットをセットするか、pythonインタープリタから呼び出すことで使用します。

目的が限定されていたのでやっつけスクリプトですが、改造すれば汎用になるかも。
いまのところ、
・エラートラップは無し
・生成されるファイル名は、トラック番号＋CDDBから取得したトラックタイトル.mp3 になる
・CDDBから取得した情報をtoc.jsonという名前のファイルとして書き出せる。
・エンコードしたファイルにID3タグを自動で書き込める
・デバイスは指定できるけど、処理が不完全。
というような仕様になってます。

動作にはpython-2.7、python-id3、python-cddb、cdparanoia、lameが必要になります。
Ubuntuの10.04上で作成したので、それ以降の環境ならパッケージは揃うと思います。

PHPでのフォーム処理を見直したりする

数年前とか数年以上前とかに作った、申し込みフォームをリニューアルすることになったので、処理を見直しています。

フォームは、入力部品を作成する時点で、PHPの連想配列にすべてまとめてしまいます。

<label for="cname">名前</label><input type="text" id="cname" name="sheet[name]" value="$sheet[name]">
<label for="cyomi">フリガナ</label><input type="text" id="cyomi" name="sheet[yomi]" value="$sheet[yomi]>

みたいな感じで、$sheetにフォーム内の入力項目を全部まとめてしまいます。
POSTデータを受け取ったスクリプトでは、$sheet変数の中身にだけ気をつければいいので、この方法は楽です。

さて、今回はオーダーメイドのフォームを作るのに飽きてきたので、汎用の入力検査処理をコーディングしてしまおうと考えています。
汎用化は、たしかにオーダーメイドに比べるとエラーに弱かったりバグが発生したりする可能性が大です。でも、それほど多種多様なケースに対応しなければならない状態というのは、いまのところ経験的に存在しません。
ということで、えいやっと作り始めたのはいいんですが。。。

ああ。とても面倒です。セキュリティ面の事も考慮すると、どうしても作業もデータも分散させざるをえません。
入力項目の検査は、検査対象となる入力項目のラベル、値への参照用コード、検査項目一覧情報をXMLに記述して、外部からはアクセスできない場所に置きました。フォームがPOSTされた後の処理は、これでOKです。
今度は、フォームの入力中に動的に行われる検査をコーディングしなければなりません。
フォームが正しく動くようになったら、人的ミスを最小限にするために、フォームの設定を記述したXMLから、ディレクトリを作成し、フォームの雛形を生成して、フォームの動作に必要なファイル群を正しい位置に配置してくれるようなヘルパ・スクリプトを用意しなければなりません。
もう、この時点でオーダーメイド・フォームを作成する作業の５割増しを軽くオーバーしています。

いや、選択を間違えたかもしれませんね。
いざとなったら、最後のスクリプトは無かったことにするかも。。。納期まであと1週間だし。。。