ウェーブ・ダッシュ(~)が文字化けする

文字コード設定をJA16SJISもしくはJA16EUCに設定した状態でUnicodeへの変換をどこかでやっていたりするとウェーブダッシュなどの文字が化けてしまう。これは、「~」という文字などがSJISとUnicodeのマッピングがOracleとMicrosoftの間で異なっているためだそうで。。。
これを解決する方法として、R9.0.1.4からJA16SJISTILDEやJA16EUCTILDEといったキャラクタセットが用意されているらしい。
詳しくはOracleのドキュメントが参考になる。

表領域を物理的に削除したときに発生するORA-01110

そんなときはこのサイトが参考になりましたが、こんな強引な削除は運用上よくありませんので、やらないことが懸命ですね。
MS-DOSプロンプトから
sqlplus /nolog
connect sys/(sysパスワード) as sysdba
alter database datafile ‘(表領域のパス)’ offline drop;
recovery database;
shutdown;
startup;
※ファイル名が分からなければとりあえず、connectした後にstartupしてエラーを出せば分かります。
僕の場合には、
データベースがマウントされました。
ORA-01157: データファイル5を識別/ロックできません –
DBWRトレース・ファイルを参照してください
ORA-01110: データファイル5: ‘(DBFファイルのパス)
と表示されました。
なお、表領域はネットワークドライブ上には作れないらしいので容量が少ないときの回避策には使えないですね。

内部統制になぜITの利用が必要なのか?

来年からJ-SOX法による運用がスタートするけれども、J-SOX法の本になっているCOSOのモデルになぜITの利用が含まれているのだろうか?
SIerからみればなんでもIT利用してもらった方が儲かるわけだから歓迎すべきだけど、理由を分かってないともちろんどこに重点を置いてシステムを提案すべきかが分からなくなってしまう。
内部統制の重要なキーは会社の規定に基づいて正しく運用されていることを証明できること。そのためには、たとえば承認しなければならない人がきちんと承認していること(承認者でない人が承認できないこと)を証明しなければならない。
アナログ運用だとその確からしさを継続的に保証することができないのでそこでシステム運用が必要になる。システムでそれが保証できるのであれば、バグが残っていたりシステム改修をしない限りはその確からしさが継続的に保証される。
だからこそITの利用でもってその証明にかかる負担を少しでも減らすべきだといっているわけだ。
もちろんシステム化するからこそ、管理者というものが存在することになり、管理者による改竄は発生することになる。それこそログは別サーバーで管理し、そのサーバーが全く別の管理者で管理され、改竄されてないことを証明しなければならないが、その管理者同士が結託すればそれもできなくなる。
根底にある難しさはやはり運用している人間自身にあると言える。オチは結局そういうことです。

ネットワーク運用の考え方の変化

インターネットをはじめインフラは現在は性悪説で運用されることが当たり前だが、以前は閉ざされたネットワークということもあり性善説で運用されてきた。それはプロトコルの設計にみてとれる。
たとえば、SMTPなんかは認証が存在しない。そもそもスパムメールを送るとかなりすましをするだなんて考慮されてないわけで。
Whoisというドメイン情報の検索サービスがあるが、これはドメイン管理の責任を明確にするためのものだったが、DM送付用の情報源になるなどの問題になり、今や当初の目的を果たせない意味のない運用になっている。
おそらくインターネットは商用利用されることになって利用者が格段に増えて今や無くてはならないインフラになったものの理想と現実のギャップに直面してきたと言える。
これからインターネットはどのように発展していくのだろうか?IPv6によるアドレス空間の無限の広がりから新たな発想によるサービスが生まれるのか、はたまた既存のプロトコルの組み合わせから思いもつかなかった便利なサービスが生まれるのか、はたまた不要なパケットによってトラフィックが埋め尽くされそこから悪循環が生まれてくることの連続なのか・・・

無償のグループウェア

メーカーが無償のソフトウエアを出すとき、そこには長期間にわたる戦略があるに違いない。
GroupBoard Workspace
2007より日本チームでの開発がされるようになっているようだ。
これもグループウェアの使われ方が世界共通ではないからだろう。

IPv6のなぞ

ずいぶん昔に、IPv4バイトのIPアドレス体系をもつのだから、IPv6は6バイトのIPアドレス体系なのかと思ってしまったことがあります。
実際のところIPv4は32ビット=4バイトですが、IPv6は128ビット=16バイトなので、違うなぁという自問自答をした覚えがあります。今こんなことを思っていたらネットワークエンジニア失格ですが。
もうすでに皆さんはご存知かと思いますが、IPv4はInternet Protocol Version4の略であり、IPv6は Version6なのです。
ということはVersion5があり、Version7以降もあるのではないかと思う人は鋭くて、実はIPv9まで存在します。
詳しくは、KyoのCCIE取得日記☆を参照してみてください。

言語を正規化する

