[OOPer's page TOP] [新うぱこむへ]
Powered by Google.

うぱさば日誌

longsleeve

2013/12/31

20:46
うぱさば日誌は、「真うぱさば日誌」として生まれ変わることになりました。これまでご愛読(?)ありがとうございました。

今後ともうぱこむと末永くお付き合いください。それでは皆様よい年越しを。

2013/12/30

20:46
ブログ管理画面の方だが、ようやく基本的な発言の入力・修正ができるようになってきた。まだまだ動かない機能が多いので、一般会員向けに公開するのは時間が掛かるだろうが、自分のブログだけは近日中に公開したい。うぱこむ開設当初より続くこの「うぱさば日誌」も、ブログ稼働後は廃止して、そちらに移管予定である。

しかしこいつ、トランザクションを全く使用しないのだな。デフォルトMyISAMだからある意味当然ではあるのだが。開発途上だとあっちこっちで不具合が発生するから、しょっちゅう不整合のあるデータがDB内に残って、その度に掃除が大変になる。

しかも超重い。一つの画面出すのに50回くらいクエリー発行するのはざら。まだ全機能のデバッグが済んでいないから、キャッシュ機能とかがうまく動いていないせいもあるだろうが、それにしても「ここまで複雑にせんでもえーがな」と思う部分は多い。自分で作るアプリなら開発環境でレスポンスが100msec以上なんて、徹底的にチューニングの対象だが、こいつに関しては、遥か昔にあきらめた。管理機能とプラグインの豊富さだけがメリットか。きっと昔まだバージョンを重ねる前は、そのプラグインやらテーマやらが作りやすいシステムだったんだろう。

2013/12/20

20:46
ようやくブログの閲覧用画面の移植がほぼ終了、まだ最新版(と思ったら本家はバージョンアップしていた)のデフォルトテーマからリンクが飛んでいる機能しか移植していないし、そもそも管理画面の方は、インストール機能以外は全く手を付けていないので、「これはあなたの最初の書き込みです」を読むことしか出来ないのだが。

作業開始から20日足らず、当初の想定より5割近く工数が余分にかかっている。まぁ、平均的なプロジェクト並みだろう…。例によって「いったい何を」と言われそうなんで、「MySQL専用のブログアプリをPostgreSQLで動かしている」と言ったら少しは許してくれる人が増えるだろうか。SHフレームワークベースにするために、ほぼ全部のモジュールを書き換えていたりする訳だが。「なんでそんなことを」と言われると納得してもらうのは難しいか。

最低限の管理機能の移植が早くて年内いっぱい、それに、うぱこむとしてのカスタマイズを施していたら、一般ユーザ向けに公開できるのはさらに先ってことになるな。その間、もうちょっと一般ユーザに「見える」機能の方にも手をつけたいのだが、ブログ移植の進捗が送れていたので、殆ど進んでいない。いつまでこのレベルの時間を割けるかも不透明なんで、もうちょっとどうなって行くかの方向性を見せられる程度まで、さっさと完成させたいのだが。

2013/12/12

20:46
BBSに画像付きメッセージを書き込もうとしたらうまく書き込めない。ログインしたらsudoも出来ない。コンソールはI/O関連のエラーメッセージで埋め尽くされている。どうも何らかの原因でファイルシステムが怪しい状態になって、ボリューム全体が書き込み禁止になっていたようだ。そんな状態でもWebサーバとしては動いているのがある意味すごいのだが、そのせいでアップロードファイルをテンポラリー領域に書き込むことが出来ていなかったようだ。そのレベルの異常があるのに実行を続けちゃうってのも良いのか悪いのか。

移植中のブログシステムだが、ようやくインストール画面が動くようになった。サーバ環境さえ整っていれば5分で使い始められるってのが売りのシステムを丸10日もかけてようやくインストール画面1個が動くだけってのは、何をやっているのか理解できない人には本当にわからないだろう。その上、プラグインの豊富さが売りのシステムで、既存のプラグインが全く使えないと言う、ある意味、超絶劣化バージョンになっている訳だし。

ぼちぼち週末だし、ユーザに見える部分もいじりたいのだが、ちょいとどの辺りに手をつけるか思案中。

2013/12/07

20:46
ディスパッチャー作成の方は、あまりにも簡単にと言うほどではないが、まぁ適当に既存のMVCを標榜するフレームワークに慣れている人が戸惑わない程度には終わったのだが。画像リンクをそちらに付け替えたら、やたらとレイテンシーが長くなっていたので延々とチューニングしていた。結局、ローカル環境の問題が一番大きかったようで本番環境にリリースしたら、そこそこの速度で動いた。

週に一カ所くらいはユーザの目に見える部分をいじろうってことで、昨日はメールアドレス追加の画面を作っていたのだが。入力させるのはメールアドレス1個だけだし、既に似たような画面遷移をする部分があるしでさくっと数時間で終わるつもりでいたのだが、結局深夜0時をさらに数時間越えることになってしまった。昨日は午前中半休だった訳だが、その分を考慮しても丸一日がかりってことになる。
 一番手間を食ったのは、フォームサポートクラスの中にいまだにcheckboxを作っていなかった点、Webアプリのプログラミングって観点に絞って仕様を考えていたら、えらく時間を食っちまった。他にも「モヤモヤした違和感」を感じながら取りあえずで実装した部分で、「こういう機能をちょいと入れてあればそんな余計なクラス作らなくて済むじゃん」なんてことに気がついて、やり直しとか。とにかく「モヤモヤした違和感」を放置したまま先に進むとろくなことは無い。

そこら辺を無事に終わらせた後、眠ろうとしても眠れず、結局未明に起き出して、新Webサーバ(white)から@oopers.com宛のメールがうまく送信できない原因を調べていた。OSのクリーンインストールのときにメールサーバ(postfix)も同時に入れたんだが、そのときに聞かれた設定で入力したドメインが、まんまmain.cfのmydestinationに記載されていた…。と言う訳で、メールサーバのibook君に送らないといけないメールを自前で処理しようとしていたらしい。main.cfをさくっと修正して無事に送信できるようになった。もうちょっと頑張って本来のメールサーバもこちらに移行したいところだが、ibookからのデータやアカウントも移行しないといけないんで、それはまた今度じっくりと。

2013/12/05

20:46
ディレクトリ構成の変更があまりにも簡単に終わってしまったので、URLパスベースのディスパッチャー作成に入った。参考記事を探しているときに、また「URLパラメータはSEO対策上よろしくない」なんて書いてあるのを見かけたのだが、当然のごとく検証可能な根拠は一切示されていなかった。以前見つけた比較記事は、そもそもまともな条件とは言えない比較(URLパス埋め込みの方は旧来のサイトのドメイン、URLパラメータの方は全くの新ドメイン…これで比較記事を書ける神経が信じられない)だったにも関わらずその差はわずかだったし。現在のSEO対策なんて、殆どがサンマの頭(注:イワシの頭以下の意味)、信じるものは救われるって世界なんだろう。反論をお持ちの方はきちんと検証可能なデータを示していただきたい。フレームワーク的には「やりたいんならそう言うことも出来ますよ」って部品だけは用意しとこう程度の意識で作っている。

2013/12/03

20:46
フレームワークのディレクトリ構成について、大胆な再構成(ま、リストラだな)を計画している。今後予定している大幅な機能追加を考えた時、今のままでは独立性の高いパッケージとしての追加が困難なので。

内部的には延々と格闘が続くのだが、サイトを訪れる皆さんの目に留まることは無い(エラーメッセージの固まりを見ることはあるかもしれない)だろう。これまでたびたび気にして覗いて下さった皆さんは、これからも我慢強くお付き合いいただけると嬉しい。

2013/12/02

20:46
70を越えてしまった。もちろん年齢ではなく、新サイトでちょっとした画面を出すのに読み込まれているフレームワークのクラス数の話。OPcacheを試しにオフにしてみても、10msecちょっとしか処理時間が増えなかったから、まぁ最近のOSのファイル処理もかなり優秀なんだろう。

昨日は延々と時間をかけて新サイトの多言語対応をやっていた。うちのサイトに英語モードやスペイン語モードでアクセスしてくれるような知人がいる訳でもないから、誰も気付かないだろうが…。せっかく訪れてくれた人が気付くような部分を先にやれば良いのにと言う気もするのだが、裏でフレームワークを作っている関係上、多国語対応の機能は外すわけにはいかないし、日本語オンリーのつもりで作ったサイトを後から多国語化するのは大変なのだ。
 スペイン語のネット用語がよくわからない。「ログインID」の訳を探すと、「nombre de usuario」って「ユーザ名」って意味の表現が出てくるのだが、うちのサイトの場合、ログインIDとハンドル名が別に持てるので、ログインIDの方を「ユーザ名」と訳していいものやら迷ってしまう。仕方ないので「nombre para entrar」なんて怪しい訳になっている。どうせ怪しくて良いんなら「ID para login」とか、英語のまんまで「login ID」の方が通じるかもしれない。誰かスペイン語が堪能なお知り合いがいる方は、是非ともうちのサイトのスペイン語リソースの監修をお願いしてもらいたい。報酬はちょっとしたバルでごちそうする程度しか出来ないが。

2013/11/17

20:46
PHPなんてタイプチェックも緩いしinterfaceなんて使わないよね、なんてずっと思っていたのだが。気がつけば、ぽつりぽつりと増えてきて、class, interface, trait合わせて1画面を出力するのにクラスファイルが60近く読み込まれている。まだログインチェックを入れていないので、さらに増えるのは間違いない…。OPcache様々だな。

フレームワークを作るってことで、あれこれのclassを量産していると、やっぱinterfaceを宣言しておきたくなる。POJOなんて言葉が流行してからと言うもの、変に自分流に拡大解釈して、やれ「ベースクラスを継承させるのはダサい」とか「interfaceを実装させるのはダサい」とか言った風潮があるが、ベースクラスやinterfaceを使った方が楽になるんなら使いまくれば良いのにと思ってしまう。

フレームワークによっては、「設定ファイルを用意するだけでコードを1行も書かなくてもWebアプリが出来てしまう」なんてことを標榜するものがあるが、そう言うフレームワークで実用的なサイトを構築しようと思うと、設定ファイルの文法がちょっとしたプログラミング言語より複雑で、『既存のプログラミング言語の』コードを1行も書かないだけで『(xxフレームワークの設定ファイルと言う)新しい言語を覚えてその』コードを山ほど書かないといけない、なんて羽目に陥る。その設定ファイルがxmlだったりして、標準開発環境に設定ファイル作成のサポート機能が全くなかったりすると、膨大なxmlファイルソースと戯れる時間が開発時間の殆どを占めることになったりする…。さらば、Struts。

新しい言語(設定ファイルの文法)を覚えるくらいなら、既に文法くらいは覚えている言語(今ならPHPね)で書いた方が楽だろう。そのためには、書かなきゃいけないことを指定してくれたり、書かなくても大抵そうするってことは用意してくれてたりする方がもっと楽だろうと思うのだが。POJO的なものを信望する人が作ったフレームワークの中には「クラス名をxxxにして、そのクラスにyyyって命名規則に従ったメソッドを用意して、この順にこんな処理をしてこんな値を返すようにすれば、ベースクラスもinterfaceも要りません」なんてものがあるのだが…。お約束の固まりを覚えるのは、明文化されている文法を覚えるのより大変じゃないの…。IDEはろくなチェックもしてくれないし。私がRailsを却下したのは、「お約束を十分理解しているメンバーだけを集められるような環境でないと、その力を発揮できない」と判断したから。個人で開発する分には自分だけが理解してりゃ良いんだが…。

Code over Convention & Configuration

2013/11/08

20:46
Zend OPcacheの効果を試したいだけだったのだが、随分時間を取っちまった。PHP5.5からZend OPcacheは標準パッケージに含まれたはずなんだが、MacPortsでもLinuxの有名どころのディストリビューションなんかでも、PHP本体とは別パッケージの扱いになっているようだ。

で、以前書いたようにPHPフレームワーク自体を作っている訳なのだが。出来るだけ軽量のフレームワークを作りたいと思いつつ、以下のようなポリシーを掲げた。
・ややこしいことは出来るだけしない。
・余計なおせっかいは出来るだけしない。
・使いもしないモジュールは読み込まない。
・設定は最小限に、動作を変えたきゃプログラムを書け。
・PHPの標準モジュールを出来るだけ使う。
…と言う訳で、出来るだけシンプルな実装を心がけてきたつもりなのだが、それでもやはり「せっかくフレームワークを使うんだから、この程度のことは楽に出来るようにしたい」とか考え出すときりがない。「オブジェクト指向なんだし、こんな実装にした方がきれいだよな」なんて思って、インターフェースやら抽象クラスやら使いだすと、どんどん読み込まれるファイルが増えてくる。
 以前、職場で「CodeIgniterでさえ十分重いよ、簡単なページ表示するのに何十個のファイル読み込んでると思ってるの?!」なんて話をしたことがあるのだが…。いざ自分で作っていこうと思うと、先に書いたような理由でどんどん肥大化してくるもんだ。まだセッションもフォームサポートも使っていない単純なページだけでも28のクラスファイルが読み込まれている…。CodeIgniterさんごめんなさいって感じだな。まぁ、何を書こうが、現在時点でCodeIgniterを採用するやつは馬鹿だと言う感想は変わらないが。

Zend OPcacheの挙動だが、読み込み済みのクラスに対しては、autoloader自体が呼び出されないのかと思ったら、しっかり毎回呼び出されていた。include/requireを実行する段階で、キャッシュにあるファイルは新たには読み込まないと言う動作をするようだ。考えてみれば、autoloaderを使わないでinclude/requireする部分もキャッシュを利用したい、とか、クラスファイルとは言え副作用のあるコードが全く走らないとは言えない、って状況を考えれば、クラス定義がキャッシュにあるからと言ってクラスファイル自体を読み込まないなんてのはまずい訳だが。

実ファイルが読み込まれないだけでも、クラスベースで書かれたPHPアプリにはかなり有効だろう。本番環境の方はどうするかは後で考えるとして、まずはキャッシュありきで、ロードされるクラスファイルの数はあまり気にせずにやっていこう。
20:46
Xcode4のDLに随分時間が掛かると思ったら、Safariが固まっていた。Download for Apple Developer (Xcode)のページに「Command Line Tools (OS X Mavericks) for Xcode - Late October」ってのがあった。これだけでもいけるんで無いの?と思ったらいけた。今まで通り、Preference...>Downloadからインストールできるようにすりゃ良いのに(ってか、開発ツールインストールするような人間はたいてい欲しがるからデフォルトでインストールしろよ)と思っちまうのだが。無料でApp Storeからインストールできる部分とは一線を画したいってところだろうか。それにしても、登録Apple Developerの場合は、Downloadメニューに表示する、なんて仕組みを作ったって良さそうなもんだが。
20:46
Xcode5からは、LLVM-GCCが削除されたようで。MacPortsには、gcc(互換)コンパイラが必要なようで、ディスクスペースがもったいないからとXcode4を削除したら動かなくなってしまった。Xcode4をインストールし直し、Preference...>DownloadからCommand Line Toolsをインストールし直し。Xcode4のインストールには、Apple Developer登録が必要になっている。どんどんUnixマシンらしい自由さを消そうとしているのだな…。

2013/10/28

20:46
oopers.com各種機能が一通り復旧。今後のためもあるので、覚え書きのつもりで原因をさらっと挙げておく。

[Webサーバ]
・固定IPで設定したはずのprivate IPが、なぜかルータのDHCP発行IPになっていたのを固定IPに戻した。
(ネット上の古い書き込みを見て、設定ファイルを直接編集したのだが、設定ファイル自体には「このファイルをエディタなどで直接編集しちゃダメ!」って意味のことが書いてあった。本当に正しい設定方法が見つかるまで、時々また起こるかも。)
[ルータ]
・DNS用のファイアウォール設定で、新DNSサーバへのTCP通信を許可するのを忘れていた。
(ポート転送だけで設定完了した気になっていた。)
・同じく、DNSサーバへのUDP通信に付いては設定の書き換え忘れどころか、設定そのものが無かった。
(なんで以前はこれで動いていたのかちょっと不思議。)

[DNSサーバ]
・named.confの設定を間違えていて、グローバルアクセスに対してもLAN内用の設定を返していた。
(OS Xのデフォルトの設定を出来るだけ修正せずに使おうと思ったので…。)

[メールサーバ]
・ネットワーク設定のDNSサーバが旧DNSのIPのままになっていた。

…という訳で、殆どがDNSサーバ切り替えに関わるもの。Webサーバ(以前はDNSサーバ兼用)の更新にあわせて慌ててあれこれ設定したのが、殆ど無茶苦茶だったという感じか。多少のアクセスチェックはしたんだが、特に外部からのアクセスの場合、うまくつながっちゃってたのは、こちらのDNSサーバにアクセスせずにキャッシュとか参照していたんだろう。

やっぱ、サーバ数が多すぎると設定の変更や追加も面倒になってくる。Web/DNS/メールくらいは1台で運用したいな。

2013/10/21

20:46
という訳で、先日のwhiteバージョンアップに伴い、新oopers.comが閲覧可能となっております。

新oopers.com

まだデバッグコードが時々表示される上に、『もう「リニューアル計画始動!!!」から一ヶ月もたつのにまだこんなもん?』と言いたくなるような内容だと思いますが…。

実は、アプリ開発に使用するフレームワークの開発を同時に行っております。CakePHP, CodeIgniter, FuelPHP, Symfony, Ethna…仕事で関わったPHPフレームワークは数あれど、どれも私が採用するには、帯に短し襷にも短しで。結局自分が一番使いやすいものは自分で作るしかないと決意したのでございます。(特にEthnaは最低最悪。論破されるまでちゃんと人の話を聞くつもりがある人は、コメント付けて下さい。)

途中、WordPressの信じられないほどぐっちゃぐっちゃな実装に惑わされかけたりしましたが、ようやく方向性が定まってきて、現在は主にSession機能の実装中であります。

そういえば、OSのバージョンアップに伴って、「うぱさば日誌」やら「News」やらのタイムスタンプが無茶苦茶になっているのを気づいておられる方もあるかもしれませんが、なんせiBookをサーバにしていた時代の名残。DBなんか使うよりエディタで修正したテキストファイルをファイル共有を使ってサーバに放り込む方が簡単だった時代に実装したもんで、ファイルのタイムスタンプ自体を記事のタイムスタンプにしていたのです。ファイル共有よりはましってレベルで、SVNリポジトリにしまうようにしたら、元のタイムスタンプの代わりにチェックアウト日時が表示されるようになっちまいました…。そこら辺の「ちょっと変だよ」も含めて、お付き合いくださると助かります。

機能・デザイン等に対する要望・修正やら、バグ報告やらは、トップページの管理者アドレスまでよろしくお願いします。
(もちろんBBSに直接書き込んでくださってもOKです。)

2013/10/18

20:46
昨夜から今朝にかけて、whiteのOSバージョンを最新化、それに伴ってPHPもバージョンアップした。それに伴わなくてもよかったのだが、Apacheまでバージョンアップされてしまって、一部の設定ファイルを書き換えるはめに。Whiteには元々desktop版を入れてあったので、最近はやたらと動きが重く、フリーズすることも多かったから、server版をクリーンインストールした。ログはどうしようかと思ったのだが、どうせ殆ど見ていなかったので保存していない。

whiteは、DNSサーバも兼ねていたので、whiteが動かない間のDNSサーバを設定し直すだけでも大変だった。結果LAN内用のDNSは未だにちゃんとは動いていない。

SVNリポジトリからソースを配置するだけで、ざっくりとは動いていたのだが、htmlspecialcharsのデフォルトがUTF-8になってたり、eregが完全にdeprecatedになってたり(昔はPCREの方が無くなるかもとか言われてたのに)で、昼に入ってもあれこれ修正。こういう退役予定のシステムのメンテというのは、どうもモチベーションがあがらない。そもそも、なぜこんな苦労をしてOSバージョンを上げたのかというと、新oopers.comを最新版のPHPで開発し始めてしまったのだな。今は最新でも完成する頃には普通になるかなぁなどと。ところがいくら頑張っても古いPHPが走っている旧whiteにはリリースできなかった(公式リポジトリ以外でも最新版PHPは見つからなかった、PHPぐらいのアプリになるとconfig設定だけで全く違うものが出来ちゃうので、自前コンパイルは避けたい)ので、フラストレーションが溜まっていたのだな。で、あれこれ考えたが、最新OSに乗り換えれば、PHPも新しくなるようだし、調子が悪いのもついでにクリーンインストールし直せば良いかと。

2013/10/11

20:46
このページが大人気である。多ければ毎分数十回のアクセスがある。IPアドレスを調べると、その殆どが中国は福建省(Fujian)からのもの。どっかの有名どころのphpアプリでprintlogs.phpに脆弱性でも見つかったのだろうか。ログがこればかりで埋め尽くされると見づらくなるんで、ページのURLの方を変えてしまった。これであきらめて来なくなると嬉しいんだが。

2012/01/16

20:46
WebSocketが去年の12月に無事にRFC化されていたらしい。まだProposed Standardの段階だが、技術的な部分は、一時「日替わりWebSocket」とまで言われたほどの頻繁な規格改定のおかげでだいぶ安定しているはずだから、後は手続き的な部分だけだろう。
 永らく停止中のまま放置してあったチャットページを再び稼働させるべく頑張ってみるか。Wikipediaによると、Jetty辺りが一番対応が良いみたいなのだが、WebSocketサーバーにするためだけに、フル機能のWeb/アプリサーバーを入れるのもなぁとか躊躇してしまう。Javaだしね…。ま、前のチャットサーバーもJavaベースだったから、移植はしやすいだろうが。

メールサーバーの移転も急がないと、老朽化著しいiBook君がいつまで働いてくれるか怪しいし、言ったっきりで全然進んでいないjQuery mobileベースのモービルうぱこむも何とかしたいんだが。

やりたいことは山ほど有るのだが、時間も体力も予算も続かない。誰か、好きなだけ好きなソフトの開発を続けさせてくれるようなスポンサーは現れないもんだろうか。

2011/12/28

20:46
ここ数日、大して厳しくもないうちのセキュリティ設定を突破するメールもなく(前回設定変更してから一ヶ月余りでわずか2通)、目新しいWebサーバーへの攻撃もなく、サーバ管理者的には平穏無事な日々が続いていたのだが。
 今日は久しぶりによく知らない攻撃が有った。phpThumb.phpだと。古典的なコマンドインジェクションが通るようだ。サムネイルジェネレーターだそうだが、攻撃が報告されたのは割と最近のようだ。いつも有名サイトがさんざん攻撃されまくった後、場合によっては数年遅れの攻撃を受けている弱小サイトとしては喜ぶべきか。WordPressとかの有名どころのプラグインとしても使われているようなので、phpのWebサイト運営者はお気をつけを。

私が「全部入り」と呼んでいる、過去に脆弱性の発見されたありとあらゆるphpモジュールを片っ端から試してみるタイプの攻撃も有った。今まで知らなかったのだが、中にはリファラーにphpスクリプトを仕込む例もあるのだな。Webアプリなんぞ書いていると、つい「このデータはここから来るから変な値が入りっこ無い」と言う思い込みを払拭できなかったりするのだが、リファラーなら大丈夫と思っちまったのか。
 攻撃者のIPアドレスは、58.254.143.204。中国は広東省のようである。10分以上に渡って、延々と404レスポンスを受け取りに来てくれたのは久しぶりである。一カ所への攻撃に10分も掛かっていては効率が悪いような気もする。ボット化するのが狙いではなく、クラッキングそのものが狙いなら、それくらい掛けても良いんだろうが、うちのような弱小サイトに侵入しても何も良いことは無いと思うぞ。

ちなみにDoS攻撃に対する備えは殆ど無いに等しいので、このホームページが見れない、なんて報告は随時頂きたい。

2011/12/12

20:46
なんと6年以上前、2005年にも紹介したawstatsに対する攻撃が、最近また増えている。(こうやって日誌ネタにすると、検索エンジン経由で攻撃ターゲットを探している連中に見つかるので、さらに攻撃が増える訳だが…。)最近の特徴は、phpAlbumなんちゅーのとセットで攻撃してくること。どちらも、同じ手法でだだ漏れサーバー化出来るようだ。以前書いた(2005/12/23付け「うぱさば日誌」、普通の人は見れない)ように、『「この程度で侵入できるようなプログラム公開するなよ!」と言いたくなる単純な手法での攻撃』であるのは、変わらず。初公開が2005年なら「コマンドインジェクション」「SQLインジェクション」なんて言葉は、Webアプリ開発者の間では、すっかりお馴染みになっていた頃。(なんせ脆弱性対策とかで、私が関わっていたシステムでも大幅な改修が有ったころだ。)その当時以降のアプリで、コマンドインジェクションがさっくり行なえるなんて、問題外も甚だしい、ほんっと、公開すんなよなと改めて言いたい。

2011/12/07

20:46
Helo command rejectedになる迷惑メールが、このひと月極めて少ない。せっかく設定を厳しくしてあるのに…って、訳ではないのだが、以前世界最大級のSPAMグループがお休み中との報道が有った時も、迷惑メールは見事に減っていたのだが、今は、HELOチェックまで届くくらい高度(って程でもないのだが)に偽装されたメールが非常に少ないと言う状況。今回もどこかのSPAMグループがお休みしているんだろうか。

久しぶりにBBSのバグ取りをした。モバイル版のリリースが先か、メールサーバーの移転が先か微妙なところである。

2011/11/29

20:46
phpMyAdminを狙った攻撃、以前はsetup.phpをチェックしに来ていたのだが、今日のはindex.phpを見に来ていた。新しい脆弱性が見つかったのか、単にインストールチェックをして、次の攻撃準備なのかは不明。バージョン番号が2.5.7なんてあるので、後者かな。いつも書いているが、オープンソースのphp(とかスクリプト言語CGI)モジュールを使用していると、ひとたび脆弱性情報が出回れば、侵入は極めて容易なんで、サーバー管理者は十分注意して欲しいもんである。うちのサイトは全編独自開発なんで、既存オープンソース用の脆弱性狙いは全然怖くないんだが、全く穴が無い訳じゃないんで、コードいじる度に塞いでいってはいる。PHPそのものに穴があると、ちょいと困る訳だが。PHPは文字コードの取り扱いが古くさく、特定の文字コードでの動作に関しては、まだまだ動作確認が不十分じゃないのかと思う挙動をすることもあるから、安心出来ない。

PHPを狙った攻撃の最初には、攻撃グループか攻撃ツール制作者か分からないが、何らかのグループ名らしきものを攻撃の最初に送りつけてくるのだが、そう言う連中の自己顕示欲を満足させても仕方ないので、ここには書かない。

url(data:〜)でのアクセス、何かの攻撃だと思っていたのだが、日本国内(それも1つは「キャノンシステムソリューションズ株式会社」だったりした…)から、普通にGoogleの検索結果を見に来る時に一緒に残っていた。セキュリティソフトの開発もやっている会社だし、ウイルスとかではないのかもしれないが、User-Agentを見る限り、同バージョンのIEが全部そんなリクエストを送ってくる訳でもないから、何らかの追加モジュールをインストールしているんだろうが、今のところ目的は謎。ログが見にくくなるから、変なモジュールは入れないで欲しい。

2011/11/23

20:46
掲示板のDB移行をようやく済ませた。画像をphpスクリプトから送信するようにしたわけだが、開発環境で動いていたスクリプトが、本番環境ではうまく動かない。あれこれいじっていたら、libpqのバージョンが違うと言うのに気が付いた。Ubuntu 10.04のlibpqは、(2010年4月ならPostgreSQL9.0のリリース前だったからだろうが)8.4のようである。9.0以降は10.04の公式リポジトリーには登録されていない。
 仕方無いのでソースコードからビルドすることにした。whiteには、サーバーとして動かすための最低限のモジュールしかインストールしていないんで、./configureの段階で、あれこれエラーが出て来る。bison/flexが無いぞの警告は、必要になりそうなモジュールはビルドしないんで、無視。readlineとzlibはerrorで止まってしまうんで、インストール。Debian/Ubuntuで採用されているapt-get、色々便利なところもあるのだが、パッケージ名がわからないとどうしようもないと言う大きな欠点がある。(他のLinuxのパッケージシステムも似たり寄ったりだとは思うが。)あちこち調べて、結局libreadline6-dev, zlib1g-devを入れたら、./configureは何とか終了。makeはお任せで普通に終わった。/usr/libのlibpq.so.5のシンボリックリンクをビルドして作成したlibpq.so.5.3に付け替えて準備は完了。apacheを再起動して(sudo service apache2 stop, sudo service apache2 start)、無事に画像が表示される事を確認。なぜか、phpinfo()の画面ではlibpqのバージョンが8.4.9のまんまで表示されるのだが、肝心な部分が動いてるんだから良いことにしよう。

まだ、時々応答がなくなり真っ白なページが表示されることがある(DBへの接続エラーだと思うのだが、接続エラーのメッセージを表示してから落ちるようにしたはずなのだが…)のだが、原因不明につき、こちらの対処は暫く放置。

それにしてもUbuntuさんよ、10.04はLTS版なんだから、PostgreSQLの最新版くらいサポートしてくれても良いと思うぞ。

取りあえず「冬が来る前に」ってのは、果たせたかな。大阪も朝晩は寒くなって来たけどね。明日(もう今日だが)は、ゼルダの発売日。そろそろ寝なければ。

2011/11/20

20:46
最近のapacheのログ、0x80以上の文字がずらりと並んで、HTTPコマンド(GET/POST等)さえないアクセス要求が目立つようになって来た。apacheにそこら辺の脆弱性でもあるのだろうか、IISなのかも知れないが。このサイトを開設したての頃は、バッファオーバーフロー狙いのリクエストがしょっちゅう届いていたから、ログが見にくくて仕方無かった。今はさすがに殆ど来ない。
 どんな脆弱性を狙っているのか調べたいのだが、毎回異なる文字列が送られてくるので、検索も出来ない。apacheかIISの脆弱性情報を探した方が早いだろうか。

BBSの方はようやく「発言1個表示」のDB対応コードが書けた。「全部読む」モードやら、発言順モード、ツリーモード等、全部処理内容が違う上に、独自DBでインデックスをオンメモリで処理していたから、処理を全面的に書き直さないといけないので、面倒臭い。大した事は全然してないのだが、本当に面倒臭いってだけ。

PDOのexecute処理、マニュアルにちゃんと、『すべての値は PDO::PARAM_STR として扱われます』と明記してあった。誰が設計したんだろうかね。PHPでは、いろんな型混在の配列が作れるって利点を全然利用していないってことだ。センスが無いにも程があるって感じ。いちいちbindValueとかbindParamとかするのは面倒臭いなと思っていたのだが、bindParamは結構便利かも。

2011/11/19

20:46
画像リンクを直接ファイルに貼らずに、phpでDBから読み出すようなコードを書いて、開発環境でレスポンスタイムの測定。ほぼ予想の範囲で、体感でもわかるくらいの一瞬の遅れがあるが、ネットが原因の遅延に紛れ込めば許せるくらい。うちのサイトの場合、大量の画像をどかんと流す事も無いので、これで良いかなと。キャッシュとかが効きにくくなるので、そこら辺の影響もあるかも知れないが。

PDOのマニュアルを見ていると、「PgSQLドライバでは」とか「Oracleは」とか、ドライバ依存の内容が、かなり出て来る。そこら辺の差異を吸収してくれてこその、オブジェクトラッパーだと思うのだが。これだと移植性はpg関数使う時と大差無いな。

2011/11/17

20:46
PDO_PGSQL、プリペアドステートメントの?パラメーターに論理型の値を渡すと、FALSEが空文字列に変換されてしまってエラーになる。どうも、一旦PHPデフォルトの文字列変換をして、後はDBにお任せって方針らしい。NULLやらFALSEやらが、みんな空文字列になっちまう。使い勝手的には、言語のnullがそのままでは渡せない他の言語と大差無いな。

2011/11/14

20:46
ぼちぼちとBBSのDBをPostgreSQLに移行する作業を進めているのだが、PDO_PGSQLがPHP Manualに記述された通りの動作をしない。具体的に言うとDSN中でユーザー名やパスワードの指定をした場合には、PDOコンストラクター中の該当引数は無視される、と書いてあるのに、実際にはPDOコンストラクターの引数が優先され、DSN内の記述を有効にしようと思うと、引数自体を省略しないといけなかった。

公式マニュアルに記述されているのと動作が異なるってのは、(簡単に回避する方策があるにしても)大嫌いなんだが。(ま、好きな人は無いと思うが、あまり気にしないって人はいるかな。)
20:46
ibookのimapアクセスログと、sasl認証用のログがローテーションされていない事に気が付いた。10.4 Tigerでは、ログのローテーションはlaunchctlのcom.apple.periodic-weeklyの担当で、実行されるスクリプトファイルは/etc/periodic/weekly/においてあるようだ。
 さて、Ubuntuはと言うと、その名もずばりでlogrotateとか言うのが走っているっぽい。設定ファイルは/etc/logrotate.confと/etc/logrotate.d/以下にあるが、普通にapt-getでインストールしたサービスについては、勝手に/etc/logrotate.d/に設定ファイルが追加されるらしい。(1週間で2GB超となったerror.logも、無事に圧縮された。)
 Lionはと調べたら、com.apple.periodic-weeklyではログローテーションはやっていない。さらに調べたら、newsyslogとか言うのが有って、そちらでやっているらしい。設定ファイルは/etc/newsyslog.conf。一口にUnix系と言うが、同じ事やるのにも色々やり方が有って、ややこしい。

全然関係無い話だが、AirMac Extreme君を再起動したら、ネットワークファイルアクセスがやたらと早くなった。先日ファームウェアがアップデートされたところだが、まだまだ不安定な部分があるのだろう。時々再起動させてやった方が良いのかも知れない。ちなみに管理ユーティリティからだとうまく再起動出来なかったので、電源を引っこ抜いてまた挿しての再起動、TimeMachine用のバックアップサーバーにしていなきゃ、他社製品に乗り換えるのだが。

2011/11/12

20:46
SQLインジェクションを狙ったと思われる攻撃が有った。発信元アドレスは、119.36.20.45。Whoisによると、中国は湖北省のアドレスである。遠くからわざわざご苦労な事だが、うちはまだ独自DBなので、この手の攻撃にはびくともしない。実際のところは、脆弱性だらけ(困るような攻撃があると、オンデマンドで対処すると言う感じ)なのだが、幸いその辺を突いて来る攻撃は、今のところ殆ど来ない。PostgreSQLに切り替えたら(以前の日誌を見たら、SQLiteにするとか書いてある、ここら辺の事情は実際に導入完了したら書くだろう)、きみの攻撃方法も参考にしてしっかり対策させて頂きます。

ニュースと日誌のページのデザインを、他と統一するために若干修正した。ま、誰も気付かないとは思うが。ついでに、日誌のページだけ文字コードがSJISになっていたのを、他のページと同じくEUCに変更した。古いブラウザで「戻る」ボタンで日誌の前後に移動すると文字化けしていたのが解消するはず…だが、そんな古いブラウザ使って、うちを見に来てくれる人はいないので確認出来ないが。

ちなみに、うちのサイトのシンプルなデザインを「手抜き」や「技術力不足」だと思っている人がいるらしいので、一言言っておくと、以下のような理由でわざとやっている。

1)携帯用のブラウザからも中身が確認出来る事
2)送信(見る側から言えば受信)データ量を減らす事

