ある日ソフトエラーを目の当たりにする

アプリケーションの計算結果のテストのためにDBで大量の検索、挿入、更新、そして照合用も含めてファイルも大量に新規作成、削除、読み込みを何日も連続で繰り返さなければならないことがあります。連続で読み続けたり書き出し続けたりするのでディスクキャッシュを数百メガバイトに設定したところで効く由もなく、連続稼動用を謳っているハードディスクを3,4台のストライピングで使用しても負荷が激しすぎで3,4週間程度でお亡くなりになるのでどんだけひどい仕打ちをしてるんだろうと思ってしまいます。古いflash SSDだったら即死するかもしれません。ハードディスク交換していてはエコじゃないので使用量を減らすとすると、DBのデータを最初にRAMディスクにコピーし、一時ファイルもRAMディスク上というのが良さげですが、いっそOSごとDRAMのRAMディスクにして物理ディスクレスにしてしまおう、ということで1年ほど前にRAMディスク化しました。

マニュアルとOEM元Q&Aは良い(しかしどちらも日本語訳はすごすぎ)のですが、なぜかそれらと輸入代理店のFAQがいい感じに違っている某商品、DDR2メモリを積めるものです。1年たった今になって、実はunbuffered ECC対応、さらにunbuffered non-ECCでもジャンパーを刺せば容量の1/9使ってをECCエミュレーションをしてくれる(ハミング符号だとすると比率から64ビットバス+8冗長ビットのエミュレーションですね)という結構優秀な機能を持っていることがわかりました(輸入代理店はECC非サポートと明記している)。コストパフォーマンスからはunbuffered non-ECCのメモリを使ってECCエミュレーションするのが一番良さそうです。

しかしインストール時はそんなことには気づいてなかったのでnon-ECCメモリでECCエミュレーションも使わずに1年近くたった先日、その日はきました。演算結果の検証エラー。

正解 検証対象
.19;5 .1995

正解は数値であるはずだったので、すぐに正解の方がおかしいことに気づくことができるのが不幸中の幸いです。別途ハードディスク上に圧縮して保管されている検証用データと比較すると、検証対象の値で正しいことがわかりました。面白いのでこのファイルの文字セットUS-ASCIIでのコードポイントを調べてみます。

9 ;
hex 3 9 3 b
bin 0011 1001 0011 1011

その他の1GB程度の正解ファイルの検証、さらにOSとports部分はTripwireしているので検証したところ違いは検出されず()、RAMディスク起動時のデータも同様、そしてその後このようなエラーも起きずにいるのでソフトエラーということで間違いないようです。ビット反転によく見える形で遭遇してしまいました。機材近辺でのノイズであればエラーが頻発してもおかしくないような気がするので日常の宇宙線か、太陽フレアか、などと空のかなたに思いをはせていたところ、こんな記事がありました。

Google: Computer memory flakier than expected (邦訳 – なぜか思い入れがえらく強いタイトルになってます…)

周辺の状況などもあるでしょうから場所、そして何の作業をしているところか、などの条件をどうしているのかちょっとわかりませんが、温度なんかどーっちゅうこともない、ハードエラーの方がソフトエラーよりcommonである(ECC前提での話?)、など面白いです。温度が経年変化に与える影響なんかも調べられてるんでしょうか。時間ができたら元の論文読むべしです。

さらに温度といえばグーグルの最新のデータセンターは非常識なほど進化しているだそうで、自宅サーバなんて昔から室温50度超えになっちゃうようなところで並んで動いていたわけで進化なのかどうかは置いておくとして、かつて大学のコンピュータがある場所では壁一面にウルトラマンに出てくるような巨大なテープが回ってる箱が並んでいてエアコンがガンガンに効いている、なんてのはいったい何の話?ってなもんですね。

何よりも実感したのは、サーバだけじゃなくてテスト機にもECC使わないとだめじゃん、ということです。考えれば当たり前な話ですが、それを言い始めるとnon-ECCで良い仕事ってあるんだろうか…

追記: bitsquatting面白い!

ClamAV 0.96.2 on FreeBSD 7.1

ClamAV 0.96.2のソケットがFreeBSD 7.1でchokeする問題

ありがたいことに既にports tree更新されてる(PORTREVISION=2なので0.96.2_2以降)ので、

したら

とか

で解決ですね。ありがたやありがたや。

server does not support RFC 5746, see CVE-2009-3555 (was: potentially vulnerable to CVE-2009-3555) Apache HTTPD + OpenSSLでRFC5746リネゴシエーション対応

CVE-2011-0411 Plaintext command injection in STARTTLSはこちら


Bug 549641の変更をここのタイトルにも入れてみました(2010/9/14) 。元々「潜在的に脆弱」という微妙なメッセージから書き起こしたエントリなので、文章のつながりが悪くなったかもしれません。


CVE-2009-3555はDescriptionによればSSL3.0(とおそらくそれより前)とTLSプロトコルにおいて、”renegotioation”でMITM攻撃者がデータを挿入可能である、というものになり、去年の11月に業界(?)を震撼(?)させたものです。

この問題を解決するべくIETFのTLSな方たちは世のため他人のため、ものすごい勢いで”secure renegotiation”(安全な再ネゴシエーション)を定義して本年2月までにRFC5746にしてくれました。

表題のメッセージはFirefoxがhttps://なサイトにアクセスした場合や、ThunderbirdがSSL,TLSでPOP3, IMAP4, SMTPアクセスした場合などなどでエラーコンソールにログされるものですが、mozilla wiki Security:Renegotiationを超訳すると、「まだ問題があるwebサーバだらけで、今よく見えるように警告してしまうとそれを無視しましょうとのたまう人が出てきて、ユーザは似たような警告も含めて無視する習慣が付いてしまうだけで世の中が幸せにならない。だから潜在的に問題のあるサーバはそっとエラーコンソールにログするだけ」とのことです。実際にはRFC5746を実装していないwebサーバとのTLS/SSL使用時に表示されるので、webサーバ側にrenegotiationを全て無効にする形でのパッチが適用されている場合、webサーバとしてはCVE-2009-3555に対して脆弱でなくでもそれを通信中のフラグ(RFC5746対応している場合にはServerHelloのextentionのrenegotiation_infoが付いてくる)では検知できないのでFirefoxのエラーコンソールに表題のメッセージがログされます。