正規とは・・・
規則などではっきりきまっていること。また、その規定。(大辞林第2版より)
システム化(プログラミング)するということは今まで手作業でやっていた作業を正規化してコンピュータに仕事をさせるための作業だ。ロボットの目指すところは人間の正規化であるわけだけど、その中で言語の正規化も必要になってくる。言語の正規化は身近なところではコンピュータの日本語変換システムが該当すると思う。
さて日本語変換システムは、単純な漢字変換(といったら怒られる。日本語の変換システムはおそらく他の言語に比べればもっとも難しい可能性があるから。)を経て、予測する世界に入ってきた。
それは、携帯電話などの小型ディバイスの発達に伴って、少ないキーの入力回数でもって日本語入力をする必要が出てきたからだ。あ、便利だと思う人もいれば、この機能が表現を制約しかねない非常に危険なツールだと思う人もいるだろう。
僕は一番最初に出版社に短いながら勤務していた。そこで国語編集部につとめていた先輩に日本語変換システム開発に必要な辞書のデータベースの提供をもとめてきた有名なコンピュータメーカとの打ち合わせに同席してもらったんですが、その会議のあとにぼやいた一言が印象的だった。”言語は生きているのにそれをひとくくりの変換システムに押し込めてしまうなんて。。。”
たしかに言語は生きている。新しい単語もできてくれば新しい言葉の使い方も生まれてくる。僕は詳しくは分からないが、これが正しくて、これが間違っているということはなくて、僕たちが今まさに話している言葉が正しいわけで、それを正規化してしまうということは、その表現の自由が奪われてしまうというわけだ。つまり、新しい日本語が生まれにくくなる。
もちろん誤った日本語の使い方だから制約してしまっても問題ないという考え方もあるだろう。でも誤用がそのまま辞書に載るようになることも長い歴史の中では多いわけだ。だから言葉は難しいのかもしれない。
話はそれてしまったが、システム化するときにエンジニアはこのようなことに注意しなければならない。一つの向きから見てこれは便利だと思ったことをシステム化する事はとても得意だ。この発想がなければエンジニアの仕事は楽しくないはず。ただ、反対向きから見て本当に便利なのかについても考えてもいいだろう。
そんなことは作ってから評価される段階において評論家にでも任せればいいと思うかもしれないが、作りっぱなしのシステムではなく使われるシステム作りを目指して僕たちはいろんな畑の人たちと積極的に話をして、価値観を共有して一つの物事を様々なアプローチから考えることができるようにならなければならないと思う。
今自分がやらなければならないことが手元になくて焦っていることがよくある。何かをやらなければ周りにおいてかれてしまうという恐怖心だ。または、こんなことをやっていて何の役に立つのだろうという疑問。
与えられた仕事をして時間に余裕ができるからそんなことを考える暇ができるのかもしれない。もし余裕ができたら恐怖心を捨てて話をしに行こうと思う。

ホスト制限が効かない

<Directory (pathname)>
order allow,deny
allow from all
deny from XXX.XXX.XXX.XXX
</Directory>
Apacheでホスト制限が効かない場合には、以下が考えられる。
1.pathnameがそもそも勘違いしている
pathnameはDocumentRoot以下の絶対パスではなく、システム上のパスである。Windows版のApacheならば、c:\などから始まることになるだろう。
2.同一のディレクティブが存在しないかをチェックする
httpd.confファイルとそのファイルがincludeしている全てのファイルにおいて、同じ
<Directory XXX>
が存在していないかを確認する。経験では、同一のpathnameを持つDirectoryディレクティブは後に出てくるものが無視されているように思える。どのような使用になっているかはもう少し確認してみる必要がありそうだが、同一のpathnameを持つDirectoryディレクティブが存在していないかを確認してみると良いだろう。
もし同じものが見つかったならば、見つかった方に追加するかもしくはpathnameをもっと詳細なパス(たとえば、/var/wwwなど)を設定するようにすれば良いだろう。

なぜpasswdファイルが閲覧されるとまずいのか?

Linuxにはアカウントの一覧を/etc/passwdで管理しているが、Directory Traversalなどによって閲覧できてしまわないように対策を進める書籍は多い。ただなぜ閲覧させてはいけないかが書かれていないケースが非常に多い。passwdにはパスワードの情報が含まれていないにも関わらずだ。
それはユーザーの一覧が分かると総当たり攻撃に必要な時間が確実に減るからだ。ユーザーが分からなければ不特定多数ユーザー×不特定多数パスワードで無限大になるが、ユーザーが固定されれば試すパターンはユーザー数×不特定パスワードとなる。
ただpasswdが閲覧できなければ安全かと言えばそうではない。デフォルトユーザー(rootやmysqladmin、postgresなど)がログインできないことが必要である。これらがログイン可能であれば結局パターン数が絞れてしまう。
またSMTPサービスによるユーザー問い合わせにも注意しなければならない。

“なぜpasswdファイルが閲覧されるとまずいのか?” の続きを読む