1)については、言わずもがなだと思うが、スマホなんてモノが普及する前は、外から確認しようと思うと、携帯ブラウザ使うしかなかったので、その対策。

2)については、今程無料Wi-Fiポイントが普及してなかった頃、海外APや国際ローミング(当時は海外パケホーダイも無かった)のような従量課金(それもかなり割高)での接続が結構多かったからである。小さな画像が数枚張り付けてある程度のページを2〜3ページ見ると、コーヒー一杯飲めたような記憶がある。

ちょいと近頃の事情には合わない部分もあるので、そのうちあれこれといじる予定ではある。

2011/11/11

20:46
CIDRでaccess制御リストを記述出来ると言うのに気が付いて、ひたすら既存のブラックリストを変換。途中まで手作業でやって、「このままでは一生終わらない」と思い、awkのスクリプトを書く。OS Xのawkはgawkではないようで、2進演算の機能が無かったのだが、CIDRの計算くらいは簡単な2進法の知識があれば書ける。今時は2進法の知識なんて全く無いままプログラマーやってるやつも多いから、そう言う人には何やってるか理解出来ないかも、などと考える。最近考え方がかなりじじぃ化しているかもしれない。

実環境に流してしばらくしてからログを見たら、警告多数。手作業でやった部分に間違いがあったようだ。スクリプトには、重複エントリーを削除する機能を入れてなかったんで、そこら辺の余分なエントリーを削除するのと合わせて、しゅしゅっと修正。自動化スクリプトを書いたりする時は、コスト対効果の判定で「スクリプト開発にかかる時間」と「そのスクリプトで節約出来る時間」だけを考えてしまうのだが、「自動化で誤りを減らせる」ってのを考慮に入れないといかんね。最近じじぃ化のせいで単純ミスも増えているし。