表題のメッセージを消す==webサーバをRFC5746のsecure renegotiationに対応させるためにすることをざっくり書くと、OpenSSLとApache HTTPD(mod_ssl)2.2系列の場合、

  • 対象のwebサーバにhttps://で接続してFirefoxのエラーコンソールに表題のログが表示されることを確認。
  • 先にOpenSSLを0.9.8m以降にアップデート。(2014/4/8現在1.0.1g以降をお勧め)
  • 次にApache HTTPD 2.2系列の場合2.2.15以降(2010/9/14現在2.2.16以降をお勧め)にアップデートかリビルド。
  • 再度https://で接続してFirefoxのエラーコンソールに表題のログが表示されなくなったことを確認。

となります。(悲しいことにrenegotiationしないと続行できない状況の場合、いまだRFC5746非対応であるIE(←末尾に追記)RFC5746非対応ブラウザなどで問題になり、わざわざmod_sslにSSLInsecureRenegotiationディレクティブを使用して古いrenegotiationを有効にせざるをえなくて困っているサーバ管理者の方も多いです)

その他にもご自分のwebサーバがインターネット上にあればQualys SSL LabsのSSL Server Testにて、SSL,TLS全般の確認ができます(表示されているように、別のURLで流れさるまでの何時間かURLと結果がさらされます(その後指定すればさらされないようになりました)。さらに上位と下位は別枠で表示してくれます)。結果のMiscellaneousのRenegotiationの項に、安全なのか古いリネゴが使えてしまう状態か、などが表示されます。

クライアントのRFC5746対応も必要ですが、表題のログがエラーコンソールに出ている時点で当然古いrenegotiationを問題視しているwebブラウザを使用していることになるのでここでは考えないことにします。webブラウザのRFC5746対応はmozilla wiki Security:Renegotiationに書かれているようにhttps://ssltls.de/で確認できます(←末尾にちょっと追記)。有るべき姿はwebブラウザ、webサーバに限らず、「SSL,TLSを用いた全てのクライアントとサーバがRFC5746に対応していること」になります。

ではwebサーバとしてはCVE-2009-3555に対して脆弱でなくてもログされる場合(薦められた状態ではないですが)はというと…

例えばOpenSSLのChangeLogを見ると、

となっていて、またFreeBSD Security Advisories2009/12/3 FreeBSD-SA-09:15.sslでは

となっています。ソースレポジトリを見ると2010/6/15現在-CURRENTとRELENG_8(-STABLE), RELENG_8_1がOpenSSL 0.9.8nであり、他は OpenSSL 0.9.8eとかkとか + SA-09:15 ということになるようです。

さらにApache HTTPD 2.2.15のChangeLogでは、

となっているので、Apache HTTPD(mod_ssl) 2.2.15以降の2.2系列をOpenSSL 0.9.8m以降のライブラリでコンパイル、リンクすることでRFC5746のsecure renegotiation対応になります。

Apache HTTPDにSSLInsecureRenegotiation指定をしない前提でまとめていくと2010/6/15現在


FreeBSD 8.1(現在ベータ1,7月リリース予定)のOpenSSLは0.9.8nなのでRFC5746対応。したがってCVE-2009-3555に対しては脆弱ではない。


FreeBSD 8.0, 7.3, 7.1各セキュリティブランチを最新の状態にしている人のOpenSSLは0.9.8? + SA-09:15なのでRFC5746は対応していないが、renegotiationを全部無効にすることでCVE-2009-3555に対しては脆弱ではない。


OpenSSL 0.9.8l
あるいはFreeBSD 8.0, 7.3, 7.1各セキュリティブランチのOpenSSL(0.9.8? + SA-09:15)
 + Apache HTTPD(mod_ssl) 2.2系列全部
の場合は

  • 表題のエラーコンソールログは表示される(RFC5746非対応)
  • CVE-2009-3555についてwebサーバは脆弱ではない(ただしrenegotiationがすべて無効)

OpenSSL 0.9.8m以降(2010/6/15現在OpenSSL 1.0.0a以降をお勧めします)
 + Apache HTTPD(mod_ssl) 2.2.15以降の2.2系列
の場合は

     

  • 表題のエラーコンソールログは表示されない(RFC5746対応)
  • CVE-2009-3555についてwebサーバは脆弱ではない(RFC5746対応)

要注意なのは、Apache HTTPD 2.2.15にしただけで安心してしまう次のパターンでしょうか。現実的にMITM攻撃が成立するかは考えずにChangeLogからだけ言うとするとCVE-2009-3555に対してwebサーバは脆弱です。
OpenSSL 0.9.8k以下(FreeBSDの場合は0.9.8k以下かつSA-09:15のアップデートがされていない場合)
 + Apache HTTPD 2.2.15以降の2.2系列、
    あるいは2.2.14 + http://www.apache.org/dist/httpd/patches/apply_to_2.2.14/CVE-2009-3555-2.2.patch
の場合は、

     

  • 表題のエラーコンソールログは当然表示される(RFC5746非対応)
  • CVE-2009-3555に対しては * 脆弱である *
          (クライアントがinitiateした場合のrenegotiationを拒否しているだけ)

まずサーバ側の古いrenegotiationの実装が一掃され(同時にメジャーwebブラウザが全部RFC5746対応するという壁も大きいようで)、そしてRFC5746実装が使用され、renegotiationの一部や全部を無効にしただけのパッチがおおよそ一掃されて、それからようやく表題のエラーコンソールのログが派手な警告なりエラーなりに格上げされることになると思われますが、まだまだかかりそうですね…
例:https://bugzilla.mozilla.org/show_bug.cgi?id=555952

FreeBSD 8.0, 7.3, 7.1 + Apache HTTPD(mod_ssl)で表題のエラーコンソールログが出なくなるようにする、つまりRFC5746対応にするには、2010/6/15現在SA-09:15ではOpenSSLのrenegotiationを全部無効にしているためApache HTTPD(mod_ssl)を2.2.15にするだけでは不十分であり、こどもの日にportsがOpenSSL 0.9.8mに対応された(2010/6/15現在1.0.0a対応)ので、これを使うのが早そうです。

最後の表示では、特に/usr/lib/や/lib/ではなくて、/usr/local/lib/libssl.so.*, /usr/local/lib/libcrypto.so.*であることを確認する必要があります。

