久々に仕事ネタ。CentOS6系+PHP5.6&ZendFramework2。

 Zendframework2ベースの開発で、でもZend::Mailだと日本語のあれこれに難があるっぽいので旧来通りのmb_send_mailを用いた添付可能メール配信クラスを作成。
 とりあえず正常に配信されるようになって一安心、でも色々試してみるかと確認してたところ
 「Thunderbirdで保存したemlファイルをOutlookで開くと、添付ファイルの中身がNullで埋まってる」
 とゆー現象に遭遇。試しに直接Outlookで取得するアカウントを作って送付してみたところ、そのシステムから送付した全ての添付ファイルが同じようになっている。ファイル名は正しい。ファイルサイズも正しい。でも中身が空っぽ。いやNullで埋まってるので空っぽではないのだが。
 Thunderbirdでは問題なし。Beckyでも問題なし。Gmailでも問題なし。Web版Outlookでも問題なし。・・・にも関わらずアプリ版Outlookではそうなる。

 色々調査&実験。emlファイルをテキストエディタで開き、添付ファイルのContent-Typeを別のものに書き換えたらうまく読めるようになった、という事があったのでメール送信側を変えてみたがダメなまま。じゃあなんで書き換えたらうまく行ったんだ?と疑問に思い、試しに「開く→何もせず保存」したところ読めるようになった(苦笑)。ここで何かしらの自動変換が影響してるものと推察。まあきっと改行コードだろう。

 元ファイル、及び元ファイルを開いて保存しただけのファイルをテキストエディタで比較してみると「違いはない」と言われる。改行コードも変わってないように見える。
 次に同じ比較をバイナリエディタでやってみる。すると「添付ファイルをbase64化した部分」の各改行コードが「\r\r\n」となっていることが判明。なるほどコレか。メールのCRLF問題っちゃ久しぶりだ。

 改めて添付ファイル部のコードを見る。やり方はネットでよく見かける手法で、ファイル添付部は以下のようにしていた。

  (この前で別のbody部を設定しつつ)
  $body .= chunk_split(base64_encode($attach))."\n";

 ここで改めて「chunk_split」について関数定義を見てみると

  string chunk_split ( string $body [, int $chunklen = 76 [, string $end = "\r\n" ]] )

 であり、非必須の第3パラメータが分割された各行の改行コードとなる。なるほど、他のところは全て「\n」、すなわちLFだけで指定してるのに対し、添付部はここで\rが余計に入っちゃったのか。

 第2パラメータは標準の76として、第3パラメータを「\n」のみ指定に変更。結果、無事Outlookでも添付ファイルが取れるようになりました、とさ。


 しかし世の中見てるとchunk_splitをそのまま使う記述例ばっかで、かつOutlookで添付ファイルに問題が発生したなんて話はほとんど見かけない。他の人はこーいったトラブルに遭遇してないのかなぁ。
 この手法そのものが今となってはあまり使われてないということなのか、それとも実行環境がWindowsベースで改行コードの問題が発生しにくいということなのか。あ、今回MTAはPostfix使ってるんでその辺が影響してるのかもしれない。今時MTAを自分のシステム上に持つなって話なのか?

 つか大抵のメールクライアントで対応できる事柄をいつまでも放置してんじゃないよ>MS、といういつものテンプレがオチなんだろう。
 





 