ログを眺めていて気が付いたのだが、実在のものと思われる日立のメアドに多数の転送要求があった。(当然全部跳ねてます。)最近流行の日本企業をターゲットにしたサイバー攻撃の一環だろうか。それにしては、送りつけてくるパケットが超稚拙、どこのメールサーバーでもさすがにこれはrejectするだろうって内容。ま、だからこそ、踏み台にするメールサーバーを探しているって可能性も有るが。発信元は114.112.228.108、whoisによると、香港のアドレスらしい。サイバー攻撃の一味なのか、単にボットネットに組み込まれた哀れなPCなのかは不明。セキュリティの観点から言えば、これだけ実在のアドレスが(単にスパム屋なのかサイバー攻撃集団なのかは分からないが)大量に流出している時点で失格だろう。

2011/11/10

20:46
11/2の設定では跳ねられてしまう困ったちゃんメールが届いてしまった。以前reject_unknown_hostnameを無効化したのも多分こいつのせいだな。その後全然直ってないんだから、しばらく放置しても直してもらえる可能性は低いから、こちらで対処。こいつのせいでかなりpostfixの設定が緩くなってしまう。サーバー管理者は何やってるんだか。内部ホスト名をそのまんま、HELOに載せてるんだろうが、こう言うのが平気なのが、大企業のシステム担当者にうじゃうじゃいるんだから、本気でサイバー攻撃のターゲットになったら、そりゃだだ漏れになっちまうのも仕方ないな。