あらかじめFirefoxでhttps://接続してエラーコンソールに表題のものがログされていることを確認した後、アップデート作業後にログされなくなればRFC5746対応完了です。


Windows関連ちょっとだけ追記(2010/9/14)。 2010年8月の月例(日本だと8/11あたり)のアップデート群に含まれていたKB980436: MS10-049: Vulnerabilities in SChannel could allow remote code executionによってWindowsのTLS/SSLスタックがRFC5746対応されましたが、それが使われるWindows XPのIEで https://ssltls.de/ のペンギンさんが表示されないのを確認しようとしてたこともあって時間がとれずに一月経ってしまいました。どうやらmod_nssを使った環境を作らないとちゃんと確認できなそうなので、先ほどざっと確認した現象だけ列挙しておきます。

  1. Opera,Firefoxは結構前からペンギンさんが表示される。
  2. KB980436が適用されたWindows Vistaではペンギンさんは表示される。
  3. KB980436が適用されていてもWindows XP, 2003ではIEのバージョンによらず、ClientHelloのextentionでもSCSVでもペンギンさんは表示されない。
  4. Windows XP(IE)のClientHelloのextentionにはtype 0xFF01(renegotiation_info)しかないが、Vista(IE)やOperaはそれに加えてserver_nameやstatus_requestなどがある。
  5. HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL にUseScsvForTlsという名前のDWORD値を作成して1をセットすると、Windows XP(IE)ではClientHelloのextentionが無くなる。Firefoxはserver_nameやstatus_requestなどがある。どちらもrenegotiatoin_infoは無く、cipher suiteに0x00FFが追加されている(SCSV)。

次はmod_nss環境を作成してnssのデバッグログを吐かせるところからになりますが、誰かとっくのとうに解決していたら教えてくださいませ。

なおWindows(IE,IISなど)で古いリネゴを拒否する方法はKB980436に書かれています。レジストリをいじって

で再起動すればサーバ(IISなど)が、そして

で再起動すればクライアント(IEなど)が古いリネゴを拒否するようになります(いろいろ使えなくなるものが出るようなので、まだ不便かもしれません)。

その他の参考リンク

** Port directory not found: math/libgmp4 からの~ ** Command failed [exit code 1]: /usr/bin/script -qa

/usr/ports/UPDATINGによるとportmaster使ってる人は

で更新、とのこと。portupgradeで許してと、

すると(as of 2010/5/10)、

あいたた。-oの時のconflictのチェックをするタイミングがおかしいような。原因を追究しなければいけないところですが、レポートはどんどんあがりそうだと言い訳をしてその場をしのぐべくUPDATINGに言われたとおりにportmaster使います。その前に念のためlibgmpに依存しているものを確認。

出てくるパッケージをメモ、

もしもメモしたパッケージがアップデートされない場合は

で解決。

全然関係ないですがLLVM全盛の世の中GCCのメッセージを眺めていて、一晩かけてSONYのNEWSでコンパイラをコンパイルしているところを眺めていた十数年前など思い出しつつ、GCCともお別れの季節が近づきつづあるようです。

http://llvm.org/demo/ VM自体はホストの時代に戻ってる気がしますが、CGIでコンパイルとか今風で最高に面白いデモです。

ActionScript3.0のDataGridでCheckboxを使いたい [AS3] – Checkbox CellRendererを作る

Using a CheckBox in a DataGrid in ActionScript 3.0 [AS3](⇐ In English)

ビジネスアプリケーションにとってデータの操作は基本中の基本。だから、GUIコンポーネントを提供する言語だったら、データをリスト表示したり並べ替えたりする機能やコンポーネントがある、と想定してもおかしくありません。ActionScript3.0にもあります。

今回はActionScript3.0で、そのリスト表示の中にチェックボックスを表示する方法について、Adobe社のオンラインドキュメントに掲載されているサンプルに追加機能を加えながら解説します。これができると、例えば社員教育の受講管理で、リスト上で受講ステータスチェックボックスにチェックを入れればその人を受講済みにできたり、複数のレコードを選択して処理する場合に、処理チェックボックスにチェックが入っている行だけ処理をする、などということができます。もちろんコントロールキーを押しながらクリックして複数選択する、という手もありますが、「これってユーザに優しくないよね」と常日頃思っている人には、チェックボックスのほうが良いかもしれません。

データのリスト表示や操作をするコンポーネントは一般的に、データ部分を提供するものと、そのデータの表示の仕方を指定して操作するものとに分ける、というパターンを使って作られていますが、ActionScript3.0もそのパターンで、データをグリッド(grid)表示するDataGrid、そのDataGridにデータを提供(provide)するのがDataProvider、そして、DataGridのそれぞれの列やセルの表示/描画の仕方を指示する(render)のがCellRenderer、という組み合わせになっています。デフォルトではデータをテキスト表示をするCellRendererが提供されています。

このDataGridのひとつの列をCheckboxにするには、fl.controls.CheckBoxクラスを拡張してfl.controls.listClasses.ICellRendererインターフェイスを実装した新しいクラスを定義し、チェックボックスにしたい列のcellRendererプロパティに、そのクラスを指定します。詳細なやり方はActionScript3.0のマニュアル「カスタムCellRendererクラスの定義」の「ICellRendererインターフェイスを実装するクラスを使用してカスタムCellRendererを定義するには」のセクションに記載されています。しかし、このページに掲載されているサンプルは動かすとエラーになるので、その代わりに、「DataGridCellEditorのオンラインマニュアルの(なぜか)コメント欄に記載されているコード例が一番参考になるでしょう。CellRendererを作成するのが初めてのかたは、まずはこのコード例を、そのまま試してみることをおすすめします。

このコード例ではDataGridの選択状況がチェックボックスと連動する作りになっています。今回、著者はチェックボックスが独立して機能するようにしたかったので、この記事ではこのコード例をベースに、その変更点について解説します。

