仕事の話です。
開発が一段落して保守フェーズに入ったので、ずーと以前から頼まれていたものの、嫌な感じがするんで先延ばしにしていた開発フレームワークの Unicode 対応に、とりかかってみたわけですが...

「なんじゃこりゃ～」いやマジで、という感じです。(^^;;;;;;;;

特に、「WAVE DASH 問題」
機種依存文字でもなく、利用頻度も高い「～」を JIS から変換したときに、Windows と、標準 (とされている仕様) で、変換されるコードが違うってのは...

はっきりいって、私は M$ 嫌いです。
M$ のわがままに自分のコードを合わせるのは、可能であれば絶対却下なのですが...これは...これはやむを得ない。仕事でプログラムを書いている以上、この場合は M$ の実装の方を採用するしかありません。無念です...

次に「BOM」
これも扱いに困ります。
入力のときは、まぁ読み捨てればいいのでしょうが、出力するときは付けるの？付けないの？アプリによって、要求バラバラだったり、挙動が変わったりするらしいので最悪です。てか、文字数の数え方とかどうするんだ？

サロゲートペア
まだライブラリの仕様検討段階だけど、どう扱えばいいんだ？ MBCS みたいに、文字単位 vs バイト単位みたいに 2 通りのメソッドを用意するしかないのか？

wchar_t
gcc の wchar_t が、4バイトがデフォって...
かと思えば Apache の Xerces の API は、文字は wchar_t ではなく、2バイト固定みたいだし。
いったい何を信じれば良いんだろう...orz

UTF-7
ってなんすか？使われているの？サポートした方がいいの？
だいたい UTF-xx て大杉

絵文字
携帯の絵文字。機種依存文字扱いなんですね。DoCoMo は、CP932 の外字のマッピングに準拠しているから扱えるけど、au はなんじゃありゃ。あんなにたくさん絵文字って要るのか？使いこなせるのか？
付き合いきれない...まぁうちの会社に携帯の絵文字をサポートする必要がある案件なんかこない気がするから、とりあえずは深く考えないことにしよう。(^^;;;;;;

JISX0213
こいつのシフトJIS は、誰も見向きもしない哀れな仕様なんだけど、94区以降を合法的にEUC にマッピングする唯一の方法ではあるので、今まで自作の漢字変換処理では微妙にサポートしていたりしたんだけど、Unicode のマッピングまで持つのはやりすぎだろうなぁ。やっぱり。

さて、収集つける自信がなくなってきたよ。どうするかなぁ...

同じメールアドレスを長いこと使用していると、宿命としてスパムメールがたくさんきます。今、プライベートで使用している Thanderbirdは、結構良くできたスパムフィルタが標準で付いていて、いい感じなのですが、難点としてはクライアントに搭載されているため、IMAP で普段使っていない環境からアクセスしたときに、鍛えた Thanderbird の方のフィルタが使えないということがあるのと、プロバイダ宛に来たメールを適宜、京ぽんに転送しているんですが、これに最近スパムが混じってしまうのをなんとかしたいというのがあります。(今は、対策として、単に charsetが iso2022-jpなメールを転送している)

この対処のために、去年の夏に職場の環境に導入した bsfilter を、自宅にサーバとして導入することを検討します。

職場のメールアドレスは、もう 8年使用していて、スパムがそんなに多くなかったときに、ML の登録なんかに使用していたのと、とどめに、IANA に SNMP用の企業番号申請するときに使用してしまったので、うんざりするぐらいスパムが来ます。

さすがに、月曜日の朝 100 通を越えるスパムを手で仕分けるのは馬鹿らしいので、導入に踏みきったわけです。

職場では、Mew を使っていて、フロアのメールサーバに POPでアクセスするので、bsfilterは、以下のようなスクリプトから POPProxyとして、SuSE 9.1で動いている個人作業用 PCで実行しています。(Mewの POP接続先を localhostの 10110に設定する)

 /usr/bin/ruby /usr/local/bin/bsfilter --pop --auto-update \
    --insert-flag --insert -probability --pop-server mail \
    --pop-port 110 --pop-proxy-port 10110 \
   > /dev/null < /dev/null 2>&1 &

インストールしたときは、
「bsfilterを mew version 4 から使う」を参考に .emacsと .mew.elとを編集して、

  /usr/bin/ruby /usr/local/bin/bsfilter --add-spam ~/Mail/trash/* 

で、それまでためたスパムを一気に学習させました。

こちらも、最近日本語スパムが増えたとき、一時効率が落ちましたが、今は 90%以上はちゃんと判定してくれているようです。(測定していないので感覚ですが)

自宅の環境は、IMAPなので、これとまったく同じには行かないですが、bsfilter自体は IMAP対応のようなので、なんとかなりそうかなぁと考えているわけです...

日経ITproの記事によると、DNSの再帰問い合わせの問題を突いてDDoSの発射台に使用されるサーバが増えているので対策を、とのこと。

正直に言うと、この話は初耳。
DNSは、NAT内で、内部ドメイン + forward-only なものぐらいしか構築したことないので、情報収集怠り気味だったとはいえ、知らなかったことは、ちょっとショックでした。
ので、外からアクセス可能な DNSサーバはたてたり、管理してないので、今のところ直接は関係ないとはいえ、後学のためにちょっと調べてみることにしました。

まず攻撃の手口についてですが、詳細に書くと、まねする奴が出るからか、Googleで検索しても、なかなか説明が見つからず、結局一次ソースの The Continuing Denial of Service Threat Posed by DNS Recursionを読むしかなさそうでした。orz

で、US-CERTの Summaryをざっと読んだところ、私の理解したところでは「(攻撃者が)いたずら電話(DNS)で他人の家(被害サイト)宛に出前(名前解決要求)を頼む」嫌がらせ...という感じでした。

ので、対策は 外向きDNSサーバを運営するなら、再帰要求を受け付ける IPなどを制限しましょう。ということらしいです。

で対策ですが、私、named.confの「recursion」の設定項目自体が初耳でした。orz

なさけないのでDNSの設定入門みたいなページを検索してみてみたんですが、あまり「recursion」をちゃんと設定の必要性まで含めて説明しているページも少ないようです。(だからなんだといわれると、ただの言い訳なんだけど)

でも、こんな状況ではJPCERTには悪いけど、「namedの方で、allow-recursionを設定しないと、再帰要求を受け付けないようにデフォルトを変更する」ぐらいの劇薬的対処が取られない限り、簡単には設定変更広がらなさそうな予感がします。

＃ rootサーバこけて、トラブル出ると、いらん仕事が増えるという意味では管理者にとってもひとごとではないんだけど orz

しかし、djbdnsのページ見ると、思いっきり警告してますねぇ。
qmailは、お世話になっているんでドキュメントも一通り読んだけど、DNSの方はスルーでした...
やっぱ、せめて主張のとこぐらいは読んどくべきだったかなぁ。orz

CNet Japanの記事によると Sendmailに深刻な脆弱性が発見された模様。
記事では触れられていないが、RedHatNetworkを確認したら、RHEL 2.1, 3, 4についても、「Critical」を冠して Errataが出ていたので、エンタープライズ用途も含めて影響範囲は極めて大きいように思われる。

Redhatの Eratta:
Critical: sendmail security update (v2.1)
Critical: sendmail security update (v3/4)

Solarisでは、9/10が影響ある模様 -- Security Vulnerability in sendmail(1M) 8.12 and 8.13.0 through 8.13.5

＃ 私自身については、仕事で関係しているサイトは、qmailにしてあるのと、このサイトは、Exim4なんで、直接関係ないんだけど。(^^;;;;

クラックの実被害がでる前に多くのサイトがアップデートを済ますことを祈るばかり...

そのエラー情報ファイルは、Webアプリケーションでエラーが発生する度に１ファイル作成されるものなので、あっという間に膨大な量になってしまいます。放置するとディスクを圧迫するので、普段は毎週 tar + gzipでアーカイブしているのですが、今回の解析のために全部展開すると、少なめに見積もって数十万、下手すると百万以上のファイルが復元されてしまうことになりそうです...

行いたい処理自体は特定パターンを含む場合に、そのファイルに記述されている情報をパターンマッチで抽出して１行出力するという Perlの十八番パターンで、特にファイル自体を復元する必要はないため、なんとか直接Perlで tarファイルを処理する方法を探ってみることにします...

困ったときの Google頼みなのですが、検索キーワードがうまく設定できないのか、世の中にそんなことをしようと思う人がいないのか、それらしいページは引っ掛かりません。orz

うーむ。困りました...
※ 実はこのエントリーを書くためにもう一度調べたら、Archive::Tarというモジュールがあるようです。でも、やっぱり今回したいことには微妙にあっていない感じ...orz

・・・tarファイルは、UNIX黎明期からある由緒ある形式なので情報はあるはずですし、今回処理する tarファイルは、深い階層のディレクトリもデバイスファイルもシンボリックリンクすらないシンプルなものなので、自力で作成してもそんなに手間はかからないはずです...

Solarisの tarの manページを良く見ると、 See Alsoに archives(4)というのがあります。参照する、と Cの構造体の定義の形式で tarのヘッダー部分のマッピング定義が書かれています。

あ！これだ。ということで、早速 Perlスクリプトで読むべく unpackのパラメタに落としていきます...

予想通り形式はいたってシンプルで、これなら楽勝かと思ったのですが、一箇所問題がありました。ファイルサイズとしてヘッダに格納されている文字列と実際の値が異なっているのです。たぶん、なにかのルールがあるはずなのですが、今ひとつ正解が見つかりません... orz
困っていろいろな tarファイルをダンプして見比べているとサイズが 64バイトのファイルに 100が設定されているのを見つけました。
で、わかりました。 -- 8進数 orz

そういえば、古い UNIX文化は 8進数の方がお好みでした。そうでした。

まぁともかく、カラクリがわかれば簡単です。時間もないので、簡単に作ります...

tarの中身は特定のフォーマットを持つテキストファイルで、それを連続で処理できれば良いので、ヘッダを読んだら識別用のパターンをつけてファイル名を出力し、後はサイズ分内容を読んでひたすら出力するようにし、実際の解析処理は別スクリプトにしてパイプで繋ぐことにします...

gzip展開のために、前処理で gzcatをしてもそこそこの時間で処理できるようです。ふぅ

＃ スクリプトは追記に書いています....

昨日の続きで、Sun Studioの話...
業務で使うかどうかは微妙なんだけど、せっかくなんで IDEを起動してみることにします。(^^;;;;

% sunstudio
Assertion failed: offset < fFileSize, file ../../../src/share/native/sun/awt/font/fontmanager/fontobjects/fontObject.cpp, line 418
/opt/SUNWspro/bin/sunstudio: line 1: 1804 Abort (core dumped)
-- 以下略 --

あれ？
なんか昔も見たような嫌なエラーが出ます。orz
Googleで検索したけど、特定の状況ででる訳ではないようで、手がかりなしです。

フォント関係のエラーだとすると DISPLAYが linuxなのがいかんのかなぁ...とか考えます。うぅ

設定してないので、VGA(640x480)でしか上がらない VMWareのコンソールだけど、エラーの原因切り分けぐらいは出来るだろうと思い、 Xをあげて確認してみます。

/etc/init.d/dtlogin start

CDEからログインしてやってみます...
微妙に違うエラーの気もするけど基本的に変わり無し...orz

・・・いっそ、開発マシンの Sunの生コンソールからやってみるか・・・

誘惑が頭をよぎるけど、今のところ業務は直接関係ないのでちょっと憚られます。(^^;;;;
VGAだと、画面が小さすぎてエラーになるのかとも思い、代わりにVNCでつないで起動してみたりもしたけど NGでした。 orz

だいぶん煮詰まってきて、/opt/SUNWspro/bin/sunstudioを、lessで見て Hackしてみたりもしたけどいまいちヒントがありません。
Javaのバージョンに問題があるのかなぁと思い(SunStudio同梱の JDKのはずなんだけどねぇ)インストール時に使用した最新版を --jdkhomeで指定してみます。が、うまく認識しません...orz
/opt/SUNWspro/prod/jdk_chooserとかも Hackしたりしながら、原因を考えます。

うまく認識できない方の原因はJDKではなく JREをインストールしていたからだとわかりました。(恥)
＃ jdk_chooserが javacがあることをチェックしていたんで、JREでは認識されなかった。

それならと、JDK1.4.2_10を落としてみます...が、エラーが出ることは変わらない...orz

これでだめなら、もう止めと最後に jdk1.5.0_06を落として試してみます...

% sunstudio --jdkhome /usr/jdk/jdk1.5.0_06 &

お、なんか起動中のダイアログが出ます。あ、IDEらしきウィンドウが表示されました。
やた。(^^)v

結局、起動にさせるのに3時間もかかってしまいました。まぁ、うまくいかなかった本当の原因は不明なんで、私の環境だけかもしれませんが。むぅ。

疲れたので、続きは後日...にしようかとも思ったけど、気分が良くなったのでもう少し続けます。(^^;;;;;

とりあえず、昨日コマンドラインからコンパイルしたアレを IDEから開いてみることにします。
ファイルメニューから...あれ？...既存の環境をインポートできそうなメニューがありません？ Welcomeを見ると、チュートリアルがあるので少し眺めてみます...書かれた手順を順番にやると、基本的な作業をざっとできるようなチュートリアルを期待したのですが、単に概要説明のようです...orz

仕方ないので、流し読みします。
・・・「ファイル」にある「ファイルシステムのマウント」というのが、既存の環境を開くメニューのようです。
なんで、IDEから ファイルシステムのマウントができる必要があるんだとは思ったんですが、まさかそういう機能のことを示しているとは思いませんでした。てか、誰もそんな機能だと思わないと思うけど。> Sun

さて、開けたのはいいんですが、私自身は emacsから、M-x compile, M-x gdbで十分快適だと思うひとなので、ここからなにを評価するべきかがイマイチぴんと来ません。 (^^;;
とりあえず、外部エディタとして、最初から XEmacsと GVimが入っているみたいなので、エディタを変えて開いてみたりします。

XEmacsは、専用の ELispも入っているようで、専用メニューがあって、ちゃんと IDEと連携できるようです。(ちょっと関心)

構築とかデバッガ関係は、また後日、気が向いたときにということで、今日はこの辺で引き上げます...ふぅ

今回も、仕事としてやった話。

うちの職場では業務で Sunのアプリケーションを開発するときは、Sunの純正コンパイラである Forte 6(Workshopコンパイラ)を使用していたのですが、Sun Studio11が無料になったのを機会に、ずっと滞っていたアップグレードを試みることになりました。(^^;;;;;

で、そのときの記録です。

まず SunのサイトからSun Studio11のアーカイブをダウンロードします。(Sunのダウンロード用のアカウントが必要)

実際に業務で使うのは SPARC用なのですが、最初の確認作業は例によって VMWare上に入れた x86用の Solaris9で行ないたいので、x86版もダウンロードします。

SPARC版のサイズは 600MB強, x86版も 300MB以上あるので、会社の回線を使用して日中からやるのもどうかと思ったのですが、上司の GOが出たのでやってしまいます。(^^;;;;;;;;;;;;

アーカイブのダウンロードが済んだら展開します。ついでにドキュメントも落として、PDF版のインストールガイドを見ながら作業を開始します。

とりあえず、適当に ./installerをやってみたら、エラーになりました。orz

仕方ないので、インストールガイドを読むと J2SE 1.4.2_08, J2SE 5.0 Update 3以降が必要なようです。
javaのダウンロードページで、最新の J2SE 5.0 Update 6と OSパッチをダウンロードしてインストールします...

終わったら、気を取り直して ./installerを実行します。今度は GUIのインストーラが起動しまうす。OK。
進めていくと、Javaの開発環境もインストールされるようです。(Sun Studioだから当然かもしれないけど)

でも、それなら「わざわざ準備で Java環境のアップグレードさせるなぁ～」といいたいです。(^^;;;

この辺が Sunの(ry
＃ まぁ、それ以上の問題はなくインストールは終了したので、それ以上は追求せずに次へ進みます。(^^;;;;;;;;;;;;

とりあえず、仕事なので給料分の義理を果たすべく、仕事で書いたプログラムを Sun Studio 11でコンパイルしてみます。

まず、configure...
./configure --with-sunws=/opt/SUNWspro

サポートしていないバージョンだといわれてしまいます。
修正しないといけないけど、ちゃんとバージョンチェックしてたんでちょっと関心... (^^;;;;;

Oracle Instant Clientに引き続き、また configure.inを修正します。

バージョンチェック部分の修正のために、Sun Studio11の ccはどんなバージョンを返すのかを cc -Vで確認します。

cc: Sun C 5.8 2005/10/13

ん？ 5.8？ なんで 5.8なんだ？
長く使ってなかった間にバージョンの付与規則も変ったみたいです...

まぁ、経緯は分からないけど、「Sun C 5.8」だというのなら、それを Sun Studio11とみなすことにします。

で、修正して、autoconfして、再度 configure, 終わったら makeしてみます。
例によって、Oracleが無いのでエラーになるけど、それ以外はうまくいくみたいです。

せっかくの Sun Studioなのに、IDEを起動する前に終電になりそうです。(^^;;;;;;;
続きはまた後日...

職場での話。
以前書いたプログラム(最初に書いたのは 8年ぐらい前)が、RedHat Linux ES4だとエラーになると、同僚にいわれたので、メッセージを確認すると、「too few template-parameter-lists」みたいなエラーが出ている。

他の環境では通っているし、テンプレートのパラメタリストは間違っていないと思うし...
おかしいなぁ。コンパイラが gcc(g++) 3.4.2と新しいから、そのせいかなぁ？

ちょっと腰をすえて調べないと分からなさそうなので、自分の作業用PCの VMWareに 、同じRedHat ES4をインストールしてやってみる...

当然だが、同じエラーが出るので、メッセージをGoogleで調べると、gccの Bugzillaが引っ掛かる。

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17445

おいおいコンパイラのバグかよ。と思って状況の方を確認すると...「Resolution: INVALID」

へ？仕様？仕様なの？特に変な書き方はしていないと思うけど...ダメなんですか？

疑問が増したので、Bugzillaにある議論を読むと、なんか、頭に「template <>」を付けないとだめらしい。
ダメな理由がよく分からないので、ARMとかプログラミング言語 C++のテンプレートのとこを読み直してみる。
でも、やっぱりよく分からない。いまいち納得できないけど、確かにそう変更すればエラーにならないし、古い gcc2.8.1でもエラーにならないから、Bugzillaにあるように修正していく。
＃ C++のテンプレートは便利なんだけど、仕様が複雑怪奇すぎる...

そうこうしながらコンパイル時のエラーは大体やっつけたものの、最終的には Oracleのライブラリがないとアプリ全体のコンパイルは完了しない。
でも、とりあえず確認のために作った環境に Oracleクライアントのインストールをするのも面倒なので、以前から気になっていた、Oracle InstantClientを試しに入れてみることにする。

まずはOTNのOracle Instant Clientのページからダウンロードする。(OTNのアカウントが必要)

ダウンロードしたZIPを展開して、出来たディレクトリを見てみると、いきなり共有ライブラリファイルがころがっている。

ん？あれ？・・・インストーラーは？ドキュメントは？普通あるべきファイルが見当たらない？

もう一回ダウンロードしたページに戻って探してみると、アーカイブを展開したらインストールしなくても動かせるって書いてある。
・・・動かせるっていったって、tnsnames.oraぐらいは書かないとダメだと思うんだけど、何処に置くんだ？

疑問が増したので、さらにドキュメントを探すと、セットアップガイドという PDFがあったので読んでみる。
・・・「@」の後ろに直接「ホスト名:ポート/サービス名」と書けば tnsnames.oraは不要です。

ふーむ・・・でも、そういえば、逆に最初に Oracle使ったときは、何でいちいち tnsnames.oraにサーバを定義しなければならないんだろ、面倒だなぁと思ったなぁ、慣れというのは恐ろしい... (^^;;;;;;;;;;;

確かにインストール作業が不要なのは楽かもしれないが、これまで書いたアプリの Makefileは、ORACLE_HOMEの場所だけが可変で、その下の構成は固定であることを前提にしていたため、その前提に沿っていない InstantClientの SDKは、 Makefileも直さないと使えない。
結構面倒だが、InstantClientは今後使うこともあるだろうから、この際、ちゃんとconfigure.inから直していくことにする...
なんかトータルでは、結局普通にクライアントインストールした方が早かったかなぁというぐらいの時間がかかってしまったが、まぁ経験値は稼げたから良しとしよう。(^^;;