2011/11/09

20:46
postfixの設定をまたちょいといじった。前回修正してから、迷惑メールは激減(1日10〜20通だったのが、2〜3日に1通…トップページにメアドさらしている割には、超少ない方だと思う)したのだが、そのわずかのメールに共通の特徴が有ったので、シャットアウトさせてもらった。
 かなり厳しい設定になったので、いくつか通常のメールに取りこぼしも生じている様子だったので、そう言うのだけはセーフリストで対処。本当は送信元のメルサバ担当者が気付くまで突き返したいところだが、利用者のことも考えるとそこまでは出来ない。

掲示板の方も、利用者側からの見た目は全然変わらない(変えないようにしている)はずだが、中身は連日大幅に書き変わっている。何か不具合を見つけたら、連絡を頂きたい。

2011/11/06

20:46
MacBook Airに開発環境を入れようと思っていじっていたら、ふとinitdbが入っているのに気が付いた。もしやと思ってLion Serverをもう一度確かめてみると、MacPorts版とは別のinitdbが存在している…。何をどう考えて無いと思い込んだのか分からないが、MacPortsの前から存在していた可能性が高い。何のために苦労したんだか。ちなみにAirのPostgreSQLのバイナリー一式は、Server.appを実行したときに勝手にLion Server化された時にインストールされたものらしい。私的にはminiをリモート監視したかっただけなのだが。