では変更点を見ていきましょう。まずはfunction set selected()です。Adobe社のコード例では、ここでチェックボックスの選択状況をセットしていますが、このメソッドは、DataGridの行が選択された際に呼び出されます。一番最初にDataGridを表示した時点では、このメソッドは呼び出されないので、セルの値がチェックボックスにチェックに反映されず、チェックボックスは常にチェックが入っていない状態で表示されます。セルをクリックして初めてセルの値がチェックボックスに反映されます。また、ここでチェックボックスの選択状況をセットすると、DataGridの選択状況とチェックボックスの選択状況を連動させることになるため、ショッピングカートや冒頭で例示したような「社員教育受講管理」など、チェックボックスが単独で機能しないといけない場合に対応できません。DataGridの行を選択したらチェックが入るのではなく、チェックボックスをクリックしたらチェックが入ったりはずれたりして欲しいのです。なので、このロジックは後述のfunction set listData()とtoggleSelected()で実装します。ただし_rowSelected属性をセットしている部分は、DataGridを選択した際に表示色などを変えるときに使うので、残しておきます。

次にtoggleSelected()ですが、Adobe社のコード例では”don’t set selected or dispatch change event.” (selected属性に値をセットしたり、CHANGEイベントを送出しないように)と書いてありますが、上記のset selected()で記述した理由で、selected属性はここでセットします。

これで、DataGridの選択状況とは関係なく、チェックボックスをクリックすれば正しい値がセットされる、チェックボックスらしい動きになります。もう一つやりたかったのは、DataGridを最初に表示したときにセルのBooleanの状況を正しくチェックボックスに反映することです。それがもう一箇所の変更点set listData()になります。set listData()は、DataProviderがDataGridにセットされるタイミングと、DataGridで何か変更が起きるタイミングの2箇所で呼び出されます(DataGrid.selectable=trueのとき)。その前者のタイミングを利用したいので、上記のset selected()で実装するはずだったロジックをこちらに移動するわけです。

これでDataGridの初期値がDataProviderのデータで埋まったときに、チェックボックスがセルの値を正しく表すようになります。

上記の変更を加えたCellRendererをDataGridのカラムにセットすれば、”true”や”false”という文字列の代わりにチェックボックスが表示されるようになります。このままでも使えますが、もしDataGridのListEvent.ITEM_CLICKイベントを拾って処理をするアプリケーションに使う場合は、最後にもう一工夫必要です。それはチェックボックスのCLICKイベントがListEvent.ITEM_CLICKEDに変換されるのを止めることです。なぜなら、今回実装しようとしている、DataGridとは連動せず単独に動作するチェックボックスの場合、チェックボックスをクリックするという行為の目的は、チェックボックスの値を変えることであり、DataGridの行を選択する、という目的ではないからです。

これでOKです。

ところで、どこかのフォーラムの書き込みで、Adobe社のサンプルを見て「こんなに長いコードを書かないといけないの?!」と驚いている人を見かけました。確かにぱっと見ただけですと、ただチェックボックスを表示したいだけのわりには長く見えるかもしれませんが、要点はこの記事に書いた点だけで、他の6~7割のコードは全て表示スタイルに関するものです。まずは表示スタイルは何もいじらずそのままにして使ってみると、見た目ほど複雑ではないことに気が付かれると思います。

なお、このコードは著者がアプリケーション開発の過程で試行錯誤の結果導き出した一つの手法であり、皆様の参考用に掲載しているものです。ご
利用の条件につきましては、「サイトのご利用条件」をご一読ください。また、このコードは弊社が開発しているアプリケーションで実際に使われています。したがいまして、今後改善やバグ修正がされる可能性がありますが、変更が入りましたら随時この記事を更新します。

LimeSurveyをインストール

オープンソースのアンケートシステム、LimeSurveyをFreeBSDにインストールしました。いつもの「実験君」です。データベースにはPostgreSQLを使います。

まだ使い始めたばかりなので、LimeSurvey自体についての感想や応用方法については後日に取っておきます。今回は現時点でマニュアルには載っていなかったインストールに関する情報を補足します。なお、この情報はLimeSurveyのForumにも投稿し、投稿後に気づいたこともこのブログとForumの両方に追記するようにしていますが、こちらのブログの内容が最新情報になります。

FreeBSD&PHP5.2&PostgreSQLという組み合わせでLimeSurveyを導入するには、以下の3つのPHPのextensionが必要になります。

  • PGSQL

これを入れないと、データベースに接続できず、インストールスクリプト(/limesurvey/admin/install)を実行した直後に”Database connection failed”というエラーメッセージがブラウザ上に表示されます。

  • SPL

これを入れないと、インストールスクリプト(/limesurvey/admin/install)を実行した直後に”ArrayObject not found”というエラーメッセージがブラウザ上に表示されます。SettingsStorageというクラスがArrayObjectを継承して定義されているからです。

  • CTYPE

これを入れないと、新しいアンケート(survey)を保存する際に、”Fatal error: Call to undefined function ctype_alnum()”というエラーメッセージがブラウザ上に表示されます。

他はマニュアル通りで問題なく動き始めたのでかなり幸先が良く、フォーラムも活発で、UIや機能も大分頑張って作った感がにじみ出ているので、かなり期待しています。

使用感や応用についてはまた後日ご報告します。

/limesurvey/admin/install

プログラムを作るプログラムを作れ – プログラムを自動生成せよ

2013/8/9 追記: 右脳左脳うそ説プラナリアの記憶の場所など興味深い話がある中で、右脳プログラミング環境だそうです。どうなっていくでしょう。


何の文脈も無く「プログラムを作るプログラムを作れ」と言われた場合、まずそれを言われた方のITスキルやバックグラウンドを知らないと延々と禅問答が続いてしまいそうです。プログラムとはコンピュータへの命令のことなので、それを作るプログラムとなるとコンピュータへの命令を作るコンピュータへの命令を作ることになりますね。最初から直接命令すればよいじゃん、となってしまいます。

各種言語のコンパイラはプログラムを出力するプログラムですし、古くからあるlexとyaccあたりで新しく構文を解釈してプログラムを出力するプログラムを作れば、lexとyaccはプログラムを作るプログラムを作るプログラムでしょうか。

program to create programなどのフレーズでいろいろ検索してみます。Visual Basicのようにコンポーネントをたくさん準備しておきそれらを配置、接続していくもの、イベントに対するアクションもあらかじめ複数準備し、視覚をベースにプログラミングするものがまず目に付きます。準備しなければいけないものは無数ですが、多くの作成者を満足できるレベルになれば便利です。あとは各種言語用のエディタも出てきます。確かにプログラムを組むため(ソースコードを書くため)のプログラムです。そして決められた形式の設計書に基づいて各種言語のソースコードを自動生成と称して出力するプログラムもたくさん登場してきます。UMLとJavaがその典型でしょうか。自動生成されたソースコードは設計書に書かれた枠だけができるため、実際に必要なロジック、つまりほとんどの部分は自力で追記していくことになります。

