2003年1月30日
# 色相の変化
色相、彩度、明度とRGB値を無段階で変換できるページを見つけた。
色相の変化って、RGBで表すと変化は曲線になってるのかな。例えば赤から黄色に変化する場合は(R, G, B) = (255, 0, 0)から(R, G, B) = (255, 255, 0)へと緑の値だけが大きくなっていくわけだけど、この変化はサインカーブのような曲線で表されるのかもしれない。今の「彩度断面図」や「明度断面図」を見るとシアン、マゼンタ、イエロー付近の色相の変化が大きいような気がするのは、直線で計算しているためかも。
テストも兼ねて無段階の変換機能も今度作ってみようかな。
2003年1月29日
# 携帯用URL
携帯などの端末からアクセスする場合用に専用のURLを設けるか、それともUser Agentなどで振り分けてPCと同一のURLを使うか、どっちも一長一短あると思うんだけど、最近は同一URLで振り分ける方法に少し惹かれている。理由としては、
- 新規にURLを増やさなくていい
- 同一のリソースを複数のURLで参照するのはスマートでない気もする
- 同じURLでいいので覚えやすく、ユーザビリティーも少し上がりそう
というのがある。一方、別のURLを設ける方法は
- 自分の見たい情報を選択することも可能（例えば携帯からでも省略されていない情報など）
- 情報量の多いページでも対象にあわせて分割したりできる
- 振り分けの設定ができていないエージェントにも対応できる
などという利点がありそう。
今uttsu.comでは携帯用ページとして日記が見られるようになっているのだけど、日記のURLが約2倍に増えてしまって、検索エンジンの検索結果にも携帯用URLの方が表示されてしまったりもしている。あとでもう少し考えてみるか。
# 掲示板設置！
掲示板が完成したので設置した。最初はスレッド式のものにしようと思って作り始めたんだけど、結局シンプルなものになったなぁ。
この掲示板の特徴は、以前にも書いたけど記事の管理を番号ではなく日付けをベースに行っているということ。過去ログも月単位で1ページになるようになっている。書き込み数がそれ程多くなければうまく機能するだろうと予想してるんだけど、どうなるかな。
それから、パソコンにあまり慣れていない人でも使いやすいようにしたかったのでとにかくシンプルにしてみた。入力フォームは名前、タイトル、本文の3つだけにして（これは後で変更するかも）、返信機能なども省いた。一度書き込んだあとで本人だけが再編集したり記事を消したりできたら便利だけど、パスワードが必要になったりと少しややこしくなってしまうので代わりに投稿前に記事をプレビューできるようにしてみた。これが結構便利そうでなかなか気に入っている(^^ ワンクッションおいて見直すのは結構効果あるしね。
2003年1月28日
# id属性の値
XHTMLではウェブページ内のアンカーとしてname属性ではなくid属性を使うらしい。このid属性の値がURLの#以降の部分（diary/20030128.html#1など）に該当するのだけど、命名の約束では値はアルファベットで始まるとのこと。なのでname属性を使っている場合にも将来性を考えるとその規則に従った方がよいだろうとのこと。知らなかった。
uttsu.comではほとんど数字で始まる値を使ってるなぁ…。
# セーフカラー
3の倍数がセーフカラーなのは知ってますとも。知っていつつセーフカラーを無視しつつある今日この頃…。
ところでこの16進表記でゾロ目になるのは10進数で表せば17の倍数なんだねぇ。255=17*15。最初の0を含めて数えれば16段階になってる（色の断面図で彩度を16段階に設定したのはこのため）。色の断面図を作っていて気づいた。
# 千と千尋の神隠し
金曜ロードショーの平均視聴率は46.9%で劇場用映画としては最高記録を更新したそうな。
視聴率46.9%というと約半数の家庭で見てたということかぁ。メディアも発達して選択肢が多くなってきているにも関わらずテレビは強いなぁ。
2003年1月27日
# 複数人でページを作るには
Web Document SystemはもともとWikiのアイデアを参考にして、よりシンプルにとブラウザ上での編集機能を削ったものなんだけど（退化？）、自分以外の人もページを更新できるようにしたい場合もあるのでいろいろ考えていた。Wikiのように各ページに編集用URLへのリンクを張ったり、リンクを張らずに編集用CGIだけ用意したり、と。
ページ上に編集用URLへのリンクをつけるのは余分なリンクを増やしてしまってユーザビリティーも少し低下するし、フォーム上での文章編集は使い慣れたエディタに比べるとやりにくいのもたしか。それにローカルにバックアップのファイルがないのでサーバーにあるものを定期的にバックアップする必要もでてくる。
そこで思いついたのが、FTPを使う方法。各エディターに専用のディレクトリを用意し、そこに原稿ファイルをFTPでUPしてもらう。
doc/
editor1/ # editor1用のディレクトリ
editor2/ # editor2用のディレクトリ
:
ここでWeb Document Systemのデータ用パスに上記のディレクトリを加えると、いずれかのディレクトリ内にyyyymmdd_n.txtがあればyyyymmdd_n.htmlというURLでアクセスできるようになる、というしくみ。サーバーへのUPはブラウザのFTP機能を使えば結構手軽にできるし。
FTPでログインするディレクトリを共通のものにすると同じファイルを編集できて便利だけど、慣れていないと他人のファイルを消去してしまうことも考えられるので個別のディレクトリを用意する方法を考えてみた（パーミッションの設定をすればいいかもしれないけど、ブラウザFTPではできないきもする）。
もっとよい方法もありそうだなぁ。
2003年1月26日
# 色断面図
12色相だとちょっとものたりない気がしたので24色相の色相断面図を作成。彩度、明度による断面図も作ってみた。
色には「色の三属性」とよばれる3つの属性（色相、彩度、明度）があって、要素が3つあるので2次元でいっぺんには表示できない。そこで各属性ごとに他の2つの属性の表を表示してみたのがこれらの断面図。3つの断面図にはそれぞれ適正があって（おそらく）、目的の色の属性のうち色相（赤とか青とか）、彩度（色の鮮やかさ）、明度（白っぽいとか黒っぽいとか）のどれかがわかっている場合には使い分けると便利そう。
色相、彩度、明度はそれぞれ24、16、17段階に設定。これらの数字を選んだわけは、色相は基本の3原色（赤、緑、青）だと3色相、これらの中間色も加えて6色相、…とあと2回繰り返して24色相。
彩度は、16段階にすることによって16進表記にしたときにきれいな数字が少し多くでてくるような気がする（CCや99など。気のせいかも）。HTMLで色を指定するときは16進表記なので。
明度は、色相の基本となる色（24色）の上下に8段階ずつで計17段階。8は2の3乗なので2進数や16進数と相性がよいし。
ソース。いずれもJavaScriptが実行されます。
# RGB
コンピュータで色を指定するときはRGB（赤、緑、青）の値で指定することも多いけど、このR、G、Bの順番は光のスペクトルの順番と同じなんだねぇ。
# 色の断面図 その2
彩度断面図なんかを眺めてると色や光の性質があらわれているようで興味深いなぁ。同じ彩度でも青なんかの色は他の色よりも暗めだとか。「色光の三原色」であるレッド、グリーン、ブルーは少し暗めで、「色料の三原色」であるシアン、マゼンタ、イエローは明るめなのがわかる。これはそれぞれの混色の性質（加法混色と加法減色）と関係がありそうだなぁ。
12色相ではものたりなかったので24色相にしたのだけど、彩度断面図などで色相を並べてみるとまだ隣との色の差が結構ある気がする。とくに色料の三原色であるシアン、マゼンタ、イエローなんかは隣との間にもう一段階ほしい感じ（ちょうど色料の三原色のところでもっとも強く色相の差を認識できるのは、これらの3つの色が原色であることと関係があるのかな）。
気が向いたら48色相版も作ってみるかな。表示に時間がかかりそうだけど。
2003年1月23日
# 鰯
近年、イワシの漁れる量が減ってきているそうな。近所のスーパーでもサンマと同じくらいの値段で売られていたりするので薄々気づいていたんだけど。
イワシの身に一体何があったんだろう。
# 新聞社HPへのリンク
各記事ページへのリンクを張ってもすぐにURLが変わってリンク切れになったりするところが結構あるみたいなので、Yahooとかに転載されている記事にリンクを張った方が便利かもしれない。もっとも、新聞社がユーザビリティーに無頓着でURLを変えてしまっているのか、著作権等の関係で記事へのリンクを嫌っているのかは分からないけれど。
# 色
スタイルシートのことについて探していたらカラーデザインに関するページを見つけた。色相やトーンについて。なるほどなるほど。
色相やトーンについて知っているとデザインをするときに役立ちそうなので少し理論を勉強したいなぁ。
2003年1月21日
# Jcode.pm
以前作った、サーバーにあるアクセスログファイルを直接解析するスクリプトを改良中。
1日ごとの詳細を見れるようにして、Webalizerなどと併用していけば便利かな、と。
URLのデコードにはjcode.plを使っていたんだけどその後継の(?)Jcode.pmというものがあるみたい。Googleなどで使われているUnicodeにも対応しているとのことで早速使ってみた。
URLデコードの場合はURLを丸ごとconvert関数に渡してやればいいみたいで、簡単で便利。
# 人名用漢字
読売新聞の記事によると、名前に使える漢字が大幅に増加される方針らしい。現在は2230字とのこと。
人名に使える漢字にある程度制限がありそうだと思ってたいたけど、思っていたよりも少ないな。それにやっぱり人名用として認可されていない漢字は使えないのかぁ。
人名用漢字の増加には個人的には賛成。漢字は好きだし。
# 横書きの句読点
「横書き句読点の謎」。
文部省の基準は「，と。」だったとは。ずっと「、と。」だと思ってた。
記者の基準が「、と。」というのは言われてみればたしかに。
ところでHTMLの場合は横書きのページがほとんどだけど、マークアップ言語は内容と見栄えを分離することがコンセプトだと思うので、縦書きに表示するブラウザなんかがあっても面白いかも。
スタイルシートではアラビア語など右から左へ書かれる言語のための属性（unicode-bidi）があるみたいだけど、縦書き用の属性ってないのかな。
2003年1月20日
# ウェブページをテキスト処理
以前にも書いたけど、Perlで案外簡単にウェブページの内容を取得できるので、複数のリンク集のページからURLを集めて処理するスクリプトを作ってみた。うまくいけば、移転になったページなんかを早く発見できるかも。
そういえばGoogle Newsって自動で更新されてるってどこかで読んだような気がするけど、ウェブページからニュースを取得してるのかな。それともHTML以外のフォーマットの原稿かな。
# 掲示板スクリプト
今朝作ってみた。以前作ろうと考えていたマルチスレッドタイプではなく、シンプルなもの。
もうほぼ完成しているのだけど、なぜかうまくいかないところがあって調整中。この掲示板はURLもデータファイルも月日が基本単位になっていて、番号が基本単位の一般の掲示板とは少しちがう趣向が凝らしてある。
2003年1月19日
# uttsu.com
uttsu.comドメインは恒久的に保持していくつもり。
したがってホームページとメールのアドレスもずっと変わらない（アクセスできる）予定です。
というわけで、今後ともuttsu.comをよろしくお願いしまする〜
2003年1月17日
# SSHでRSA認証
SSHでRSA公開鍵暗号による認証を試してみた。リモートログイン時にパスワードを入力しなくていいので便利。
SSHでリモートログインするときに使われる認証方式は
- ホストに対するRSAによる認証
- ユーザーに対するRSAによる認証
- パスワード認証
があり、この順番で試されるらしいんだけど今までずっとパスワード認証を使っていたし。
ところでSSHではログイン時の認証にRSAなど公開鍵暗号が使われ、データ通信の際はDESなどの秘密鍵暗号が用いられるとのこと。公開鍵暗号で安全に秘密鍵暗号の鍵を渡して、速度の速い秘密鍵暗号で暗号化してデータ通信をするのだとか。なるほどー。
# 掲示板
スクリプトを書こうかと思ってちょっと考えているのだけど、やっぱり奥が深いなぁ。
よくよく突き詰めていくと結局一番シンプルな形の掲示板がよさそうという気がしてくる（用途にもよると思うけれど）。「○○にはじまって○○におわる」みたいだなぁ。
マルチスレッド式の掲示板もシンプルな掲示板の集まりと見れるのもちょっと興味深いところ。
それから新着記事の表示順でも結構雰囲気が違うもんだなぁ、と気づいた。新着記事を一番下に表示するものだと、少しだけだけど今までのの記事への「返事」というふうに感じてしまうのかも。
2003年1月16日
# CLASSICAL MUSIC ARCHIVES
CLASSICAL MUSIC ARCHIVESというサイト。クラシカル・ミュージックのMIDIが置いてあるんだけど、すごい充実ぶり。
外部音源でMIDIを聴きたいなぁ。
2003年1月15日
# ポップアップ広告
ZDNetの記事によると、ポップアップ広告はバナー広告の約2倍のクリックスルー率があるそうな。でもこれって、記事にもあるけれどまだブラウザの操作にあまり慣れていないユーザーが誤ってクリックしているだけのような気がする。興味を持っていないユーザーを誘っても広告効果は薄いだろうに。
最近では広告の上にマウスを重ねただけでページを開くタイプも登場してきているらしい。まったく迷惑。
ポップアップ広告遮断機能が多くのブラウザに搭載されてきているけれど、こういう問題があるために正規の用途にもポップアップ機能などを使えなくなってきているのは残念。
2003年1月13日
# CHM
HTMLや関連のリソースファイルをまとめて圧縮したCHMファイルを、配布用やPDFのような用途に使うというのは便利そう。これだとコンピュータに慣れていない人にも簡単に扱えそうだし、管理や保管などにも便利そうで、レポート提出用の用途にもかなり有用そうな気がする。
それから、普通の圧縮ファイルをブラウザが解釈するというのはスマートで汎用的。
でも、HTTPでのやりとりでは少し問題があるかも。
普通圧縮ファイルをダウンロードするときに送られてくるサーバーからのレスポンスヘッダを受け取ると一般的なブラウザはファイルを保存しようとしてしまうし。
あと、ページとして表示するにはある程度速度も優先させたいのでその辺は特化されたCHMの方に軍配が上がるかも（複数の圧縮ファイルを開く場合など）。
HTMLの特長の1つはいろんな表示環境で表示できることなので、PDFにはないような用途も多くありそうな気がする。
追記。別にHTTPで直接ページをリクエストする意味はないか…。
# CGIスクリプトの共有
同じCGIスクリプトを異なるディレクトリにいくつか設置するなら、設定ファイルだけを別にして本体のスクリプトは共有するとバージョンアップなどの管理に便利そう。
で、共有する方法としては、
- シンボリックリンクを使う
- mod_rewriteを使う
などが考えられると思う。
どちらも.htaccessなどであらかじめ設定ファイルの位置を環境変数で指定しておく。
シンボリックリンクを使うのは、多くの環境で使えそうだけど、FTPクライアントソフトによってはシンボリックファイルが普通のファイルのように見えてしまったりするのでその点はちょっと扱いにくい。
mod_rewriteを使う方法はよりスマート。でも、.htaccessなどで環境変数をセットできないと使えない弱点も。
.htaccessなどで環境変数をセットするには、Apacheの場合は、
- RewriteRuleディレクティブの[E]フラグを使う
- SetEnvディレクティブを使う
- SetEnvIfディレクティブを使う
などがあるみたい。
2003年1月12日
# サーバー稼動状況
ファイヤーウォールもウェブサーバー等も、順調順調。
さすがLinuxといった感じ。
# プログラミング日課
忙しかったこともあるけど、最近ほとんど新作をリリースしていない。
ということで、自分になんらかのノルマを課してみようかな。
小さくてもいいから週に1つは作る、とか、とにかくコツコツ作りつづける、とか。
でもあまり窮屈にしすぎると、せっかく自由に作れる環境にいるのに会社勤めのような感覚になってしまったり…。
全然プログラミングをしない期間もあるかと思うと、やおらPCに向かって一気に作ってしまうこともある。
相変わらず自分のプログラミングペースについてはよく分からないなぁ。
# スタイルシートの長短
「見栄えと内容を分離できる」という最大の利点はもちろんだけど。
最近日記のページなどをスタイルシートで整形してみて改めて思うのは、表示位置などの大まかな指定も、細かな指定もできる、ということ。サイドのメニューをページの左右どちらに表示するかはスタイルシートだけでダイナミックに操作できてしまうし、同時に、ピクセル単位での微妙な位置指定もできたりする。
これはHTMLだけでは難しいことだし。
欠点は、環境に依存する、というのと、知らないことはできない、ということ。後者は、HTMLならテーブルを使って少々強引だけどいろんなレイアウトが作れるし。
# ウェブページのタイトル
ユーザビリティの大家、ヤコブ・ニールセン博士のコラム「Alert Box」のタイトルが「Alert Box: ○○」とAlert Boxを先につけるものから「○○ (Alert Box)」とタイトルを先にする表記に変わったみたい。
以前にも触れた表記法なので、ちょっと嬉しかったり。
2003年1月11日
# X Forwarding
UNIX系OSではリモートホストのGUIなアプリケーションをローカルのコンピュータから使える、というのに憧れている。この機能を使えば（1台の）サーバーにあるアプリケーションだけを管理していれば複数のクライアントPCで常に最新のアプリケーションが使えて便利だし、それになにより理想を形にしたような機能でかっこいい。
これを実現するのがSSHによるX Forwardingというもので、以前一度友達に見せてもらったことがあるけど、動作は予測できたけど自分にとっては画期的なその方法にびっくりしてしまった。
最近では自宅のPCにもLinuxをインストールしたのでX Forwardingを使ってみたいのだけど、非力なPCをサーバーにしているのでXをインストールしていないためまだ自宅では体験できていない。いつかXクライアントのPCを1台用意して学校のアプリケーションを実行してみたいものだ。
# サーバー管理状況
現在自宅ではファイヤーウォールとWebなどの各種サーバーを起動しているPCがそれぞれ1台ずつある。そのどちらも当然LANで繋がっているのだけど、キーボードやマウス、ディスプレイはついていない。設定を変更したりログを確認するときはSSHでメインのWindows機からログインして操作している。
この方法はとても便利である。でも、ファイヤーウォールの設定をSSHでしていて、誤ってWindows機からのパケットを通さない設定にしてしまったときには、それを解除するためにそのPCで直接操作しなければならないので、本体を引っ張り出してキーボードとディスプレイを繋げて設定をし直す。そしてうまく通信できるのを確かめてから元に戻す。ところがファイヤーウォールの設定を見直しているうちにまた繋がらなくなる。そしてまた引っ張り出す。というようなことの繰り返しになったりしたときにはとても不便である。しかもルーター（ファイヤーウォール）が麻痺しているのでLAN内からインターネットにも接続できなくなるし。
そしてこんなに不便な思いをするのならブロードバンドルーターでも買うのも悪くないなぁ、と思った訳。
# Last-Modifiedヘッダー
CGIのレスポンスヘッダーにgmtime()の値を渡してやるとサーバーが適切なHTTPレスポンスヘッダーに変換して出力してくれるみたい。
$_ = gmtime((stat('target_file.html'))[9]);
print "Last-modified: $_\n\n";
そしてHEADリクエストにも対応するには
$_ = gmtime((stat('target_file.html'))[9]);
print "Content-type: text/html\n";
print "Last-modified: $_\n\n";
exit if ($ENV{REQUEST_METHOD} =~ /^head$/i);
のようにすればOK。
ということで「Web Diary System」と「Web Document System」にも搭載。
2003年1月10日
# VirtualHostとmod_rewrite
Apacheで、VirtualHostを有効にしているとどうやらhttpd.confでRewriteEngineが使えないみたい。VirtualHostディレクティブの中でなら使えるのだけど。
多くのヴァーチャルホストに共通する設定をRewriteで済ませようと思ったのだけどなぁ。
# Web Document System 改良
文書が見つからないときには「404 Not Found」のステータスコードを返すようにした。今までは「Internal Server Error」という物々しいエラーを返してしまっていたので。訪問者を驚かせかねないし。
でもCGI側でエラーコードを返すとサーバーのエラーログには残らないようで、エラーログからリンク切れを見つけられなくなるのでその点はちょっと不便である。
ちなみに方法はCGIから出力するヘッダーに
Status: 404 Not Found
を加えればOK。
# Web Document System 改良 その2
それから、原稿ファイルのヘッダー部にタイトル以外に、サブタイトルと目次を生成するかのフラッグの項目を追加した。
ところでWeb Document Systemに限らずテキストファイルでヘッダーとボディ部が必要な場合は、両者を改行のみの行で区切り、ヘッダーは「変数: 値」のように書く書式に統一しようかと最近思っている。理由はこの方式はHTTPでのやりとりを始め多くのシステムで採用されていて汎用性も期待できるし、境界が簡潔明瞭でプログラムで扱ったりエディタで編集するのにも都合がよいので。
Title: テキストファイルのヘッダー部について Subtitle: 1、比較と検証 Author: 山田太郎 テキストファイルのヘッダー部とボディー部は…
ところでWeb Document Systemでは例外的にタイトルとサブタイトルだけに関しては「変数:」をつけずに記述する方式を検討中。タイトルは変換後のHTMLにおいても必須のヘッダーなので少しでも記述コストを減らすために。両者の識別はサブタイトルの場合は先頭に半角スペースを記述することで指定。
それからタイトルとサブタイトルのどちらを上に記述するかはヘッダー中に現れる順番で指定することに。今のところ原稿ファイルの書き方はこんな感じ。
テキストファイルのヘッダー部について 1、比較と検証 MakeIndex: No テキストファイルのヘッダー部とボディー部は…
タイトルとサブタイトルで「変数:」をつけての指定もサポートするかは、順序も識別するとなると少しだけややこしくなりそうで、他のプログラムからもデータを扱いにくくなりそうなので考慮中。データの汎用性を考えるとすべてのヘッダーを「変数: 値」の方式で記述するのがよさそうだけど。
# Web Document System 改良 その3
わりと便利なプログラムだと思うので早く公開したいと思いつつ、でもまだヘボヘボなのでせめて仕様だけでも固めてからと思いつつ。
2003年1月8日
# HDD親亀小亀
以前HDDを増設したときの話。
メインで使っているSOTECのパソコンは予備の3.5インチファイルベイがないので、HDDを増設するには既存のHDDの上（HDDが縦に付いているので、人間から見れば横）などの空間を利用することになる。アルミ製ステーなどの部品でもとのHDDの上にくっつける方法はとくに「親亀小亀」というのだとか。
ところで増設したHDDの方が容量が大きいので、まるで小亀の上に親亀が乗っているような状態になってしまって、ちょっと小亀がかわいそうな気になってしまった。
# サーバー管理のポリシー
複数人のユーザーがいるサーバーを管理するなら、ユーザーのプライバシーに関する管理者としてのポリシーを明確にしておく必要がありそう。それから、実際そういう運用ができるようサーバーを設定する必要もあるし。
プライバシーの問題は結局はセキュリティーの問題でもあり、ユーザー間での情報の漏洩や外部からの不正アクセスを防ぐのは管理者の役目だけど、管理者は技術的にはユーザーのファイルを見れてしまうので管理者の方ではそういうポリシーも明確にしておく必要があると思う。
でもこのプライバシーとセキュリティーのバランスがなかなか難しそう。というのも、管理者はいろんなログを毎日点検する必要があるけど、そのログの中にユーザーのプライバシーに関するデータが含まれないとも限らないので。あまりくまなくログをチェックすることはプライバシーにも関わってくるし、でもログを見ないと不正アクセスなども検出できないし。
実際、ウェブサーバーへのアクセスログにはアクセスされたURLが記録されるけど、掲示板管理用のCGIなどではURLの一部にパスワードなどが含まれるものもある（専門的にはGETメソッドを使ったアクセス）。こういう問題もあるのでなかなか難しそう。
さいわいウェブサーバーのログの問題は、バーチャルホストを利用してユーザーごとにサブドメインを発行し、ログを分けることで解決しそうな気がする。またメールは、これまでにも数人のユーザーで運用してきたけど（ほとんどの期間はレンタルサーバーでの運用だけど）特に難しくはなさそうな雰囲気である。でもサービスの種類などを増やしたいときにはこの点に十分留意した方がよさそう。
# /etc/passwd
UNIX系OSの場合パスワードは/etc/passwdというファイルに保存されているけど、なんで管理者以外でも読めるファイル属性になっているのだろう。もしかして、いろんなプログラムでパスワードが必要になったときに、このファイルに暗号化されて保存されているパスワードを参照できるようにするためかな。こうすれば複数のパスワードを管理しなくてもよいし。
でも最近はセキュリティー強化のためにシャドーパスワードという技術が取り入れられてパスワードは管理者権限でしか読めなくなっている。この場合自作のプログラムからパスワードを共有する方法ってあるのかな。
# Apacheの実行ユーザー
Apacheの実行ユーザーをnobodyにしていると、CGIなどでファイルの書き込みをするときにotherの属性が参照されるのかな。これは少しだけ不便な気がする。ということで調べようっと。
2003年1月6日
# Apache設定
自宅サーバーのApacheの設定をした。とりあえず全ユーザーにフルアクセスOKに。
# ルーティング
ルーターの根本的な機能はルーティングだと思うのだけど、ルーティングについてネットで検索してみてもあまり情報がない。NATとかマスカレードとかなら結構あるのだけど。
普通ルーティングなんて一般家庭などでは必要ないからかな。
# 1FD Linux Router
FD1枚でルーターとして動作するLinuxのディストリビューションがいくつかあるみたいだけど、ルーター専用として使うならHDなどを他に有効利用できるのでよい方法かも。
# www prefix 問題
前にも書いた話題。
どうしてほとんどのウェブサーバーのドメインにwwwがついたものが使われるのか分かったような気がする。もちろんカッコイイというような重要な(?)ファクターも多分にあるだろうけど。
実は今さっきuttsu.comのホームページを自宅サーバーに移行しようと思って気づいたのだけど、uttsu.comのIPアドレスを変えると同じドメインで運用しているftpやpop3、smtpサーバーなどのIPアドレスも自宅サーバーと同じものになってしまう。ところが、これらのサーバーは今のままにしておきたいときにそれが困難だからではないかな。同じネットワーク内にあればポートフォワーディングなどによってできる気がするけど、まだメール用のサーバーなどは立ててないし。
ここで、ユーザーが自分ひとりだけなら新たにpop3.uttsu.comなどのようなサブドメインを作ってuttsu.comは自宅サーバーのアドレスに移行することも簡単にできるけど、複数のユーザーがいる場合にはこれはあまりスマートではないし。
ということで
- 異なるネットワークで各サーバーを運用したい
- かつ、自分以外のユーザーがいる
という場合にはwwwなどのサブドメインで運用しておく方が便利そうという結論に達したけど、実際のところはどうなのかな。
# FTPサーバーで簡易ファイルサーバー
IEやNetscapeなどのブラウザでFTPにアクセスする方法を使えば、使い慣れたインターフェイス（とくにIEの場合）でFTPということをあまり意識せずに使え、簡易なファイルサーバーとしても使えるのでは、と思ってブラウザのFTPクライアント機能を試してみたけど、どうもうまくいかなかった。アップロードはできるのだけど、ダウンロードやファイルの移動などはできなかったり面倒だったり。やはり本格的なFTPクライアントとして使うようには設計されていないのかな。
Explorer風のインターフェイスを備えたFTPクライアント・ソフトがあれば、FTPサーバーを立てるだけでちょっとしたファイルサーバーとして使えそうな気もする。というより、もともとFTPサーバーはそういう用途で使うものかもしれないけど。
# 異地点バックアップ
デジタル情報はCD-Rなどのメディアに簡単にバックアップできるけど、どんなにまめにバックアップをしても天災などでは対応できない可能性も残っている。そこで、より確実なのは地理的に離れた場所にバックアップしたデータを置くことだけど、最近はブロードバンドが普及してきているのでこれも現実的な話かも。
バックアップデータの保管にはウェブ上で見かけるレンタル用のディスクスペースなどを使うのもいいかもしれないけど、これでは容量の問題もでてきそう。この点は自宅サーバーなどを立ててお互いに利用すればいいかも。バックアップするデータによっては暗号化してから送ればいいと思うし。
2003年1月5日
# DNS情報の伝播
各ネットワークノード（PCなど）からドメイン名を使って他のノードに接続するには、ドメイン名をIPアドレスに変換してアクセスする必要があるけど、インターネット上ではドメイン名とIPアドレスとの関係はDNSサーバーによって管理されている。
ところで、そのDNSサーバー上で情報を書き換えても世界中のDNSサーバーにまで伝播するのには1〜3日くらいかかるので、それまではIPアドレスを指定してしか目的のホストに接続できない。でも、DNSによって伝わる早さが違うので伝播の早いDNSを指定すれば少しだけ早くドメイン名で接続ができるようになる。自宅でサーバーを立ち上げている人なんかには便利かも。
伝播の早さはもしかしたらDNSなどに問い合わせれば分かるかもしれないけれど、ぼくにはまだわからず。自分の利用しているプロバイダで試したところ、ぷららのDNSよりもIIJのものの方が伝播が早いようだった。でもこれもケースバイケースなのかも。
# DNSサーバー
固定IPを取得したので、DNSサーバーを立てるか考え中。DNSサーバーばかりはおそらく固定IPでないと運用できない気がするし（プライベートネットワーク内だけなら別だけど）。
DNSサーバーを立てるとすれば、プライマリのDNSサーバーを自宅に立てて、セカンダリDNSサーバーは他のネットワークに置く必要があると思うので、セカンダリDNSサーバーになってくれるサービスを探さないと。
2003年1月4日
# 自宅サーバーがちゃんと公開できているか確認する方法
汎用的なのはリモートのホストからtelnetでポートを指定して接続してみる方法。
telnet yourserver.com 80
この方法だといろんなサービスを調べられるし。
HTTPに限ってなら、ウェブ上のページ翻訳サービスなどで自分のアドレスを入力する方法も使える。
そういえば、POP3とかでもウェブメールのサービスから読み出せるか。
# ブラウザでFTP
IEやNetscapeなどのブラウザではFTPクライアントの機能も備えているので、簡易な用途になら便利かも。
使い方は、アドレス入力欄に次のように入力する。
IDとPASSWORDはFTPサーバーのもの。
3つめの方法はいちいちパスワードを入力しなくていいので便利だけど、URLに生のパスワードが含まれてしまうのでその分危険度は高くなってしまう。
IEやNetscapeをFTPクライアントとして使った場合、おそらくミラーリングなどの機能は使えないと思うので本格的に使うのには力不足だろうけど、パソコンの初心者や余分なソフトをインストールしたくない人などには結構便利かも。
またウェブスペースを貸し出したりする場合にも、下手にファイル編集用のCGIを作るよりも、FTPサーバーを立ててブラウザのFTP機能を使うのも一方法かも。貸し出し用のWeb日記などでファイル編集機能を代用するのにも使えそう。
# 複数セッション
昨日の続き。
複数同時にセッションを張ることは簡単なのだけど、それを利用するのは難しいそうなことが判明。ゲートウェイは（普通）1つしか使えず、そのためすべてのパケットが一方のネットワークのみに流れるのでもう一方は通信できないのだとか。専用のルーターを使えば簡単に使えるらしいけど。
# 迷惑パケット
パケットフィルタリングやNATなどの設定って、難しいけれどなかなか面白い。ポートスキャンをかけてすぐに成果がわかるのも楽しいし。
ところで外部からの招かれざるパケットは想像以上に届けられている模様（まだアドレスさえ公開していないのに）。めずらしがってときどきnslookupでホスト名を調べているのだけど、海外からのものが多いみたい。この事実を一度知ってしまったらもうファイヤーウォールなしには戻れなそう。
2003年1月3日
# 複数セッション
NTTのフレッツADSLでは同時に複数のセッションを張れるけど、これが意外に使えそう。
固定IPで自宅サーバーを公開する場合、クライアントとして使う場合のIPも同じIPになってしまう。これでも別にいいのだけど、いつも同じIP（しかも世界に一つのユニークな！）でネット上をうろうろするのはちょっと気が引ける。この点、複数同時にセッションが張れるなら、サーバーを固定IPで公開しつつ、クライアント用として動的なIPが使えるし。
それからパケットフィルタリングの設定もIPごとにできるので、サーバー公開用のIPではHTTPやFTPなどのポートも開けて、クライアント用のIPではpingが通るだけにしたりもできる。でも実際、一方でも開いていればあまり意味はないのだけど。
# 自宅サーバー
ポート転送の設定もできたので、運用開始。いくら固定IPといってもいろんな理由で接続が切れることがあるので、様子を見てみて安定しているようならuttsu.comもそちらで運用するかも。
2003年1月2日
# サーバー設定中
ドメイン名で固定IPにアクセスできるようになった。まだ情報が伝播していないDNSにもじきに伝わるでしょう。
ところで自宅サーバーが安定して使えるようになれば気軽にいろんなことができそうな気がする。たとえば独自ドメインのサイトを運営するのも、PCサーバーの電気代などを無視すれば年間10ドルほど（gTLDの場合）でできるし。
どんな面白い使い方ができるか楽しみである。
2003年1月1日
# 恭賀新年
あけましておめでとうございます。
今年もよろしくお願いいたします。
# 固定IP
Linuxでのルーターも設定できたので、先日書いたぷららの固定IPサービスで固定IPを取得した。DNSの設定も書き換えたので、2、3日中にはドメインでアクセスできるようになるはず。
固定IPのメリットはなんといってもどの環境からでもサーバーにアクセスしてもらえること。ダイナミックDNSではDNSサーバーのキャッシュなどによって古いIPアドレスを参照したりしてしまうし。
# Linux Router
はじめはLinux機を一台、ルーター兼各種サーバーとして使おうと思っていたけれど、これだとどちらかのメンテナンス時に両方が使えなくなってしまう。ということでルーター用に一台使うことに。そしてこのルーター機がファイヤーウォールの機能も兼用。あとはポート転送の設定ができればサーバーを公開できる予定。
ところでルーター機能専用にPCを1台を使うなら、ブロードバンドルーターでも買った方がいいかもしれないなぁ。設定の自由度は多少落ちるけれど、扱いが簡単というメリットはとても大きい気がする。