2011/11/05

20:46
Subversionの移転はさっくり完了。やっぱり必要なバイナリーが全部インストール済みと言うのは楽だね。なんでPostgreSQLにはinitdb付けないのかね。

iBookとLion Serverでは、バージョンが違う(iBookは1.5.6、10.7.2のLion Serverは1.6.16、ついでにUbuntu 10.04のwhiteは1.6.6だった)ので、データの移行はsvnsyncで。最初pre-revprop-changeを作成しろとか怒られた。リポジトリの/hooks/に正常(終了コード0)終了するスクリプトファイルを置いておかないといけないらしい。全部のリポジトリに同じ事やらないといけないのが面倒だったが、それさえやってやればさくっと移転は完了。mini側のsvnserveを動かして、iBook側の方は停止させた。

今後クライアントの方も、iBookからチェックアウトしたディレクトリーは削除して、miniから再度チェックアウトしなおさないといけない。忘れたまま修正するとあれこれ面倒になるのだが、そこら辺はオンデマンドで。
20:46
昼間書いたばかりだが、iBookのIMAPサーバーが不調。原因は不明だが、IMAPサーバーが使用しているDBが軒並み壊れている。メインのメールボックスは、再起動したら修復したんだが、ユーザーデータベースの方は壊れたままらしく、うまくつながらない。ユーザー自体は消えていなかったので、あきらめてパスワードだけ再登録したのだが、なかなかこの先が不安である。