もしコンピュータへの命令の仕方を知らない方が言った言葉であるとすると、きっと自分で理解できる命令の仕方を作って欲しい、つまり自分にも使えるプログラミング言語、あるいはプログラミング言語までにも至らないプログラムする方式を作って欲しいということなのかと想像できます。自分で理解ができる命令の仕方という意味で考えてみると、最善はしゃべった言葉をそのまま理解して実行してくれるということになるでしょう。サイロン、ターミネーターがそんな感じだと思われます。

かつて自分が小学生であった頃、親に「マイコン」を買ってもらうための殺し文句に「英語の勉強になる」というものがありました。残念ながら自分の親は共にホストコンピュータを触っているような人達だったのでそれはまったく通じませんでしたが、知らない人にはコンピュータは英語で動作していると思われていたのかもしれません。そしてそのような古き良き時代、日本語を入出力できる日本語BASICならぬ、日本語で動作するBASICなるものがマイコン雑誌の広告に出ていたりしたものです。日本語であればプログラムができると思う層を取り込む試みだったと思われますが、1,2年もしないうちに見なくなったと記憶しています。

もし I < 100 ならば I = I + 1900

半べそです。そもそも知らない人にはIFやらTHENやらが日本語になったところで I = I + 1900 で、そんなアホな、です。実際には英語も含めて自然言語を完全に理解するプログラムはいまだにできていません。言語は進化することを考えると言語の進化も取り込めるようにする必要もあるでしょうし、自然言語は前後の文脈が無いと理解不可能な場合が頻繁にあります。受け身や敬語のように前後の文脈どころか発言者の立場までわかっていないといけない場合もあるでしょう。人間の脳は小さい頃からお勉強してそれらを学んできたのですね。

現在でも日本語でプログラムを書けるようなプログラミング言語は作られているようですが、みな教育用のようです。英語と日本語が大きな壁になる場合には有効な教育方法だと思われます。一方、実際のプログラミング言語で予約されている「英単語」は数十の場合が多いので数十単語覚える方が早いのかもしれません。利用したわけではないので時間があれば「パソコン」を買ってもらえた今、実際に日本語プログラミング言語を使って楽しみながら確認してみたいです。

日本語英語の壁を考えないとして、現在の自分で理解ができる命令の仕方となると、やはり何かしらのプログラミング言語、あるいはプログラミング言語のソースコードを作成するためのかなり限定的な枠組み、ということになるでしょうか。プログラムを作るプログラムがあってもプログラミングができる人間の脳は必要とされている状態で、ロボコップがそんな感じです。

ターミネーターはストーリーにはもう大分できていないといけないくらいの時期だったかと思いますが、スカイネット様への納期を死守するには越えなければいけない高い山が続々とあるようです。あれ、スカイネット様をまず納品しないといけないのでしたっけ。

以上は飲み屋でMetaMojiという会社の記事から始まってまだ世の中はロボコップかねぇという話になるまでを思い出しながら書いたもので、とりとめが無いです。お後がよろしゅう。

devel/php5-pcre (port directory error)

PHP5のportupgrade中に

が出たので、/usr/ports/UPDATINGを見ると、 php5-dbase php5-ncurses php5-pcre php5-spl php5-ming php5-mhash がコアになったから消して、php5と依存してるもの全部リビルドせいとのご指示。

で依存しているものたちをメモ。

で消し去ったら


2011/10/17 追記(archiver/php5-zip参照): /usr/local/php/ext/php_config.h に、必要の無い行がある場合は削除します(pcre spl以外は実際に存在していたか特に確認していません)。

間違いの無いようにファイルも

とでもしてリネームしておきます。追記部分終了


最後に

あたりで処理。あとは一応php.iniを見直し。

あ、その金庫、横に鍵が張り付けてありますが中身大丈夫ですか?

動けばよいってもんじゃない 」ですが、ショッピングカートはその最たるものの一つです。かつてネット通販が出始めの頃、いろいろなケースに出会いました…

最も多かった問題が、返信メールに記載されたURLをクリックするとログインもしていない(そういう通販サイトにはcookieとかセッションとかいう概念が存在しません)のに住所から注文内容から確認できるものです。メールにURLを記載しなければ良いという話でもなく、注文するときはそのようなシステムと知らないわけで、注文終わってからあーやばい通販だったかと学習することになります。今では使う通販も決まってきて新しいシステムの通販に手を出すことはほとんどないのでそういう思いをすることもまずないですが、いまだに某大手ISPのアンケートシステムでも使われてました。海外のTシャツ屋、今は無くなってしまった書店、今もある比較的大手の通販、などなど何度か出会いました。「該当URLが404を返すようにして、あと恐ろしいのでカードの情報も削除しておいてね」とお願いすると、そのすべてから「URLにランダムな文字列が入っているので大丈夫!」(鍵が貼り付けてある金庫なので当然大丈夫じゃないです。念のため)「SSLだからデータは安全!」(通信路の暗号化であり、しかもメールで送られてきてしまったURLは暗号化されていないうえに両端ではデータは復号化された状態なので全然大丈夫じゃないです…)と笑い話にもならない自信満々のお返事を頂戴したものです。

このたび「noindex,nofollow,noarchiveと書いてあるし、user agentでロボットはじいているから大丈夫!」という説も増えたようですが、何にせよ鍵が横に貼り付けてある金庫を、メールで送ったりブラウザから送信させておいて、その金庫の中身が大丈夫だと言ってしまうのはこれまた…

今時ですとブラウザに各種ツールバーをインストールされている方も昔よりも格段に多いでしょうから、tappingやらbrute forceされるまでもなく、そして自らが認識しているかどうかにかかわらず閲覧しているURLが他ホストに自動的に送られている場合も、セキュリティのためなどと称して多数あることでしょう。また別の側面では「ランダムな文字列」が実は順番の数字のBASE64エンコードだったりソルト無しハッシュ値のような、なんちゃってランダムだったときにもノーガード公開状態となります。

