2001年03月01日(木)<< 前の日記 | 次の日記 >>
この日の詳細

■1 bindのバージョンの調べ方[http://sofa.tnm.ne.jp/~whiro/computer/qa.html][freebsd]次の記事 >> このエントリーをはてなブックマークに追加

dig @ns.example.co.jp version.bind chaos txt
nslookupつかうなら、
nslookup -type=TXT -class=CHAOS version.bind. ns.example.co.jp
ですか。

■ 関連記事

■2Webページ書き換え[セキュリティ]<< 前の記事 このエントリーをはてなブックマークに追加

知り合いの会社がやられたらしい。

■ 関連記事

詳細はこの日の詳細から

2001年03月02日(金)<< 前の日記 | 次の日記 >>
この日の詳細

■1bindの緊急対策でサンドボックスアプローチ[セキュリティ] このエントリーをはてなブックマークに追加

バージョン上げないとまずいというのは分かっているけど、今は対処できないって場合。 bindを移行するのは大変だと思って手を付けないでいる方は、 とりあえずこの対策だけでもどうぞ。標準作業時間15分を目安にどうぞ。 *1
% named -h
とやって(別にhでなくても、無効なオプションならそれで良いのですが)、
Usage: named [-d #] [-q] [-r] [-f] [-p port] [[-b|-c] configfile]
             [-u (username|uid)] [-g (groupname|gid)]
             [-t directory]
の様に、'-u'や'-t'のオプションが使えれば、緊急対策ができます。
砂場でbind[http://www.nantoka.com/~kei/diary/?200102c&to=200102242#T200102242] の方法を使って、少なくともroot権限は取れないようにしましょう。
ポイントは、
  • namedユーザーとグループを作る
  • /etc/namedb/var/run をnamedさんのものにして、namedさんの権限で書き込めるようにする
  • (セカンダリをやる場合は)バックアップファイルを置くディレクトリもnamedさんのものにする
  • named.confのoptions directory の指定を"/"にする
  • namedの起動オプションを 'named -u named -t /etc/namedb -c /named.conf'として、 /etc/namedbにchrootしてから、namedさんの権限で動くようにする
です。
砂場でBINDを動かす[http://www.pcc-software.org/security/sandbox-bind.html] という解説が参考になります。
この対策だけでは、namedエントリに嘘情報を流し込まれたり、 namedを落とされたりする可能性はありますが、少なくともroot権限を守ることができるようになります。
書き換えを受けたり、踏み台にされる可能性がなくなる訳ではありませんが、 対策に掛ける手間の割には安全性が向上します。 とりあえずこの方法で緊急対策しておいて、移行の準備を進めると良いでしょう。
*1: もちろん、設定ファイルや起動ファイルがどこにあるか分かっていればそんなに掛かりません。

■ 関連記事

詳細はこの日の詳細から

2001年03月05日(月)<< 前の日記 | 次の日記 >>
この日の詳細

■1花粉症次の記事 >> このエントリーをはてなブックマークに追加

昨年、発症してしまったのだが、今年も残念ながら発症。
一度発症すると、翌年からも発症しやすくなるらしい。

■ 関連記事

■2 組み込み屋の率直な話[http://www.totalware.gifu.gifu.jp/~a.rin/diary/?200103a#200103021]<< 前の記事 | 次の記事 >> このエントリーをはてなブックマークに追加

某日記[http://diary.imou.to/~AoiMoe/2001.03/early.html#2001.03.05_s14] より。
私も、ファームウェアへのGPL適用には違和感があったのですが、 ファームの開発を経験しているかが、この感覚を左右する気はします。
ソースを公開するということは、ソフトウェアのリバースエンジニアリングが不要になるばかりか、 ハードウェアのリバースエンジニアリングも容易にします。
お客さんがデバッグやハッキングする類の楽しい商品だったら別として、 電子レンジのファームをハッキングというのは現実的じゃないし。 *1
しかしながら、カーネルのソースが無い苦しみが分かっているからこそ、 カーネルのソースが公開されている世界は素晴らしいなぁという気持ちもあります。 「やっぱり、組み込みにはBSDだよね」とか言ってみる。
*1: やったって良いんだけど、世の中にはUIを改善したいような商品もありますし。 成果ができたとして、その成果物の再利用性があまりにも低すぎますよね。 パターンカットして、マスクROMをEPROMに換装してって。

■ 関連記事

■3 Nikomat[http://www.fastwave.gr.jp/diarysrv/kiwamoto/200103a.html#20010305-6]<< 前の記事 このエントリーをはてなブックマークに追加

「落としても壊れないNikomat」でしたっけ。銀塩写真しばらくやってないなぁ。

■ 関連記事

詳細はこの日の詳細から

2001年03月06日(火)<< 前の日記 | 次の日記 >>
この日の詳細

■1 3-stableのpackages[http://home.jp.FreeBSD.org/~matusita/memorandum/#20010304165907]次の記事 >> このエントリーをはてなブックマークに追加

さよなら3-stableなので、mirrorしてCDに焼いておくことにする *1 です。 ウチとこから近いのは、 RING(OCN)[ftp://ring.ocn.ad.jp/pub/FreeBSD/] なので、ftpmirror.cfに、
package = packages-3-stable
 ftp-server = ring.ocn.ad.jp
 remote-directory = /pub/FreeBSD/ports/i386/packages-3-stable
 local-directory = ~ftp/pub/FreeBSD/ports/i386/packages-3-stable
とか書いて丸ごとミラー。近いだけあって、ラインの9割位でてますね。

終わった:

2,627,312KBytesですか。上手にCDに分けるスクリプトってなかったですかね。 *2
*1: メンテナンスしてる先のサーバは、2.2系列や、3系列があるので、 新しいものを入れるときに、手元にpackagesを持っていないと困る。
*2: packages間の依存関係があるんで、上手に分けることができればCD入れ替えの回数が減らせて嬉しい。

■ 関連記事

■2 プレステ2への移植に関する Richard Stallman との議論(翻訳)[http://www1.neweb.ne.jp/wa/yamdas/column/technique/rmsj.html]<< 前の記事 | 次の記事 >> このエントリーをはてなブックマークに追加

A Way Out[http://club.h14m.org/kenji/diary/?200103a&to=200103065#200103065] から。 このところ、 ライセンス[http://www.bsdclub.org/~motoyuki/d/d200103a.html#06-3] 関係の[http://www.fastwave.gr.jp/diarysrv/mad-p/200103a.html#20010305-1] 議論が[http://diary.imou.to/~AoiMoe/2001.03/early.html#2001.03.06_s05] 活発[http://www.totalware.gifu.gifu.jp/~a.rin/diary/?200103a#200103021] ですが、私はGNUほどストイックにはなれないなぁ *3 と感じました。
  • 楽しいデバイスがある
  • 技術資料は入手できるが公開はできない
  • ドライバのバイナリを公開することは許されるがソースは公開できない
  • ドライバのAPIは公開できる
という状況だったら、ハックしたかったらするし、 ドライバなるべく小さく切り分けて、他の部分はBSDライセンスで出せるところは出したいですね。
お仕事頂いて、プロジェクト丸ごとオープンソースにするのは難しくても、 一部だけならオープンソースにできるという場合は、それも前進だと思いますし。
*3: 共感もするし、納得もするし、理想を感じるけど、現実を変えていくだけの力がないです。 少しずつ現実と折り合いをつけていくことはできそうなので、できる範囲でがんばっているつもり。

■ 関連記事

■3 登記[http://www.denpa.org/~go/denpa/200103/from01.html#06_5]<< 前の記事 このエントリーをはてなブックマークに追加

「本来、厚生年金と社会保険は義務らしいのですが」社会保険事務所に行ったら、 作ったばかりの会社じゃ加入に難色を示されたりすることもあるみたいです。
フリーの人で集まって会社を立ち上げて、会社からの給料はものすごく安くして(個人で大部分の仕事は受注する)、 社会保険料を安くあげる・・・なんてことがあるからかも知れません。

■ 関連記事

詳細はこの日の詳細から

2001年03月07日(水)<< 前の日記 | 次の日記 >>
この日の詳細

■1 居酒屋きゅるる亭[http://qlulu.tripod.co.jp/a_frame2.htm][CLIP]次の記事 >> このエントリーをはてなブックマークに追加

アリー・マイ・ラブ挿入曲リスト発見。

■ 関連記事

■2 napster[http://www.napster.com/]<< 前の記事 このエントリーをはてなブックマークに追加

napsterを初体験。
昔から頭の中に時々流れる曲があって、タイトルを知りたいなぁと思っていたのですが、 アリー・マイ・ラブ[http://www.nhk.or.jp/kaigai/ally/index.html] でその曲が流れたんですね。
エピソード毎に 挿入曲のリスト[http://www.nhk.or.jp/kaigai/ally/mimiyori/mimiyori17.html#songs] があるんで、ほぼタイトルは間違いなし。
これでCD屋さんに行って、視聴ができれば買ってくるだけなのですが、 せっかくの常時接続環境ですし、napsterで検索掛けたら簡単に見つかる聴けるです。 これは既存の音楽流通業界反対するのは分かります。
でも、この便利さは音楽の流通を根底から変えるという予感がします。 著作権者の権利を守りながらこの便利さを享受するために、 どういう技術を開発して、どういう運用にすれば良いのかなぁと考えてみたり。
結局、探し出した曲は、グロリア・ゲイナーの"I Will Survive".

■ 関連記事

詳細はこの日の詳細から

2001年03月08日(木)<< 前の日記 | 次の日記 >>
この日の詳細

■1サーバ落ちる次の記事 >> このエントリーをはてなブックマークに追加

このところ、調子が悪いなぁと思っていた内部用サーバが落ちました。 状況証拠から見て、スラッシングの果てにダウンした(様に見えたのかも知れない)様です。
再起動してもしばらくするとloadとiostatの数値が上がってくるので、 異常にに太るプロセスがいて、こいつが実メモリを食いつぶすという仮説で調査開始。
太るのはsquid *1 で、こいつを止めるとiostatもloadも正常値に戻る。再起動すると再発する。 かなり長いこと安定して動いていたので、設定自体には問題がないと思われるので、 溜め込んだキャッシュを掃除してみる。 どうせ、キャッシュだけのパーティションなので、ayncマウントし直して削除。
# umount /.u2
# mount -o async /.u2
# cd /.u2/squid/cache
# rm -Rf *
# squid -z
# cd /
# umount /.u2
# mount /.u2
とかやったら回復。キャッシュが変になっていたらしい。
*1: topで見ると、RESが120M。STATEがswread。

■ 関連記事

■2 DISCO FEVER[http://izan.simplenet.com/][音楽]<< 前の記事 このエントリーをはてなブックマークに追加

Real Audioで試聴ができるのでとっても便利。

■ 関連記事

詳細はこの日の詳細から

2001年03月09日(金)<< 前の日記 | 次の日記 >>
この日の詳細

■1 どうもゲーム会社らしい[http://twilightex.tripod.co.jp/index.html]次の記事 >> このエントリーをはてなブックマークに追加

偶然に見つけた。 ゲーム製作の現場はどこも大変。
でも、もう一度やってみたいと思ったりも。

■ 関連記事

■2 メータ巻き戻し[http://catv-8-109.medias.ne.jp:10080/~takayuki/diary/?200103a&to=200103073#200103073]<< 前の記事 | 次の記事 >> このエントリーをはてなブックマークに追加

同じニュースを見て、
  • タンパフリーなカウンターモジュール
  • 1Km毎にカウントアップする信号を供給するのみ
  • 10秒に1カウント以上はしない
  • 指定数値にセットするのはディーラーorメーカーのみ可能
みたいなものを考えたけれども、ディーラーから鍵の組み合わせ情報が漏れたりする事件もあったんで、 完璧じゃないですね。そもそも新品のモジュールを手に入れれば、何日かで指定数値に持っていけちゃう。
エンジン回転数を含めたもっともっと多くの情報をコンピューターユニットに記録して、 その数値を読み出す道具は簡単に手に入るけど、改ざんは事実上不可能という状況を作る問題。
なんか暗号の適用分野と重なってきますね。

■ 関連記事

■3 中国初の人型ロボット、発表[http://www.peopledaily.co.jp/j/2000/11/29/jp20001129_44763.html][CLIP]<< 前の記事 このエントリーをはてなブックマークに追加

今まで見つけたところでは、信憑性の高いページ。

■ 関連記事

詳細はこの日の詳細から

2001年03月11日()<< 前の日記 | 次の日記 >>
この日の詳細

■1 DeCSS Perlスクリプト[http://www.cs.cmu.edu/~dst/DeCSS/Gallery/qrpff-fast.pl] このエントリーをはてなブックマークに追加

さくらださんのとこ[http://www.halsys.co.jp/~sakurada/diary/d200103b.html#10-2-1] から。
その昔,某コンピューターに載っていた1行プログラムを思い出したりしました。 囲み記事で,「ちょっといいプログラム」とかいうのもありましたよね。

■ 関連記事

詳細はこの日の詳細から

2001年03月12日(月)<< 前の日記 | 次の日記 >>
この日の詳細

■1Napster次の記事 >> このエントリーをはてなブックマークに追加

導入して何日か経ったので,感じたことを書き残しておこうと思った。 新しいものに触れたときに感じたことは, 時間が経って当たり前になってしまうと,なかなか思いつけなかったりする。

自分が送り手になること:

は,楽しいのかも知れない。

メッセージを送る方法:

として,ファイル名を使ってメッセージを書くという方法を使っている方がいた。

P2P?:

もともとインターネットって,Peer To Peerが当たり前。 いつのまにか,イソターネットになってしまっていた。

自分の身は自分で守れるOS:

ファイヤウォールの役割が変わる

コンテンツ:

に対するお金の払い方が変わらないといけないと思う。

■ 関連記事

■2FireWallのバージョンアップ<< 前の記事 このエントリーをはてなブックマークに追加

長年FireWallをやってきたマシンのバージョンアップをやった。 実は、今までパッチ当てまくりの2.2-stableだったので、 ものすごく世代をとんだバージョンアップになった。 運用上、止めるのが非常に難しい(内側のセグメントがインターネットに接続できなくなる)ので、まとまった作業時間を取れず、長いことバージョンアップできなかったのです。
本当だったら、別のハードウェアを用意して差し替えれば良いのだけれど、 手頃なマシンが調達できなかったので、停止時間を取って作業することにしました。
予め、修正点や入れたports等をリストアップして作業手順を作っておいたので *1 、 非常にスムーズにいって復活。 素晴らしい。ここまで心配するほどじゃなかったな。
*1: 途中で、内側セグメントはインターネットに出れなくなるので、 あのページに書いてあった・・・なんていうことが起きると困る。

■ 関連記事

詳細はこの日の詳細から

2001年03月13日(火)<< 前の日記 | 次の日記 >>
この日の詳細

■1 ipfwでステートフルフィルタリング[http://www02.so-net.ne.jp/~masuda/diary/?200101b&to=200101161#200101161][freebsd]次の記事 >> このエントリーをはてなブックマークに追加

FreeBSD4.1以降では、ステートフルなパケットフィルタリングができるようになりました。 これまでは、外側から来るestablishedなパケットは全て通さぜるを得なかった訳ですが、 この機能を使うと、ウソACKがセットされたりしているパケットをフィルタリングできる様になります。
他にも別のmethodが指定できたりするらしくて興味はあるのですが、 マニュアルではちょっと情報不足なので、ソース読んだりしないといけない様ですね。

■ 関連記事

■2Amanada<< 前の記事 このエントリーをはてなブックマークに追加

portsが、ServerとClientに分かれるようになったので便利。 これまで、Clientに最低限必要なパッケージを見切って、
pkg_add -f amanda-2.4.1.tgz
とかしてた。

■ 関連記事

詳細はこの日の詳細から

2001年03月16日(金)<< 前の日記 | 次の日記 >>
この日の詳細

■1 PacketShaper[http://www.metrosystems.co.jp/packetshaperhp/]次の記事 >> このエントリーをはてなブックマークに追加

うーん。コンテンツ依存の帯域制限を実現してるのか。 手ごわい。

■ 関連記事

■2 ipfw(8)[http://www02.so-net.ne.jp/~masuda/diary/?200103b&to=200103155#200103155][freebsd]<< 前の記事 このエントリーをはてなブックマークに追加

リンクさせていただきました:-)。
dummynetの解説[http://www.iet.unipi.it/~luigi/ip_dummynet/]ALTQ[http://www.csl.sony.co.jp/person/kjc/kjc/software.html] も参考になりました。TNXです。
キューイングによる帯域の制御って本当に効くのかなぁという疑問もありまして、 これは体感的な納得が必要なので、試してみるしかないですね。

■ 関連記事

詳細はこの日の詳細から

2001年03月21日(水)<< 前の日記 | 次の日記 >>
この日の詳細

■1 魅惑の似非科学[http://www.geocities.co.jp/Technopolis/8931/][CLIP]次の記事 >> このエントリーをはてなブックマークに追加

また一つ,理系読み物サイトを見つけた。
こういうのためておいて寝る前に布団のなかで読みたいのだけれども, うまいテクノロジーはないですかね。ノートパソコンは今ひとつだった。
こういうのこそ,PIMに持っていって読むと良いのかも知れない。

しまった・・・:

リンク先間違えていました。ご指摘いただいた方には感謝です。

■ 関連記事

■2upgradeインストール[freebsd]<< 前の記事 このエントリーをはてなブックマークに追加

内側用ファイルサーバを,4.2-RELEASEにアップグレード。
アップグレードであっさりいくと思ったのですが, 途中でCDRomを読めなくなって失敗。
どちらのカーネルでも立ち上がらない状態にしてしまい,fixitで対処。 フロッピーブートだから時間が掛かってしょうがない。
結局,1時間位の予定が2時間以上掛かってしまった。油断大敵。

ちなみに:

業務で使っているファイルサーバのアップグレードは, 軽い気持ちでやるもんべきではありませんね。 何が起こるか分かりませんから, 1日丸々作業に使える日じゃないと,本当はやっちゃだめ。

■ 関連記事

詳細はこの日の詳細から

2001年03月22日(木)<< 前の日記 | 次の日記 >>
この日の詳細

■1デバッグ用のカーネル[freebsd] このエントリーをはてなブックマークに追加

最近4.2Rにアップグレードしたサーバが2回もpanicしたのでちょっと追ってみた。 ネットワーク周りの問題に見えたので,デバッグシンボル付きのカーネルを仕込んだ。 /etc/rc.confで
dumpdev="/dev/ad0s1b"
しておいて,次のクラッシュの時には詳しく調べてみよう。 ちなみに指定しているデバイスはswap領域で,こういう事態を考慮して, ウチで仕込んでいるサーバは全て,クラッシュダンプが取れるだけの/varとswapを 確保してあります。
デバッグシンボル付きのカーネルでなくても,クラッシュダンプとそのkernelのconfigファイルが手に入れれば, ある程度は解析できる[http://www.jp.freebsd.org/www.FreeBSD.org/ja/handbook/x18419.html] ので,とりあえずクラッシュダンプだけでも手に入れるのはメリットがあると思います。
一般に,「落ちたら解析しよう」と待ち構えているサーバに限って安定だったりするので, ひょっとしてお守り効果もあるかも知れません。

■ 関連記事

詳細はこの日の詳細から

2001年03月23日(金)<< 前の日記 | 次の日記 >>
この日の詳細

■1 再び深刻化? ITプロフェッショナルに迫る“心の健康”問題[http://itpro.nikkeibp.co.jp/free/ITPro/OPINION/20010321/1/] このエントリーをはてなブックマークに追加

桜田さんとこ[http://www.halsys.co.jp/~sakurada/diary/d200103c.html#22-2-2] から。
今の状況は、A氏より厳しい状況になっている気がする。 コードの生産性が上がらないのも、バグがなかなか取れないのも、うつが原因かも知れない(本当か?)。 アンケートに答えてみた。まずいのかも知れない。 このプロジェクト片付いたら、少しは休みを取ろう。

■ 関連記事

詳細はこの日の詳細から

2001年03月24日()<< 前の日記 | 次の日記 >>
この日の詳細

■1 mg-2.24[ftp://ftp.iij.ad.jp/pub/IIJ/dist/utashiro/perl/mg-2.24][freebsd]次の記事 >> このエントリーをはてなブックマークに追加

複数行にわたるgrepを実現できるコマンドがないかと思って、 users-jpでたずねたところ、 multi-line grep[ftp://ftp.iij.ad.jp/pub/IIJ/dist/utashiro/perl/mg-2.24] の存在を教えてもらった。
探していたものそのものズバリって感じでしたが、探し方が足りなかったと反省。
ただ、上手に質問してあって *1 それを元に回答なり議論があれば、それはアーカイブの財産になるので、 無駄ではないと思います。
*1: ああいったMLでの質問の良し悪しについて、色々と議論がありますが、 アーカイブの財産になる質問は良い質問だと思います。 私の質問が財産になるかどうかは分かりませんが、検索まで気を配って配慮しているつもり。

■ 関連記事

■2 バックアップ運用話[http://www02.so-net.ne.jp/~masuda/diary/?200103c&to=200103223#200103223][freebsd]<< 前の記事 | 次の記事 >> このエントリーをはてなブックマークに追加

そんなあなたに Amanda[http://www.amanda.org/] がお勧め。
他のNTベースのサーバのクライアントになってバックアップってのもできます。

■ 関連記事

■3 お仕事[http://www02.so-net.ne.jp/~masuda/diary/?200103c&to=200103231S2#200103231S2]<< 前の記事 このエントリーをはてなブックマークに追加

システム管理者の究極的な仕事はラクすることです。
大変な目にあわないようにセキュリティ対策したりバックアップしたり, もっとラクしたいのでそれを自動化したりするわけですね。
ところが,しょっちゅうサーバ落としてその度に徹夜で復旧したり, 深夜みんなが帰ってからバックアップを手動で取ったりしている管理者と, 普段から安定動作に配慮して履歴もCVSあたりで管理して自動バックアップ体制。 問題が起きたら自動的に携帯にメールが来るようになってるので, 安心して帰りますという管理者だと,なぜか前者が評価されたりするんです。
従って,忙しそうに働いているように見えないと評価されない職場では, 優秀なシステム管理者ほどスポイルされることになります。

ちなみに:

優秀なハッカーもラクするのが仕事です。
エディタを駆使してテキストファイルを加工する仕事を頼んだのに、 コンパイラを駆使してツールを作っちゃう人を評価できないのは不幸ですね。
管理職のためのハッカー FAQ[http://www1.neweb.ne.jp/wa/yamdas/column/technique/hackerj.html] でも読んで勉強して欲しいところです。

■ 関連記事

詳細はこの日の詳細から

2001年03月26日(月)<< 前の日記 | 次の日記 >>
この日の詳細

■1 Amandaとオートローダー[http://www02.so-net.ne.jp/~masuda/diary/?200103c&to=200103262#200103262][freebsd]次の記事 >> このエントリーをはてなブックマークに追加

できます。ドキュメント *1 もあります。 やったことはありませんが、近い内に仕込む必要があるので情報収集の段階です。 うまくいったら、メモ程度は書く予定。
ちなみに、Amandaが通常想定している運用は、 全ての領域を1本のテープにとるということなので、 もし、毎日チェンジャを使ってフルダンプをとりたいという運用であれば、 それだけを目的とするスクリプト書いたほうが良いと思われます。
嬉しい状況は、
  • 毎日バックアップをとる
  • 全てのサーバの全領域のフルダンプはテープ1本に入らない
  • テープは毎日入れ替える
という状況です。
例えば、テープを15本セットにして番号を振っておきます。 とりたいサーバとディスクをコンフィグに書いておくと、 フルダンプと差分を取り混ぜながら、テープに入るように計算して、 自動的にバックアップをとってくれます。
戻すときは、指示されたテープを順番に入替えていけばOK。 テープの範囲で指定した日の状態に戻すことも可能です。
*1: TAPE.CHANGERS

■ 関連記事

■2逆リンクの自動生成[hns]<< 前の記事 | 次の記事 >> このエントリーをはてなブックマークに追加

を実現したら面白いかなと以前から思ってます。
もちろん手作業で取り込むことはできますし、 取り込みを支援する機能をlog.cgiに加えることは、それほど難しくはなさそうです。
そうではなくて、筆者が関与しないうちに日記内のリンクが拡張されていくというのも面白そうだと思いました。 link_logにターゲットとリンク元を書き込むのは比較的簡単にできますから、 日記を生成する時にlink_logをハッシュに取り込んでおいて、 リンクを生成していけば良さそうです。
問題が一つあって、これを実装するとキャッシュが使えなくなること。 逆リンクページを切り出すと、直感性が薄れて今ひとつです。
キャッシュとの両立は難しそうです。

■ 関連記事

■3 まだまだ行かない天国社[http://www.tengokusya.co.jp/]<< 前の記事 このエントリーをはてなブックマークに追加

なぜRefererに?新手のReferer広告か?
は良いとして,ここのCMソングはツボります。mp3でDL可能。

ひょっとして:

日記に取り上げてもらうのを狙ってますかね。 中身がないページでやられたら腹立ちますけど。CMソングがツボったので許しちゃいます。

■ 関連記事

詳細はこの日の詳細から

2001年03月27日(火)<< 前の日記 | 次の日記 >>
この日の詳細

■1 続・逆リンクの自動生成[http://www.nantoka.com/~kei/diary/?200103c&to=200103262#T200103262][hns] このエントリーをはてなブックマークに追加

実験。 日付指定[http://www.nantoka.com/~kei/diary/?200103c&to=200103260#T200103260] に調整が必要みたい。

調整したところ:

うまく動いているらしい。

考えてみると:

これって,他の読者にも注目記事が分かる仕組みですね。 いや,自分も読者なので便利なのですが。

パッチを[../dist/hns-2.10-pl0-linkto.patch]:

作ってみました。hns-2.10-pl0に対する差分の形です。
log/link_logが生成されるようになっています。 大きくなる一方ですから,ある程度のところで手作業で縮める必要があります。
テンプレートで'%linkto'が使えるように拡張されています。 japaneseテーマには反映してあります。
キャッシュはOffにしないと意味がないです。

■ 関連記事

詳細はこの日の詳細から

2001年03月28日(水)<< 前の日記 | 次の日記 >>
この日の詳細

■1 続・逆リンクの自動生成[http://www.nantoka.com/~kei/diary/?200103c&to=200103271#T200103271][hns]次の記事 >> このエントリーをはてなブックマークに追加

修正:

変なRefererと自分の日記をリンクしないように修正。

「僕の他にも」[http://www.commentout.com/people/takai/diary/?200103c&to=200103276#200103276]:

っていうのが分かるのも魅力の一つですね。

link_log[http://club.h14m.org/kenji/diary/?200103c&to=200103282#200103282]:

周りを追っていて,そういう意図があるんだろうなぁということは感じました。 うまくrefを生成してリンクを張る方法がないでしょうかね。

refの生成:

hns向きのURLということが判定できればできそう。 正規表現でそれっぽいのを引っ掛けるのはちょっと乱暴かも知れない。 新しいキーワードを作れば可能ですね。

■ 関連記事

■2今日のばんごはん[ごはん]<< 前の記事 | 次の記事 >> このエントリーをはてなブックマークに追加

思いついた。ハンバーグにしよう。

■ 関連記事

■3連続稼動[napster]<< 前の記事 | 次の記事 >> このエントリーをはてなブックマークに追加

ほぼ終日連続稼動中。MRTGで見ていると,ほとんどあるだけの帯域を使い切ってますね。

■ 関連記事

■4 BIND worm[http://www.securityfocus.com/archive/75/170684][セキュリティ]<< 前の記事 | 次の記事 >> このエントリーをはてなブックマークに追加

セキュリティホールmemo[http://www.st.ryukoku.ac.jp/~kjm/security/memo/2001/03.html#20010326_lion] より。
広まりだすと恐ろしいことになりそうなのですが,今のところは「猛威を揮っている」という感じではない模様。 バッファオーバーフローを使った攻撃で,環境の微妙な違いでうまくいかなかったりするので, そんなに広まっていないというところでしょうか。

■ 関連記事

■5 検索エンジンと Web 日記[http://clotho.KU3G.org/diary/?20010327#200103274][hns]<< 前の記事 | 次の記事 >> このエントリーをはてなブックマークに追加

確かに検索エンジンを使っていて,日記が引っかかることが多いというのは感じます。 その後の感想が違っていて,日記で有効な情報を得られることは多いと感じます。 というよりも,必要な情報が日記で見つかることが多いので,日記は貴重な情報源だと思っています。
これは検索エンジンの能力の問題で,今のほとんどの検索エンジンのAND検索が, 指定した語句が文脈にどのように出てくるかを意識しないというということから発生する問題だと思います。 検索エンジンにはまだまだがんばってもらいたいところです。
上手に検索させる実験として,ロボット用に1アーティクルずつ分割したコンテンツを作っておいて, ロボットからのアクセスの時はmod_rewriteを駆使してそちらのページを食わせることに チャレンジしたことがありましたが,ロボットをうまく見分けるのが難しくて挫折しました。

この感想は:

使っている検索エンジンに依存するのかも知れませんね。 最近のお気に入りは google[http://www.google.com/] です。

■ 関連記事

■6 段落アンカー[http://www.tk.airnet.ne.jp/~papanda/d/?20010328#id2001032824][hns]<< 前の記事 | 次の記事 >> このエントリーをはてなブックマークに追加

どうしようかなぁと考えていたですけど,結局書かずにはいられなかった。
サーバ管理者日誌は, 書き始めたころ[http://www.nantoka.com/~kei/diary/?199810b&to=199810140#T199810140] は静的なページを手作業で生成していたのですが, 去年の今ごろ[http://www.nantoka.com/~kei/diary/?200003c&to=200003311#T200003311] にhnsに出会って,アーティクル毎のリンクやアクセス解析ができるようになって, これは静的に生成してアクセス解析をしない日記とは「別物」だと思うようになりました。 コンテンツを供給する仕組みというよりは,ある種のコミュニケーションツールだと感じています。
コミュニケーションツールとしてとらえると,不特定多数を相手にしたコミュニケーションを行う訳ですから, それなりの覚悟が必要だと思います。

悪意のリンク[http://www.tk.airnet.ne.jp/~papanda/d/?20010328#id2001032842]:

よりも,こちらに知る方法がないところで取り上げられるほうがいや。
ファイヤウォールの中らしき掲示板で話題になっているらしいという状況には, hnsに慣れてしまってからは欲求不満(?)を感じるようになりました。
相手のページにリンクが張られている場合は,逆リンクを辿って誤解や間違いがあれば, こちらのページで説明することができます。 全ての人を納得させることは難しいかも知れませんが, 少なくとも説明する機会が与えられます。

逆リンク:

の公開を試験運用していますが,これはリンクに関して筆者のフィルタが掛からないシステムです。 期待しない内容のリンクであっても自動的に載る訳です。
コミュニケーションツールとしてみた場合,逆リンク情報の開示が寄与する効果は大きいと信じるのですが, 筆者がそれを運用しきれるかどうかが試されると思います。

そういえば:

2chあたりからリンク張られていて,何が書いてあったのか分からない時ってやっぱり不安。 明らかに批判されてる場合よりも不安ですね。

考えてみると[http://www.fastwave.gr.jp/diarysrv/mad-p/200103c.html#20010327-4]:

段落アンカーを付けることとリンク解析をついついセットにして考えてしまいますが, 段落orアーティクルアンカーを付けると,
  • リンク先を明示しやすい(読者orつっこみのメリット)
  • リンク先を絞り込んで批判とか曲解をされるリスク(筆者のデメリット)
いうことになって,確かに筆者には読者への配慮以上のメリットがない様に思えたりもします。 もちろん,みんながこうやってくれると嬉しいというのは同感です。 参照性があがるし時間が経っても役立つページになるでしょう。
これとリンク解析を組み合わせると,
  • リンクがどこからどこに張られたのか(筆者のメリット?)
が分かるので,コミュニケーションが双方向になる可能性が出てきます。 私はこれをメリットだと思うのですが,そうは思わない方もいるでしょう。 そういう人は,段落リンクもリンク解析もすべきではないのかも知れません。

■ 関連記事

■7 年刊 BSD magazine[http://www.ascii.co.jp/books/detail/4-7561/4-7561-3763-6.html][freebsd]<< 前の記事 | 次の記事 >> このエントリーをはてなブックマークに追加

■ 関連記事

■8 おめでとうございます[http://www.spnet.ne.jp/~tatsu/d/200103c.shtml#2602][ぐる]<< 前の記事 | 次の記事 >> このエントリーをはてなブックマークに追加

惜しい!

■ 関連記事

■9 パケットのイメージ[http://t-code.org/~rui/diary/?20010327S1&to=200103271][ぐる]<< 前の記事 このエントリーをはてなブックマークに追加

小包[http://www.1783.org/diary/index.cgi?200103c&to=200103283#200103283] はそのままパケットですね。
私の画像としてのイメージは,帯状のものに各階層のヘッダやペイロードが書いてある感じ。 これを巨視的にみると紐状になって空間を飛んでいる形ですね。 飛ぶときには,「ピーギャラギャラ」とか「ザー」とかいう音がします。
パケットのイメージがAX25とかKPCとかの時代に作られたので,音が付いてるし空中を飛ぶのでしょう。 アマチュア無線のパケットって,人間の認識が追いつける速度でパケットによる通信を見せてくれるので, 教材にすごく良いと思います。

■ 関連記事

詳細はこの日の詳細から

2001年03月29日(木)<< 前の日記 | 次の日記 >>
この日の詳細

■1 新リンク方式[http://club.h14m.org/kenji/diary/?200103c&to=200103282S1#200103282S1][hns] このエントリーをはてなブックマークに追加

なるほど。'ref=here'を「ref解釈能力がありますキーワード」として扱うわけですね。 実現するとして,ロードマップは,
  1. 標準添付のThemeのセクション等のタグに,ref=hereキーワードを埋め込む
  2. HNS.pmのlink_logの書き出し部で相手がrefを解釈してくれているかどうか判定する
  3. LINK,LNEW,LSUB等のリンク系コマンドに手を加えて,hereキーワードを置換する
  4. log.cgiにlink_logの解析機能を加える
  5. (逆リンク自動反映)
という感じでしょうか。 ある程度多数の人が導入しないと役に立たないので, どこかのリリースで取り入れてもらえるようだったら *1 やってみたいですね。

逆リンク解析支援:

'&ref=here'を含んだリンクを書き込んだときに、 hereキーワード部分を自分の日記のアーティクルを特定できるURIに書き換えてやれば良いんだけれども、 段落を指すURIをそのまま返すと既存のシステムが混乱しますから、 この辺りの書式にもう少し合意事項が必要ですね。 例えば、yyyymmddnn[SF]ssだと決めてしまえばそれでよい訳ですが、 これを受け取った相手のシステムは、これをもとに相手の日記を参照したい筈で、 そうなるとhnsに閉じた話ではなくなってしまいます。
これさえ決めてしまえば、実装はCommand.pmのAsHTMLのスーパークラスでちょいちょいしてやれば 実現できそうです。

以前にも[http://www.nantoka.com/~kei/diary/?200005b&to=200005112S2&ref=here#T200005112S2]:

引数統一されればなぁとか言っていましたね。 hnsの場合、yyyymmddnn[SF]ss形式を受け取った時に、少なくともyyyymmddと同様に解釈してくれれば、 上の形式で行こうかと思ったのですが。

ちょっと実験[http://www.nantoka.com/~kei/diary/?200103c&to=200103291&ref=here#T200103291]:

失敗。
*1: 大多数のユーザーに受け入れられるかどうか。 普及しなかったら技術的には可能でもあんまり嬉しくない類のことなので。

■ 関連記事

詳細はこの日の詳細から

2001年03月30日(金)<< 前の日記 | 次の日記 >>
この日の詳細

■1 逆リンクにGo![http://www.1783.org/diary/?200103c&to=200103302#200103302][hns]次の記事 >> このエントリーをはてなブックマークに追加

導入ありがとうございます。
現在の課題は,同じ個所からのリンクでも読者によってURIがまちまちなので, なると(@)がたくさん表示されることです。
この問題は,帰ってきた「新リンク方式」が実現されたときに解決される予定です。

新リンク方式:

解決しようとする問題は,
  1. Refererでは同じ個所からのリンクが様々な形式で表示されるため未読を探しにくい(識別したい)
  2. 逆リンクを張られた時にどのセクションから張られたのか分からない(リンク元を知りたい)
このために,refテクノロジでは,
  1. 相手方にリンクを張るときに'ref=識別子'の形式によって,こちらのセクション情報を引き渡す
  2. 上記1の'ref=識別子'形式を理解できる日記は,自分自身のセクション(or段落)リンクに,'ref=here'なるキーワードを含める
  3. 'ref=識別子'を生成できる日記では,LINKを張るときに,'ref=here'を'ref=識別子'に置換する
ということを行います。
問題になるのは識別子の決め方です。問題(1)を解決するためには, 識別子は一意であれば何でも構いません。 (2)を解決するためには,refテクノロジを導入する日記間での合意が必要になると思われます。
考えられる識別子として,
  1. hnsでいうところの#nameの内容を使う(hnsではこれは一意になります)。'http://日記パス/?識別子#識別子'でアクセスできることを保証する
  2. URIフルパス表記とする
(2)のフルパスをRefererの情報で補完することによって圧縮する案は,本質的には(2)と等価でしょう。
(1)を採用した場合,例えばhnsでは'http://日記URL/?引数#name'の引数として'200103301S1'等が 受け取れるように改造する必要があります。 また,静的に'200103.html'等を生成している日記では対応が困難だと思われます。
(2)のフルパス表記及びその応用では,恐らくURLエンコーディングをしないといけないので, 生成側・逆リンク解析側ともに負担が増えますし,引数が長くなるのがちょっとイヤです *1 。 引数を縮める方法としては,Refererの最後のスラッシュ以下をエンコーディングするのが有効だと思われます。 例えば,'ref=?20010330#20010330S1'あるいは'ref=200103.html#20010330'(共に実際に引き渡すときはエンコーディングの必要がある)となります。

結局:

'here=ref'を埋め込んだ人は, 自分がどのセクションからリンクされたか知りたい[http://club.h14m.org/kenji/diary/?200103c&to=200103303#200103303] 人なので,置換された後のref=識別子が分かりにくくても長くても,それがあなたの望んだものだから,URIを丸ごとエンコーディングして渡すのが良いような気がしてきました。 また,中途半端に圧縮すると互換性の問題を生じる恐れがあります。
上の記事から辿れる リンク補足機能[http://www.etl.go.jp/~kfujiwar/message/messagehelp.html#link3] もURI丸ごとエンコーディング方式ですし,hnsのlink_logの実装もそれを期待している様です。

refテクノロジ対応日記システムの分類:

こちらにもメモを残します。
  • A. LINKにref=hereを見つけると、そのセクションの一意な識別子を返す
  • B. Aの識別子からその記事のURIが特定できる
  • C. 「ref=識別子」を食べても大丈夫
  • D. 「ref=識別子」を利用した逆リンク解析ができる
  • E. 自分向けリンクに「ref=here」が埋め込まれている
A,Bは、相手の日記に分析結果を提供するための機能。 C,D,Eは、自分が分析をするために必要な機能です。 Eを満たしているものは、C,Dは満たしている筈(ということを期待している)。
Aを満たすけれども、Bを満たさないシステムはあるかも知れない。 C,D,Eを満たすけれども、Aを満たさない残念なシステムもあるかも知れない。 A,Bを満たすけれど、C,D,Eには興味が無いシステムもあるかも知れない。

ref引数を圧縮するなら:

HTTP_REFERERからの相対パス表記を*can*にすれば良いですが、 実際にはこれを保証するのは難しいかも知れない。
ref引数の置換を行う場合、日記に記述したリンクの'ref=here'を、 'ref=識別子'に置換します。
識別子は日記内でユニークでなければなりません。 識別子によってリンク元を明示したい場合、識別子はURIである必要があります。 識別子をURIとする場合、URIは絶対パスあるいは考えられるHTTP_REFERERからの相対パスによって表現することができます。
*1: 圧縮すれば短くはなりますが,見た目として美しくないという問題は残ります。 'ref=%3f20010330%2320010330S1'等。

■ 関連記事

■2ぐるぐるします[ぐる]<< 前の記事 | 次の記事 >> このエントリーをはてなブックマークに追加

今日は 日記バード[http://www.nantoka.com/~kei/nb/] からのスタートです。

n年日記[http://www.yomogi.sakura.ne.jp/~hiro/diary/?200103c&to=200103291#200103291]:

n年続けようという意欲のためのデフォルト表示ということで。

Sound Engineeringのページ[http://ottotto.com/sound/index.html]:

ねぎ式[http://clotho.KU3G.org/diary/?20010329#200103291] より。
その昔,放送部あたりで活動してた頃を思い出すけれども,はるかにハイレベル。

あなたの超能力測定します[http://members.tripod.co.jp/shakasenz/esp/esp_top.htm]:

INTERNET Watch[http://www.watch.impress.co.jp/internet/www/wtoday/index.htm] より。
透視能力も予知能力もなかったけれど,石を割るのには成功したらしい。

ProjectX 〜 KAMEプロジェクト[http://homepage1.nifty.com/susho/diary/2001/03.html#30]:

必見ですね。

東京ペンクラブ メイド研究会[http://www.geocities.co.jp/WallStreet-Stock/3500/]:

いや、chmoe o+maidとかのビットはたっていないんですが、これはすごいと思ったです。
「おことば」の履歴[http://village.infoweb.ne.jp/~fxba0022/okotoba/0103okotoba.html#20010330] より。 MAID CAFE[http://www.mangazoo.com/news/news.php3?id=561] は行ってみても良いかな。秋葉原というのが狙っていますね。 長崎にもそもそも制服がメイド服な喫茶店があったと思いましたが、 特にその時は意識しなかったですね。

■ 関連記事

■3 Perlメモ[http://www.din.or.jp/~ohzaki/perl.htm][CLIP]<< 前の記事 | 次の記事 >> このエントリーをはてなブックマークに追加

URIの正規表現,エンコーディング(エスケープ)について。
RFC2396[http://www.csl.sony.co.jp/cgi-bin/hyperrfc?2396] によれば,':'も'/'もエスケープしないといけないんですね。

■ 関連記事

■4 企業ネットワークへの攻撃者は内部にいる可能性が高い[http://www.watch.impress.co.jp/internet/www/article/2001/0330/kpmg.htm][セキュリティ]<< 前の記事 このエントリーをはてなブックマークに追加

内部の教育不足を含めたら,情報漏洩系のセキュリティ問題の大多数は内部に原因ありでしょう。
セキュリティ対策は費用対効果で考えないといけないのですが, コストバランスを考えるときに,内部犯行のコストを考えてみるのは参考になります。
例えば,あるサーバをネットワークからの侵入者(例えば企業スパイ)から守るためにどれくらいコストを掛けるかという問題は, ネットワークを通じて侵入するコストが,内部のスタッフを買収するコストより大きくなれば十分(あるいはそれ以上は無意味)という考え方です。
もちろんリスク回避となるとまた状況は違ってきますが,セキュリティに掛けるべき費用を考える上で, 内部スタッフの教育やモラルのコストに目を向けることは大切だと思います。

■ 関連記事

詳細はこの日の詳細から

2001年03月31日()<< 前の日記 | 次の日記 >>
この日の詳細

■1 リンク元を一意に[http://catv-8-109.medias.ne.jp:10080/~takayuki/diary/?200103c&to=200103302#200103302][hns]次の記事 >> このエントリーをはてなブックマークに追加

結局,Refererに頼るのは限界があるということになると思います。 大文字・小文字が混じるのもURIをきちんとパースしてやれば, ドメインパートは小文字に統一とかできると思いますが, リンク元の自己申告ならば好きなように表示させることができます。

■ 関連記事

■2 逆リンク機能[http://www.nantoka.com/~kei/diary/?200103c&to=200103301&ref=here#T200103301][hns]<< 前の記事 | 次の記事 >> このエントリーをはてなブックマークに追加

しばらく実験してみて、いくつかの課題が明らかになりました。ご協力ありがとうございます。
まず、 ナルト増殖問題[http://catv-8-109.medias.ne.jp:10080/~takayuki/diary/?200103c&to=200103302#200103302] として、読者によってRefererが違うので、実際は同じ部分からの逆リンクでも山のように並んでしまう問題があげられます。 リンク元とそれに興味を持ってリンクを辿った読者数の目安になるという見方もありますが、 同じ部分から辿ったリンクは一つしか表示したくないという要求は当然にあると思います。
もうひとつは、 逆リンクからのReferer問題[http://www.dive-in.to/~tom/diary/?20010330#30-3-P1] で、特に新たな記述がある訳でもないのに、逆リンクを辿った読者が運んでくるRefererが大量に生成されるという問題が指摘されています。
いずれもにしても、Refererの持つ不確実性 *1 が原因ですから、技術的にはいずれの問題もrefテクノロジおよびrefテクノロジを応用した技術が普及することによって改善可能だと考えています。
*1: そもそも、論理的にどの部分からリンクが張られているということを知る機能をRefererに求める点に無理がありますから。

■ 関連記事

■3 日記テーマ[http://www.dive-in.to/~tom/diary/?200103c#30-8][hns]<< 前の記事 | 次の記事 >> このエントリーをはてなブックマークに追加

いじれることは良いことです。 カレンダー[http://hachi.haun.org/diary/200103c.html#3102] も筆者によっては便利だったりするので(私はこのカレンダーを主に使ってます)、 本当にいじれること重要。
ちなみに、先日付けの日記に予定書いちゃうっていうのも便利ですよ。

■ 関連記事

■4 日記バード[http://www.nantoka.com/~kei/nb/][ぐる]<< 前の記事 このエントリーをはてなブックマークに追加

日記バードを中心に、ログなどを取り混ぜて一回り。

東京ペンクラブメイド研究会[http://www.geocities.co.jp/WallStreet-Stock/3500/]:

ここ数日で 恐ろしいくらいカウンタがアップ[http://www2.neocity.to/treebbs/view.cgi?board=072/penclub&root=4&target=9&mode=tree&page=1] したらしいです。Web日記の影響力ってすごいですね。
近いうちに『メイド短歌』と『メイド法』もアップされるらしいので、要チェック。

続・ピンク診療着[http://www.1783.org/diary/?200103c&to=200103306#200103306]:

なんだか揺れてますか。乙女心?

■ 関連記事

詳細はこの日の詳細から

以上、21 日分です。

指定日の日記を表示

前月 2001年03月 翌月
1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30 31

最近の日記

2019年04月01日

新元号「令和」について

2019年03月23日

DXアンテナ ワイヤレスチューナー メディアコンセント DMC10F1

2019年02月17日

#例のグラボを活用する

2019年01月03日

シリーズ5・myHomeAlexaで自分のCDをかける

2018年12月25日

シリーズ4・英語の楽曲・アルバム・アーティスト名をカタカナに直す

2018年12月23日

シリーズ3: Echo Dotがやってきた

2018年12月19日

続・Echo Dotがやってきた

分野別タイトル一覧


全て
CLIP
SYA!nikki
book
freebsd
hns
magic
おさけ
おしごと
お買いもの
ぐる
ごはん
アクセシビリティ
オープンソース
セキュリティ
音楽
地域情報化
電子自治体
日記

keikuma on Twitter

keikuma Name:前田勝之
Location:長崎市
Web:http://www.nantok...
Bio:前田勝之(まえだかつゆき)。長崎在住。コンサル、SE、プログラマー、 なんとか株式会社代表、非常勤講師(情報セキュリティ)。 セキュアド、テクニカルエンジニア(SV,NW)。サーバ管理とWeb日記を10年ほど。 ネットとリアルの接点に関心あり。食べること・歌うこと・愛すること・作ること・飲むこと。おいしいものがぜんぶすき。

サイト内検索

Google AdSense

Powered by hns-2.19.9, HyperNikkiSystem Project