サーバーの移転を加速したいところだが、このトラブルのせいで逆にsubversionの移転も、BBS用DBの作成も放置することになった。明日はこの辺の作業は一休みにして別の作業に掛かる予定。
20:46
Lion Server、subversionはインストール済みで、svnserveを初めとするバイナリー一式はちゃんと存在するのだが、svnserve用のlaunchd plistは見当たらない。iBookは10.4 Tigerなのだが、そちらのplistは殆どそのまま使えそうだ。デーモンをログインユーザーで起動すると言う変則的なことをしているので、そこら辺は修正しないといけない。

GUI画面でさくっと管理起動が出来る、とまでは望まないが、せめて設定ファイルのひな形くらいは用意しても良いんでないの?本当に何のためのサーバーOSなんだかよくわからない。殆どあらゆるサービスの管理がGUIで出来るって意味では、圧倒的にWindowsサーバーに軍配が上がる。管理出来るサービスがMicrosoft独自のものばかりって部分を改善してくれたら、多少は使い出があるのだが。
20:46
いつまでも構成設定で試行錯誤していても前に進めないんで、「MacPorts標準構成の別インスタンス」ってことで運用することにした。

pgAdminってMac用もちゃんと出ているのだね。管理者用と使用者用のユーザー(PostgreSQLの場合、実際はロールだが)を追加。ユーザーから各DBへの権限の設定方法が分かりにくい。BBS用データベースは、テスト用と本番用を別に作成。

pg_hba.confを直接いじって、自サバ以外のLAN内アクセス情報を追加。接続先毎に細かくアクセス制御出来るのは良いが、IPアドレス(CIDRだが)を直接記述しないといけないのはいただけない。ホスト名による指定も可能だが、その場合は全ホスト名を列挙しなければいけない。どっちにしろ、ネットワーク構成に変化があった場合に、この設定ファイルも変更しないといけなくなる。サーバーの提供するサービス毎にこの手のファイルが増えていくと、それだけで、管理が大変になりすぎるんだが。もうちょっとLAN内ホストのグループをうまく管理することは出来ないものか。