このようなシステムを作ってしまう人がここ十数年絶えることなく出続けてきたわけですから、webアプリ作成者の常識に期待することをあきらめるとすると今回のような深刻な犠牲者を増やさないためにはどうすればよいでしょうか。セキュリティソフトと呼ばれるものの中には生のまま特定の情報が送受信される場合に通信を遮断する機能を持つものがありますが、メールで送られてくるURLの場合のように他人のシステムから送られてきてしまう場合、そしてそのページに問題がある場合にはいかんともしようがありません。良さそうなのは、ショッピングカートに限らず鍵付き金庫をばら撒くようなシステム採用サイトのレピュテーションサービスでしょうか。コミュニティーベースでしか成立しそうにないですが、消費者保護とサービス提供者の常識確保のために政府にやっていただければ良いですね。そしてやはり経営者さん、特に消費者の不利益に直結するサイトを運営されている経営者の方たちも「動けばいいってもんじゃない」を考えていただけるとありがたいです。

と今回の某通販での大惨事の記事を見て思ったことでした。

ClamAV 0.96のビルドが失敗

ClamAVのエンジン古いっすよ警告が出るようになったので0.96にするべくportupgradeしたところ、失敗。エラーは次の通り。

PythonのtracebackとGNU makeのメッセージが混ざって見づらいですが、LLVMのユニットテスト用のファイルを作成開始し、import threadの行にて、ImportError: No module named threadエラー発生、ということでどうやらビルド後に行われるテストのPythonでthreadモジュールが必須になったようです。

にて(XXはインストールされていて使われたPythonに合わせて修正)、THREADS の項目を選択してPythonを再インストール。その後ClamAVのアップグレードも無事完了。

その「名前」、あなたのものですか?(その2)

この記事は「その『名前』、あなたのものですか?(その1)」の続きです。

あるお客様が、会社のウェブサイトの引越しをしたい、とおっしゃいました。 この場合、一番基本的な進め方としては、サイトのコンテンツを構成するファイル達を別のサーバに移動して、URLが新しいサーバを示すように変更する、と いうものです。しかしこのお客様の場合はそれが(すぐには)できませんでした。前回の記事は「ドメイン名」について解説しました。

前回のポイント

  • ドメイン名 ≒ 唯一無二の苗字
    • 唯一無二だから好き勝手につけられない。→レジストラから入手するもの。
  • IPアドレス ≒ 住所
  • ネームサーバ ≒ 住所録
    • ドメイン名に対するIPアドレスを知っているネームサーバをレジストリに登録する。
    • 苗字を変えずに住所だけ引っ越すことができる。

今回は実際の引越しについて解説します。

人が引越しをする理由は様々です。間取りが狭くなった、新しい設備が欲しい、建物が無くなる、などなど。ウェブサイトのサーバを引越しする理由も大して変わりありません。そして、人が引越しをするときは、トラックで中身を移動して市役所に転出・転入届を提出しますが、ウェブサイトのサーバの引越しも基本的には中身を移動して住所変更をするだけです。

では、弊社サイトである「www.abacustech.co.jp」を引っ越すと仮定した例で考えてみましょう。前回の記事の例では、このサイトのコンテンツ(文章や画像などのページの内容)は198.51.100.88というIPアドレス(住所)のサーバに置いてありました。今回は、これらのコンテンツを203.0.113.7という「住所」にあるサーバに移動したとしましょう。

図1 サーバの引越し
図1 サーバの引越し

ドメイン名「abacustech.co.jp」は レジストラから株式会社Abacus Technologiesの名義で入手し(図1の(1))、Abacus Technologiesが操作できるネームサーバを登録しています(図1の(2))。そこでAbacus Technologiesはネームサーバに新しいIPアドレス(203.0.113.7)を登録します(図1の(3))。これは皆さんが引っ越した際に転居届を出すのと似ています。

この処理が終わると、ネームサーバは「www.abacustech.co.jp」について聞かれたら、新IPアドレス(203.0.113.7)を教えるので、ユーザのコンピュータからは正しく、引越し先である203.0.113.7のサーバへ要求がたどり着くのです(図1の(4))。

この処理が正しくできたのは、直接的には、レジストリに登録されているネームサーバをAbacus Technologiesが操作できたからなのですが、そもそも操作できるネームサーバが登録できたのは、以下の条件が揃っていたからです。

  1. abacustech.co.jpがAbacus Technologiesの名義である(管理のためのメールが届く)
  2. レジストラに登録されているドメイン名の登録内容の変更権限(*1)をAbacus Technologiesが持っているので、Abacus Technologiesが操作可能なネームサーバを指定できる

通常、変更権限を持つ人はそのドメイン名の名義人、もしくはその名義人から委託された人になります。この2つの根本的な条件が揃えば、ドメイン名の登録IPアドレスはいつでもどこにでも変更できます。

そこで質問です。皆さんがウェブサイトを公開しているそのドメイン名、名義人とドメイン名の登録内容の変更権限を持つ人は誰ですか?

ウェブサイトを制作する際に、その作業を業者に委託すると、ドメイン名の取得も代行してくれる業者が多いです。もしドメイン名の取得も委託する場合は、ドメイン名の名義人と、登録内容の変更権限を持つ人が誰かを確認しましょう。そして、もし将来的にサーバの引越しの自由度を視野に入れるのであれば、できる限りドメイン名の名義と登録内容の変更権限を持つ人が自分になること、もしくはその名義や変更権限が移管できることと、その移管プロセスが明確であることを確認しましょう。

ドメイン名が自分のものであれば、もちろんサーバに縛られることなく自由に処理できます。もしドメイン名の名義人でなかったり変更権限がなければ、仮にサーバを引越ししたくなっても、ドメイン名の名義人や変更権限を持つ人が許可しないと引っ越せません。もし許可が無くても引っ越したければ、別のドメイン名を取得することになり、それは苗字が変わるのに似たインパクトがありますが、このインパクトについてはまた別の機会に解説します。

ドメイン名の名義人になると、その管理にはドメイン名によって年間で数百円から数万円の管理費がかかります。ドメイン名は、不要になれば放棄できます(ただし一度放棄したら、後日同じドメイン名を再度取得したくなっても、それができる確証はありません)。また公共性の高いサイトや大人気のサイトの場合は悪い人が取得してmalwareの配布に利用される恐れもあります。