2015-12-25 [技術・作業]

 今日のアクセス履歴で「zendserver documentroot 変わらない」とゆーワードで来た方がいらっしゃったのですが、ひょっとして以前私が引っかかったのと同じ理由かもしれないので備忘録として記載しておきます。 

 その前に軽くご説明しときますと「ZendServer」とはPHP及びZendFrameworkを稼働させるためのWebアプリケーションサーバ。その実体はApache+PHPにZendFramework環境を搭載し、且つサーバ操作・設定用のGUIを搭載したもので、それぞれを個別にインストールするよりかは簡単にZendFramework環境を構築できるものです。LinuxだったらApache+PHPは標準として入っている事が多いのでZendFrameworkを入れてApacheを設定するだけなのでそれほど意味はない(※最適化とか別の利点はありますが)ですが、Windowsの場合にApacheごと1つのインストーラで導入できるので、それぞれを個別にインストールしたり、あるいはIISでPHPを動かす設定を行うより楽に環境が構築できます。プラットフォームを変更する可能性がある場合にも有効でしょうな。
 そいや何年か前に「IISでもPHPがちゃんと動くようになったよ!」とMSが盛んに言ってる時期があったけどアレってどうなったんでしょね。個人的には結局「PHPを動かすのにIISを選択するもんじゃない」とゆー結論に達しましたが。
 話を戻すと、結局のところインストールされるものはフツーにApacheでありPHPなので、設定方法は通常通りhttpd.confやらphp.iniやらのテキストを編集することで可能です。一部設定はGUIでも可能ですが慣れてる人は直接confなりiniなりを編集した方が早いと思います。DocumentRootの設定も然り。

 …と、前置きが長くなりましたな。ぶちゃけそんな複雑な話では実はなく、それどころかZendServerの話でもなく。
 インストール対象のOSがWindows7や2008Serverなどで、ZnedServerのインストール先を「Program Files」(含む(x86))にしてしまった場合、あのフォルダの配下はいわゆるUACにより通常権限でのファイルの書き換えができなくなっているため、「フツーの方法でテキストエディタなどからhttpd.confを開いて保存しても正式な登録として反映されない」とゆー罠があります。コレがヤらしいのは正式に登録はされなくてもどっかに仮保存されてるらしく、保存→再び開くとちゃんとデータが書き換わって見える点。なので「あれー?ちゃんと設定ファイル書き換わってるなー、でも設定反映しないなー」とすげー悩む事になるわけです。コレは「Program Files」配下に限らずWindows配下のhostsファイルとかも同様。
 とりあえず対処方法はメモ帳などのテキストエディタを右クリック→「管理者として実行」で管理者権限起動し、その上で「ファイル」メニューから目的のファイルを呼び出して編集→保存すること。対象ファイルをD&Dしてはダメ。
 根本的な対策としては「Program Files」とかのUACによって特殊な管理をされているフォルダを避けてインストールすること。 ま、セキュリティ的にそれが良いかどうかは別物ですが。

 そもそも根本的な問題としてUACの制御方法が一般人にとてもわかりにくい、とゆーこれまで議論百出した話になるわけですが。まあその可能性さえ押さえておけば他のアプリや設定ファイルで同じ事象が発生してもピンとくるかと思います。

2012-03-12 [技術]

 何故か昨日辺りからPhpMyAdminの脆弱性などを狙ったアクセスが増加してきた。具体的には

 /PHPMYADMIN/scripts/setup.php

 等の管理ページへのアクセスを狙ってくるもの。アクセス元は国外でバラバラ。まあアテにはならないが。
 本サイトはMySQLを使用してないので当然PhpMyAdminも存在しないのだが、ZendFrameworkのルーティング機能を用いているため、とりあえずどんなアクセスでも受け付けつつErrorControllerに流され、結果404エラーが返らないようになっている。何かしら応答がある!と思ったbotがチョーシに乗ってるのかもしれない。もっとも404を返したとしても試行されるのは変わらないだろうが。

 まあパターンは分かってるのでそのうちFBIにでもリダイレクトするように仕向ける予定。