LAN内の別マシンにもpgAdminを入れて、BBSの管理者用ユーザーで接続出来るのを確認。BBS用のテーブル定義の追加はこれから。phpのDBアクセス部分をPostgreSQL版にしてデータ移行までするのは、来週になるかな。

最近iBookの調子がいまいちおかしいので、それまでにsvnリポジトリー(svnserver)もLion Serverに移しておかないといけない。Lion Serverには、subversionもプリインストールされている訳だが、こいつも実際に使おうとすると大変…なんてことがないことを願っておこう。

2011/11/04

20:46
作りかけのAndroidアプリは放置して、朝からPostgreSQLの設定を試行錯誤でいじってみる。Lion Serverプリセットの設定をコピーして試してみたのだが、あまり簡単にはならず。極めて特殊な設定である事を再確認。決して、LAN内のホストに対してDB層のサービスを提供するためのものではなく、Lion Server内で稼働しているサービスのためのもの、と考えて間違いないだろう。このインスタンス内にデータベースを追加しても、バージョンアップ時にその内容を引き継いでくれると期待するのは無理そうだ。

今までLion Serverと言うものの立ち位置が全く理解出来ていなかったのだが、中小企業のセキュアなLAN内だけで使うコラボレーションツール用サーバー、と捉えた方が良いだろう。外部公開用のWebサーバーとしてセッティングするだけでも、あれやこれやの追加インストールが必要になるし、それらがGUI画面だけで完了と言う訳にも行かないから、ノンサーバー版のMac OS Xを使う方がかえって簡単だったりする。

そもそもOS Xは、セキュリティーアップデートでさえ、苦労して作った/etc配下の設定ファイルをバックアップも取らずに置き換えてしまうことがあるので、結局プリセット設定のインスタンスを利用する事も、プリセット設定に準じた別インスタンスを作成する事もあきらめた。MacPortsのディレクトリー構成は嫌いなのだが、結局は似たような事をしないとOSのバージョンアップ時にさくっと削除されてしまうかもと言う心配を拭えない。まるっきり同じと言うのもつまらないので、データベースクラスタを置くディレクトリーや、デフォルトのスーパーユーザ、接続用のポートなどはみんな変えてある。

先日の設定変更以来久しぶりに届いたスパムメール、fivestar-results.comとか言うところから。一応自社ドメイン名も取っているようだが、日本の法律上間違いなくスパム認定。あなたのサイトのキーワード検索ランキングを上げますなんてことを書いてある。スパム用にドメイン名取得するなんて奴は少ないだろうが、詐欺サイト用にドメイン名取得する奴は一杯いるからね。こんなスパム営業する会社なんて、怖くてコンタクト取る気にもならないぞ。

メールサーバーのログと言えば、うぱこむサーバー開設直後に困ったちゃんメールを送って来ていた中小企業のメールサーバーが、ちゃんとRFCに準拠した正しい手順でメールを送ってくるようになっている。こういうことをきちんとやってくれるだけで、スパムのフィルタリングがずいぶん楽になるんだが。

2011/11/03

20:46
Lion ServerのPostgreSQLを使いたい。
 ↓
デフォルト設定のセキュリティーが甘いが、設定を変更するとLion Serverのサービスに影響が出る。
 ↓
BBSで使用するためのDBを別インスタンスとして作成しよう。
 ↓
Lion Serverにはinitdbが入っていない。
 ↓
まずはMacPortsをインストール…しようと思ったら出来なかったので、まずはXcodeをインストール。
 ↓
MacPorts版のPostgreSQL9.0.5をインストール、途中Javaもインストール。

…と言うところまでなのであった。

で、「せっかく時間掛けてインストールしたんだから、initdb使ったら終わりじゃなくて、MacPorts版のPostgreSQLプロセスを動かしちゃおう」と思ったのが運の尽き…。

別のpostgresql90-serverなんてパッケージをインストールさせられたあげく、ディレクトリー構成は違うからそれに合わせるためにごそごそ、サービスプロセスのユーザーが「postgres」で固定になっているから、それを変更するためにゴソゴソ、そこをいじったらパーミッションの関係で動かないからまたゴソゴソ、やれshmmaxの値が足りないと言われてゴソゴソ、直して再起動したらshmallの値が足りないと言われてまたゴソゴソ。何とかサービスプロセスが起動したと思ったら、phpPgAdminにログイン出来なくてあれこれ調べ、延々と時間を使ったあげくようやく「システムユーザーじゃなくて、DB内のユーザー情報にパスワードを設定しなきゃいけない」ってのに気付いた…。

と言う訳で、BBS用DBの管理者用と使用者用のユーザーを登録したところで、今日は力尽きた。まだ別サーバーからアクセス出来るようにするための設定はしていない。

で、あれこれいじってる過程で、「サーバー管理」ってアプリを使うと、外部ディスクをホームディレクトリーに持つユーザーがGUI画面から簡単に作成出来る事に気が付いた。本日唯一の収穫と言う感じ。今日は他にやりたいことがあったのだが…。
20:46
サーバーの設定を変えた直後なので、連日人力ログチェック。Webサーバーでの攻撃人気No1は、相変わらずphpMyAdmin。今年もまた新しい脆弱性が発見されたそうだ。外部から見える場所にこんなもの置いておく感覚が理解出来ないのだが、DB対応のレンタルサーバーとかだと、こういうのしかDB管理ツールを提供してくれないんだろうか。
 うちも独自DBを改めて、PostgreSQLにする予定だから(今日はお休みだし、ちょいとその作業をしなくては)、もうちょっと真面目に対策しないとデータがだだ漏れになっちまうかも知れない。気を付けないと。

新手の攻撃としては、"GET /url(data:image/png;base64,〜"なんてのが有った。ネットで検索したら、今年の初め辺りから報告が増えているようだ。ログを見る限りでは、バッファオーバーフローを起こす程の長いものではなかったから、ここでWebサーバーがdata uri対応してて、デコードした画像データを返しちゃったりすると、本格的な攻撃用のデータを送りつけて来る、と言う手はずなのかも知れない。

"GET //web-console/css//〜"なんてのも有った。何かの管理ソフトの脆弱性を狙ったものか。cssを取得出来ただけでは悪さは出来ないと思うんで、これも取得結果を見て本格的な攻撃を仕掛けてくるのだろう。

だだ漏れプロキシ化してないかの偵察攻撃はほぼ日常茶飯事。Webサーバー移転の時に設定をチェックするのを忘れていた。メールサーバー移転の時には、ちょっとした設定ミスでスパムの踏み台にされてしまうので、気を付けないといけない。

2011/11/02

20:46
postfixの設定で、smtpd_helo_restrictionsの中のreject_unknown_hostnameを復活させた。以前、まともなメールサーバーと思われるのにホスト名が逆引きできないメールがまれに有ったので、仕方なしにチェックを外していたもの。ここ最近のログを見る限りは、そう言う困ったサーバーからのメールは見られないので、復活させることにした。

この変更でうぱこむメアドに対するスパムは大幅に減る見込みである。

2011/10/29

20:46
DNSサーバーもwhiteに移転した。OS XもUbuntuも同じbind9だし、設定ファイルをコピペすればすぐに動くかなと思っていたのだが、Ubuntuでは、Debianスタイルのディレクトリ構成を強制するようになっているらしく、OS Xに合わせて作成したディレクトリーに関連ファイルを置いても認識してくれなかった…。