ドメイン名は唯一無二の苗字と同等で、時間が経って周知されればされるほど組織や会社の呼称の一つとして大事なものになります。ウェブサイトを制作する際や、会社のドメイン名を取得する際には、ドメイン名の名義人と管理について以上の要素を包括的に検討されることをお奨めします。

ここがポイント

  • ドメイン名の名義人であり変更権限があれば好きに操作できる
  • IPアドレスはいつでもどこにでも変更できる
    • →苗字を変えずに住所だけ好きに引越し可能!(*2)

(*1) 少し専門的な言葉を使うと、ドメイン名の登録内容とは「whois」の内容のことです。ドメイン名の内容の変更権限を持つ、ということは「whoisの内容の変更権限を持つ」ということで、レジストラによってその権限の付与の仕方が異なります。例えばMelbourne ITというレジストラだと、変更権限を持つユーザはユーザIDとパスワードを使ってシステムにログインして管理します。

(*2) ただしそのサーバが利用できる立場でないといけません。引越し先の物件を賃貸契約していないと引っ越せないと同じです。

注意: この記事内のIPアドレスは全て説明用のダミーのIPアドレスです。このようなIPアドレスについては「文書に記述するときに使って良い説明用のドメイン名、IPアドレス」を参照してください。

その「名前」、あなたのものですか?(その1) – ドメイン名とは何ですか?

仕事用のウェブサイトをドメインも含めて誰かにお任せで作られる方へ: ドメインを含むURLなどを長く使い続けたい場合は、なんだかよくわからなくてもぜひドメインの「登録者(Registrant)」(属性JPの場合は[登録担当者]、汎用JPの場合は[公開連絡窓口])および「管理者(Admin)」のメールアドレスは、完全にコントロールできる権限が自分だけにあり、かつ@以降にそのドメインを含まないメールアドレスを指定してもらってください。御自身で利用しているプロバイダがメーリングリストを提供している場合もあるので、そういったサービスを利用して自分とお任せする方へ自動的に転送されるようなメーリングリストのアドレスを作成すると便利かもしれません。ドメイン登録者のメールアドレスの確認はwhoisというものでできます。廃業される方も多いので何年か後に泣かないで済むかもしれません。


あるお客様が、会社のウェブサイトの引越しをしたい、とおっしゃいました。この場合一番基本的な進め方としては、サイトのコンテンツを構成するファイル達を別のサーバに移動して、URLが新しいサーバを示すように変更する、というものです。しかしこのお客様の場合はそれが(すぐには)できませんでした。そこで2回に分けてウェブサイトの引越しについて解説します。今回は「ドメイン」について解説します。

例えば弊社のサイトを見るためには、ブックマークに登録していただいたリストの中から「株式会社Abacus Technologies」をクリックしたり、http://www.abacustech.co.jp/とURLを直接入力したり、検索結果から弊社のサイトのページを選んでいただいていると思います。いずれの場合も、皆さんのコンピュータは「www.abacustech.co.jp」にアクセスしようとします。

ドメイン名の使われ方
図1 ドメイン名の使われ方

図1の(1)でユーザーが見たいウェブページを指定するために使っているwww.abacustech.co.jpのabacustech.co.jpの部分が「ドメイン名」と呼ばれるもので、「ドメイン名」は「苗字」の役割を果たします。つまり「abacustech.co.jpさん」と呼んでいると思ってください。ただしこの「苗字」は唯一無二という特性があり、他に同じ苗字を持つ人はいません。そして、みんなが好き勝手に名前を付けていたら唯一無二にはならないので、ドメイン名は「レジストラ」から入手することになっています。なお、説明書などで例示するときに使えるドメインは「文書に記述するときに使って良い説明用のドメイン名、IPアドレス」をご参照ください。

さて、苗字を知っていても住所を知らないので、ユーザーはそのページが実際にどこにあるのかは知りません。そこで登場するのが「ネームサーバ」です。「苗字」の役割を果たすドメイン名に対して、ネームサーバは「住所録」の役割を果たします。つまりネームサーバが「www.abacustech.co.jpさん」がどこに住んでいるのか、その「住所」を見つけてくれるのです。その「住所」の役割を果たすのが「IPアドレス」と呼ばれるものです。IPアドレスは物理的に存在する機械に対して割り振られています。したがって、住所録であるネームサーバに聞けば「www.abacustech.co.jpさん」の住所が「198.51.100.88」(*1)であることが分かるので(図1の(2))、コンピュータはそのIPアドレスを指定してウェブサイトのページを要求することができるのです(図1の(3))。

でも、そもそも「www.abacustech.co.jpさん」の住所が記載されている住所録はどこにあるのでしょうか。その情報を管理しているのが「レジストリ」です。レジストラからドメイン名を入手すると、管理情報の一つとして、レジストリにそのドメインの情報を管理するネームサーバをレジストラ経由で登録できます。ネームサーバはレンタルサーバの業者が提供するもの、レジストラが提供するもの、他にも相当気合があれば自分でサーバを運用する、などがあります。

ところで、このトピックのそもそもの目的は「ウェブサイトの引越し」でした。皆さんが引っ越した場合には、市役所で転出・転入届けを出して、新しい住所を届け出ますね?市役所が駅から遠い所にあるとちょっと面倒ですが、これをしないと住民票が移動しません。さて、そう考えると、ドメイン名に関しても、「苗字」(ドメイン名)があって「住所」(IPアドレス)と「住所録」(ネームサーバ)があるということは、「要するに住所録を書き換えれば良いのか?」と想像できるのではないかと思います。それで正解です。つまり苗字を変えずに住所だけ変えることができるのです。

では次回はその引越しについてご説明しましょう。

ここがポイント

  • ドメイン名 ≒ 唯一無二の苗字
    • 唯一無二だから好き勝手につけられない。→レジストラから入手するもの。
  • IPアドレス ≒ 住所
  • ネームサーバ ≒ 住所録
    • ドメイン名に対するIPアドレスを知っているネームサーバをレジストリに登録する。
    • 苗字を変えずに住所だけ引っ越すことができる。

(*1) IPアドレスは一つのドメイン名に対して複数登録できます。また一つの機械(ネットワークインターフェース)に対して複数のIPアドレスを割り振ることができます。さらには複数の機械に一つのIPアドレスを割り振る(エニーキャスト)こともできますが、一般人がインターネット上でエニーキャストを運用することはありません。

注意:

PivotXでファイルのアップロードをする時は

PivotXのCommunityでもファイルのアップロードについて度々話題になっているようです。アップロードの設定は場合によっては若干複雑になります。 そうこうしているうちに自分もその仲間入りをしてしまいました。 php.iniの次の行がOnになっていること。

file_uploads = On

php.iniの次の行が指定しているディレクトリが存在していること。

upload_tmp_dir = “/phptmpdir”

upload_tmp_dirが指しているディレクトリ(上記の例だと/phptmpdir)はhttpdのプロセスオーナーが読み書きできるようにアクセス権が設定されていること。 この設定ができていないと、新しいエントリーを作成中にイメージをアップロードする操作をしたときに、Complete(完了)というメッセージが出るものの、イメージディレクトリには何もできません。

FAX受信 -> PDF -> e-mailでペーパレス 爆速インストールHylaFAX

あるお客様が一日中ひっきりなしにFAXを受け、トナーを買いに行く手間も値段もバカにならないし紙も大量に消費して地球に優しくないとのこと。常時可動のサーバも無いので、そりゃHylaFAXの出番でっせ、と社に戻って記憶をたどってワークショップをあさると、ありました外付けモデムME5614D2 for まいと~く、そして非力ながらもまだまだ使えるWindows 2000 Professionalときらきら光るシールの張ってあるPC。これでナンバーディスプレイ対応FAX e-mail変換機が簡単にできるじゃありませんか。送信時は媒体が定まっていないので今までどおりFAXに挿すままでよさそう。受信だけが問題である、というわけでさらに簡単(後日 PDF -> e-mail添付 -> FAX送信でペーパレス もやりました)。他にも「HylaFAXでの送受信速度」も参考になるかもしれません。あとインターネットからサーバへのアクセスはフィルタするなり対処が必要です。IPv6でlistenしているからいいやとほっておくと、当たり前にIPv6になった日に大騒ぎになるかもしれません。

まずはFreeBSD RELEASEを最小インストール、そしてpowerd, ntp, ipfw, メール, syslog転送など必要な設定(ざくっと省略)。

デフォルト以外を選択したのは

  • [nn] Default page size: A4

だけ。 /dev/cuau0 (cf. http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/serialcomms.html)がモデムがつながっているやつであることをさくっと確認。ATI4とかATI3とか。そしてアプリケーションでの設定。USBモデムならば/dev/cuaU0とか。

デフォルト以外を選択したのは

  • Country Code: 81
  • Area Code: 3 (東京03から国内開放番号の0を除いた3)
  • Long distance dialing prefix: 0  (国内開放番号)
  • International dialing prefix: 010 (国際開放番号 cf. マイライン)

自動的にfaxaddmodemが起動され、そこでデフォルト以外を指定したのは

  • Serial port that modem is connected to: cuau0
  • Phone number of fax modem: +81.3.0000.0000 (FAXの番号)
  • Local identification string: HOGEHOGE (任意のFAXID。相手側のFAXに通知される。)
  • Long distance dialing prefix: 0  (国内開放番号)
  • International dialing prefix: 010 (国際開放番号 cf. マイライン)
  • Tracing during normal server operaton: 0x1a73f
  • Default tracing during send and receive sessions: 0x1a73f
  • Rings to wait before answering: 3  (早すぎると相手番号を取得し損ねる)

Windows用のinfファイルを見ながら適当にモデムに向かって電話をかけつつ、Caller IDを取得する方法(ここではAT+VCID=1)を見つけて /var/spool/hylafax/etc/config.cuau0 とか.cuaU0 などに追加。

CallIDPatternの後者は自機の番号。AT+GCI=00はAmazonなどで売っているConexant CX93001搭載の技適マークなんか付いてないど安いClass 1.0, Class 2 USB FAXモデムを構内回線につないでFAX受信時にATAでオフフックにならないような場合に付けてあげるともしかしたらつながるようになるかもしれません。Amazonの商品コメントでもFAXの送信ができても受信が安定してないとかできないと書いてありますが、料金からしてだめもとでいろいろ試して楽しめちゃう人向け商品ですね。IN/OUTがあるとかいう深い謎を持った商品もありましたがLINE/PHONEの間違いでしょうきっと。AT+GCI=で設定してATI5で返ってくる00の部分は、日本製でもITU-T.35のAnnex Aに基づいているものもあれば某携帯キャリアのように81とか電話の国番号だったり、某モデムでは64とかなんでかわからない値だったりするので、チップセットメーカによって違う場合があります。話を戻してその他のATI4とかはログで眺めてふーんとうなずくためのものです。ついでに下のこのME5614D2 for まいと~く用に書いた追加設定でMR560E5 for まいと~くも動作することも確認。

e-mail送り先などを指定するために /var/spool/hylafax/etc/FaxDispatch を作成。http://www.hylafax.org/content/Handbook:Server_Operation:Receiving_Faxesにも詳しく書いてありますが、/var/spool/hylafax/bin/faxrcvd を見ながら作成すると必要なものが一目瞭然。

他にも${CALLID1}が自社の番号の時には自社の名前を表示するようにしたりして遊んでみました。/var/spool/hylafax/etc/templates/ro(ちょっとしたボケ)/faxrcvd-succces.txtを自分の気に入った順番や必要な情報だけに整理(ftp://など必要ない)して、

/etc/ttysでは、TAで送信者の電話番号による振り分けを行って2つのfaxgettyで捌くように設定します。

を追加。

して、syslogでエラーが無いことを確認。FAXを送って動作していることを確認して、再起動。再起動後もFAXを送ってちゃんと動作していることを確認。ハードディスクの空きは十分すぎるほどあるのと、良く伺うお客様なので、キューはひたすら溜めて問題時対応用に。いずれフラッシュするようにしましょう。

さらに万が一のPCハングや保守時にも受信できないといけないので、ワークショップからCFカードにFAXを受信できるVE-GP62をひっぱりだしてきましたが、さすがに大量のファックスをいちいち確認するのは大変かもしれないので、冗長用には今のFAXの使い方の紙に印刷のまま使ってもらうのが良いでしょうか。そもそも送信用のFAXは今までのを使うのだから後者ですね。実際に運用して確認してもらいましょう。

ありがとう HylaFAX と portsシステム。あなた方のおかげで楽して世の中がまたまた少しエコになりました。多分。