2011-02-10 [セキュリティ]

 2011年初頭から1ヶ月経過して2月。本サイトver.5のβ版運用が始まってからはほぼ2ヶ月。その間ちまちまと完成に近づいてはいるが、逆に言えば未だ完成は見えず。そのココロはと問われると、ひとえにめどいからと答えよう(苦笑)。さすがに全コーディングをイチから見直すとなると大変でのぅ。今回コードの再利用率は10%未満だろーからなぁ。まあZendFrameworkのおかげで相当高速で書けてはいるし、主要な機能はできあがってるのでまあ良いのだが。

 そんな中、先日じみーに機能復活したのが「カウンタ機能」。最近はあんま流行らなくなった機能だけども、せっかく今までじみーにカウントしてたのがもったいない気もしたので。それに、どーせアクセス制御系の機能とアクセスログ系の機能は作らなきゃいけないから、それに組み込めばいい話だし。そんなわけで、復活したカウンタ機能の裏ではアクセス制御機能とアクセスログ機能が同時に復活したわけです。

 アクセス制御はその名のとーりアクセス可否を判断する機能。特定条件によるアクセスの拒否から、一定時間内過度アクセスの排除などを担うと共に、カウントアップ実行の判断などを行っております。カウントアップするかしないかはクローラ等除外の他、同一IP一定時間内カウントアップ禁止などを行ってます。以前はその判断のためにDBにアクセス時間を書き込んだ上で都度検証を行ってたワケですが、それは当然相応のトランザクションの発生を意味しており、それなりに速度低下を招いていただろなぁ、と。
 それに対し今回は、先日ちと話題に出したmemcached+Zend_Cacheを利用したメモリキャッシュ方式に変更。生存時間を設定できるキャッシュのおかげで大した苦労もなく判定できるようになった。アクセス制御等も同様。ちなみにカウンタ値も実は普段はメモリキャッシュに書き込みつつ、一定確率でDBにアップデートかけるGCもどき風味に。若干カウンタ値の欠損の可能性があるものの、これも負荷軽減にはけっこー効果があるんじゃないかと。

 アクセスログは…まあアクセスログ(苦笑)。別にApacheのログ+Webalizerでええやんとゆー話はあるものの、検索エンジンのキーワード解析とか、それらのデータマイニングを考えると、自前で取って且つDBに入ってた方が都合がよいので。
 こちらも以前は全てDB…PostgreSQLに都度書き込んでいたワケだが、やっぱそれはそれでトランザクションがアレ的な事になるだろう、と。前Verではログ書き込み部分をWebアプリ部から分離してシェル化し、表面的な体感速度の向上は図ってたので、更に今回はログの書き込み先をsqliteに変更してトランザクションそのものを分離。DBファイルは1日単位で作成する形式とし、1日単位でのデータ解析をやりやすいように。まあ逆にトータルでのデータ解析はやりづらくなってるかもしれないが(苦笑)、まあデータの統合はいつでもできるので。
 また、メインDBであるところのPostgreSQLは高速性を考慮して実体をSSDに置いてるが、ログDBはそんな必要もないので外付けのHDDへ書き込み。…これはむしろSSDの寿命を考慮しての事だったりする(苦笑)。

 …とまあこんなカンジで、表面上はほとんど現れない部分に結構苦労してたりします。めんどくさいのは分かってたのでイマイチ手を出す気になれなかった部分。でもまあ苦労の甲斐あって、以前と比べて色々高速化・最適化されたカンジがします。苦労したと言いつつ前verよりも環境整ってるんで比較で言えば楽だったんだけどね。
 あとメモリキャッシュ周りに手を出したついでに、頻繁にアクセスされるであろうトップページ(ルート)のデータ、及びRSSのデータをメモリキャッシュに置くことでの高速化も搭載してみた。ここんトコはアクセス解析と併用すれば更なる効率化が望める事だろう。

 つーことでちょびっと完成に近づいた。完成目標は今年度内!…ではあるものの飽きたらその限りにあらず(苦笑)。
2011-02-01 [日記]

 Webアプリ高速化の手法として良く見かけるようになったmemcached。標準状態のCentOSだとrpm、yumとかで入らないのでこれまで放置してきたが、今回システム入れ替えに伴い、自前で共有メモリを使って処理してた部分をmemcached+Zend_Cacheで置き換えようと考えた。

 それほどメモリが潤沢にあるサーバでもないんで(なんせCF-R3なので)キャッシュにおける情報はそれほど多くはない中で、キャッシュに入れる情報を吟味する必要がある。もちろんブログのように本来DBから読みだされてテンプレートを経由して表示、されるようなデータをキャッシュしとくのが効率的なのでそれも追々検討予定なのだが、取り急ぎ効果を確認したかったのがZend_Config_Iniで取り込まれるいわゆるINI形式ファイル。
 INI形式で取り込まれる定数系のデータは、基本的にそう頻繁には変更されず、一方でシステム全体に絡む設定が多いのでアクセスの度に読み込まれるものが多い。これをメモリキャッシュに置くことでどれくらい高速化されるのかを検証してみた。

 試験用として60個くらいの定数を持つINIファイルを作成。キーで6~7個くらいに分化されている。これをZend_Config_Iniで取り込みtoArrayで配列化したものをキャッシュに置いた状態をスタートとし、キャッシュの読み込み10000回にかかった時間と、ふつうにZend_Config_Iniで10000回取り込みにかかった時間を比較してみた。
 なおINIファイルの置き場所はSSDなので、HDDに置かれるよりかは高速に読みだされているものと思われる。

 結果。
   キャッシュ読み:1.63秒
   INI読み:9.17秒

 まあ当たり前だけど結構な差が付いた。頻繁に読まれるファイルだけに効果は大きそう。INIに入ってるデータってそんなに多くもないから(少なくともウチのシステムでは)メモリ的にもそんなに圧迫しないだろうし。とりあえずその方向で調整してみよう。

 あとはトップページや、アクセスランキングで上位に来る情報を優先的にキャッシュするよーにすれば結構高速化できそうな感じ。
関連タグ:PHPZendFramework
2011-01-24 [技術・作業]

ほほう。備忘。対応版のZend Serverも近いうちに出てくれるとありがたいのだが。
関連タグ:PHPZendFramework
2010-11-08 [ソフトウェア]