WhiteのDNSサーバーを稼働させたら、ルータのNAT設定の変更、ファイアウォールの変更、LAN内のマシンで直接DNSのIPアドレスを指定しているマシンの設定変更などなど、結構面倒臭かった。この移転であれこれ修正が楽になったから、新しい仮想ホストも定義してみるかな。

2011/07/10

20:46
と言う訳で、png投稿の対応も完了した。こちらはメール投稿プログラムの方は対応が完了していたのだが、php側でも対応が必要なので、放置してあったのだな。

で、なんでphp側が放置なのかと言えば、うちはいまだにphp4を使っているからで。なんとかphp5にグレードアップして、自作DBからSQLiteに変えたいんだが。
20:46
と言う訳で、メール投稿プログラムをUTF-8対応にしてみた。EUC-JPに変換できない文字コードは、全て文字コード参照になるようにしてあるので、ブラウザで表示できる文字なら、Unicodeのコード表にある文字は何でも送れる。

結局libiconvは使いにくかったので、Unicodeコンソーシアムのページからダウンロードしてきたものに手を加えて、変換表を自作した。ちょいと面倒臭かったが、変換時にややこしいことになりそうな文字をどうするかってのを、全部自分で決められるのはやっぱり良いな。iconvも、あるがままで結果を受け入れられるような処理になら使えるんだが。

2011/07/09

20:46
と言う訳で、試しに文字コード参照で両方の文字を書いて見る。
「〜」…こっちは波ダッシュ
「~」…こっちは全角チルダ

ちゃんと区別して表示してるぜ>Safari君。ちゅーことは、Safari君はJISの波ダッシュのコードをUnicodeに変換する時には、全角チルダ(U+FF5E)として扱うっちゅーことですね。いや、別に良いんですよ。両方向の変換で辻褄が合ってれば…。

ちなみに、Mailが勝手に波ダッシュを全角チルダに変えるのは、送信の直前で、どんなに頑張って波ダッシュを入力しても、「送信済み」に移動した時(当然その前のうぱコムサーバー到着時にも)には、全角チルダに変わってしまってました。
20:46
さらにさらにもうちょっと見てみたら、文字コードがEUC-JP(一部のページはS-JISだが)のうちのサイトで表示されている「〜」をSafaiから文字ビューアにドラッグしてみたら、全角チルダになっていた。

うちのサイトは基本EUC-JPだから、間違いなくJISの波ダッシュのコードを送ってるんだが、Safariとかで読み込んだ時に全角チルダに変えちゃってるようだな。んで、それをそのままコピペしてJISで送り直そうとすると、送れないと言う…。

これ、いつぞや仕事でやったシステムでも苦労させられたのだよな。せめて「OS X」の中だけでも辻褄の合う動作にしておいて欲しいぞ。
20:46
今調べ直してみたら、ISO-2022-JPで表現できる(JIS-X0208に規定されている)のは、波ダッシュだけで、全角チルダが現れるのはX0213以降のようだから、ま、全角チルダ入りならISO-2022-JPで送れないのは仕方無いってことにしておこう。

で、その後さらに調べてみたのだが、ことえりが「から」とかで変換する「〜」は、間違いなく波ダッシュなのに、Mailの「件名」欄に入れると、いつのまにか全角チルダの~に変わることがあるみたい。うまく再現できないんだが、何か怪しい仕様だ。
20:46
と言う訳で、Mailから「〜」をタイトルに入れたメールで、テキストエンコーディングを「自動」から「日本語(ISO 2022-JP)」を指定して送信しようとしたら…。

テキストエンコーディングが正しく有りません

メッセージ内の一部の文字を"日本語(ISO 2022-JP)"テキストエンコーディングに変換出来ませんでした。"テキストエンコーディング"メニューから別のエンコーディングを選択して下さい。

なんてダイアログシートが出てきて、送信さえさせてくれなかった…。そういえば、「〜」は全角チルダになるのか、波ダッシュになるのか辺りで変換結果が変わっちまうってのはよくある話だが…。どっちもJISコードに有ることは間違いないんで、変換自体が出来ないなんて話は初めて聞いたぞ。

ついでに言うと、そのまま送信せずに新規メッセージの窓を閉じようとすると、

このメッセージは"下書き"メールボックスに保存出来ません。

添付ファイルのサイズが大きすぎるため、このメッセージは"下書き"メールボックスに保存できません。添付ファイルをいくつか削除してみてください。

なんて言う見当違いのメッセージが出てきて、窓を閉じることさえ出来なくなってしまった。もうちょっとまじめにやれよ>Apple。
20:46
仕方無いので、うぱこむのsmtpサーバー機能を急遽復活させて、nifのメールサーバーを通さず、oopers.comのメールサーバーから送信することにしてみた。引っ越し以来設定ファイルを修正するのが面倒で、全く使われていなかったのだな。

んが、やっぱり、タイトルの文字コードがutf-8になっている。と言うことは、AirのMailが勝手にエンコーディングをutf-8に変えているのか…。そんなはずは無い。一昨日まで、普通にメール投稿出来てた訳だし、この数日でOS Xのバージョンアップも無かったし。
 んで、utf-8でないと表現出来ない文字を入れた訳でも無し…と思ったのだが、もしかして「〜」がまずかったのかも知れない、と思って「〜」の無いタイトルに変えて送信したら…すんなり通ってしまった。恐るべし>OS X Mail。しかし、うぱコムサーバー側のutf-8対応は避け難いな。
20:46
またまた、メール投稿プログラムがうまく動かない。ローカルのデバッグ環境ではうまく書き込めるメールが、本番環境では書き込めないのであった。延々時間をかけてあれこれ試していたら…。なんと、nifのメールサーバーが勝手にメールのヘッダフィールドを書き換えていたのだった…。それってメールサーバーの動作的には、反則でないの…。ま、タイトルをutf-8に変えられたくらいで対処出来ないこっちのプログラムも、今時それで良いのかよなんだが。libiconv使うと、変換出来ない文字の処理が面倒なんだよな…。

2011/05/29

20:46
と言う訳で、BBSへのメール投稿プログラムであるBBSPostのバグ取りをした。なんとquoted-printable(一部の文字を16進表現するだけと言う超簡単エンコーディング)のデコード部分に、人には言えないような超初歩的なミスがあった。(ポインターを2カ所でインクリメントしていたのと、仕様上「=改行」は無視しないといけないのに、それをやっていなかった。)
 今までquoted-printableのメール投稿なんて来なかった(出してるのは殆ど私だけだが)んで、全くテストさえされてこなかったようだ。

ついでながら言うと、サーバー移行の作業、先日ようやくHDDを壊してしまった開発機(コードネームBlue)を復旧し、次期サーバー候補機(コードネームWhite)とともにUbuntu10.04LTSをクリーンインストール、apache2とphp5/SQLite3は入れたものの、その後ぴたりと作業が止まっている。今回のメール投稿は同じサーバーで動いてないと処理がややこしいんで、メールサーバーも移行しないといけないってのに気が付いたので、なかなかやる気にならないってところ。(メールサーバーは設定項目が死ぬほど多くて、apacheでphpのサイトを公開するのとは桁違いの手間がかかる。)

ファイルサーバーに使っているAirMac Extremeもあまりにもパフォーマンスが低い上に、しょっちゅう固まるから、新しくしたいのだが。Snow Leopard Server搭載Mac mini(名前が長すぎだよ)でも買ったら簡単に済むだろうか。


[OOPer's page TOP] [新うぱこむへ]