日記 †

少し調べてみると、すくなくとも luks を利用しない dm-crypt の暗号化デバイスについては、cryptsetup にて resize というオプションが提供されており、 luks の場合であっても luksOpen した後のデバイスについて resize をすればよいという記述が何箇所かに見つかった。

ただ、luks での利用方法については、オフィシャルな記述が発見できなかった。裏づけを取らずに運用中のデータに適用するのも気が引けたので、ちょっとcryptsetup のソースコードをあたってみた。結論としては、上記のリサイズ方法で問題がないと思われる。

luks は通常の暗号化ブロックの先頭に、ヘッダの形で管理データを保持しており、 (lib/setup.c: __crypt_luks_open(), luks/keymanage.c: LUKS_read_phdr() ) ペイロード部分の初期化とデバイスへのマッピングには、 luks (cryptsetup luksOpen) と non-luks (cryptsetup create) で最終的に同じ関数 (lib/libdevmapper.c: dm_create_device() ) が呼ばれていた。おそらく、luksOpen した後のデバイスに resize を行うことは問題ないのではないかと思われる。 luks の固有データ（ヘッダ部分）にペイロード長があるとまずいが、少し眺めた範囲では発見できなかった。 (luks/luks.h: struct luks_phdr)

と、いうことで、自家用のやつも、

mdadm raid1 - dm-crypt - LVM - ext3fs

から

mdadm raid1 - LVM - dm-crypt - ext3fs

に変えようかなぁ。

↑

サイズの管理 †

確認中

メタデータなどでの永続的な管理は行っていないように見える。下層のブロックデバイスのサイズ上限まで使えそうな。もしかすると cryptsetup resize はオンラインリサイズのためのコマンドで、たとえば LVM の LV を増やして luksOpen すると、その上位の dm-crypt デバイスは自動的にリサイズしそうなコードに読める。もうちょっと読んで、あとで実験してみようと思う。

まぁ、位置に依存する情報って、ブロック（セクタ？）の番号を iv の種に使うくらいだから、サイズが変わっても問題ないし、一番単純なレイヤーであるはずの生の dm-crypt で管理するだけ無駄だよなぁ。

2008/4/8 (火)

Linux で eSATA + Port multiplier †

mdadm とか、dm-crypt とか調べた結果裸族の二世帯住宅で、外部バックアップディスクを作ることにした。これは USB2.0 と eSATA のインターフェイスを持っており、最初は USB2.0 で利用しようかと思っていた。しかし、USB2.0 経由では SMART での情報取得がうまくいかなかったことと、 USB2.0 と比較して eSATA のほうが 150/60 = 2.5 倍ほど高速らしいので SATA2E2-PCIe(Sil3132) を買ってみた。

ところが eSATA で見ると二台あるはずのディスクが一台しか見えず、 vanilla linux-2.6.22.19 では Port Multiplier に対応していないことが判明。

Linux板のスレによれば2.6.18-2.6.23 まではパッチ当てで OK. 2.6.24 からは vanilla kernel で OK らしい。

2.6.24 では VMWare server が素でうごかなそうなので 2.6.22 で止めておいたのだが、しょうがないからに上げるか。

あと、PortMultiplier への対応には、 SATA コントローラー個別の対応が必要っぽい話がところどころで出ていた。

↑

sil3124, 3132 チップのバグ？ †

Port Multiplier がちゃんと動かないのはチップのバグだと。しかし、カーネルの Changelog ってでかいのね。2.6.24 のやつは 5.8M もあった。git で自動生成だからかな？

commit 13cc546be3060324de9d92ebde3bc9dbd950df23
Author: ***
Date:   Thu Jan 10 15:47:56 2008 +0900

   sata_sil24: prevent hba lockup when pass-through ATA commands are used

   Fix commands timeout with Sil3124/3132 based HBA when pass-through ATA
   commands [where ATA_QCFLAG_RESULT_TF is set] are used while other
   commands are active on other devices connected to the same port with a
   Port Multiplier.  Due to a hardware bug, these commands must be sent
   alone, like ATAPI commands.

↑

fstab でのラベル指定 †

何で使うのかと思っていたら、デバイスが増えて /dev/sdX とかが変わっちゃったときの保険なのね。デバイスへは、tune2fs, e2label, xfs_admin とかで設定、確認できるみたいだ。

↑

mkinitramfs + Label †

echo ROOT=UUID=1234.... >> /etc/initramfs-tools/initramfs.conf

とか

echo ROOT=LABEL=hogefuga >> /etc/initramfs-tools/initramfs.conf

とかしておけばよいみたい。

ついでに、

/etc/initramfs-tools/initramfs.conf

に

MODULES=most

とか指定してあっても、この most は initramfs に組み込まれるだけであって、ロードされるわけではないのか。モジュールは入っているはずなのにカーネルパニックになっていて不思議だった。私の環境の場合、

sata_nv
xfs

を追加して OK だった。

ところで、initramfs で作成される initrd イメージは

zcat initrd.img | cpio -i

とかで簡単に解けるので助かった。自分の状況に良くマッチしたドキュメントが見つからなかったので、内部に含まれている init スクリプトを読みながら試行錯誤することで問題解決できた。

2008/4/5 (土)

Linux での UDP を利用するサーバアプリケーションとマルチホーム †

今日は支離滅裂文章だ。

マルチホームしているサーバで UDP を取り扱おうとすると、結構都合が悪い。

アドレス : aX, aY
インターフェイス : iX, iY

としたときに、iY から入ってくるパケットのあて先として aX, aY 両方が混在していると、この双方に適切なソースアドレスをもつ返信をするのは面倒だ。

アプリケーションレイヤで対処するならば、setsockopt で IP_PKTINFO を有効にして、パケットと同時に、受信したインターフェイスの情報を受け取り、 sendmsg の際に、それを利用して source アドレスを設定すればいいみたい。

まぁ、IP_PKTINFO を利用しなくても、socket per interface で複数ソケットを使って送り分けすればよいわけだ。

いずれにしても、受信インターフェイスの情報を受信した段階からずっと持って回らなければならず、まったくもって面倒だ。

iY から入ってくるメッセージが aX, aY どちらか片方のみあて先とするならば、状況が多少単純になる。 aY 宛てのみであればサーバソケットを一切 bind しなければOKとなる。この場合、ルーティングによって決定されるインターフェイス（iX,iY）に基づいてソースアドレスが決定され、 iX から送られるパケットには aX が、iY から送られるパケットには aY がソースとして利用される。逆に、すべてのパケットが aX 宛てであれば aX にサーバソケットを bind しておくことで、全部のパケットが aX から送信されていることになる・・・と思う。（未確認）

んが、bind しちゃうと、確実なローカル通信として便利な lo が（おそらく）使えなくなる・・・だるいな。意外と送れたりして･･･？ Python で手抜きサーバでも作って確認してみるべきか。

次の項に詳細は書いてあるが、確認したところ問題ないようだった。受信は 127.0.0.1 とメインのアドレスから行い、送信はメインのアドレスのみから行うことで、 lo + メインのアドレスでの送受信が問題なく可能なようだ。

↑

bind したソケットから 127.0.0.1 への sendto †

確認してみた。問題ないようだ。通常の eth0 などのアドレスにバインドした udp socket から、 127.0.0.1 に sendto してみたらちゃんと受信できた。カーネルバージョンに依存して変わる、とかだと困るけど･･･。さすがにないとは思ったが一応確認して、2.4.20-18.7(RH7.3) と 2.6.22.19(vanilla) で OK なことを確認した。

Server

#! /usr/bin/python
import socket as so
def loop():
    s = so.socket( so.AF_INET, so.SOCK_DGRAM )
    s.bind( ("127.0.0.1", 4000) )
    while True:
        d, a = s.recvfrom(8192)
        print d, a
        continue
    return
loop()

Client

#! /usr/bin/python
import socket as so
def send():
    s = so.socket( so.AF_INET, so.SOCK_DGRAM )
    s.bind( ("10.1.1.2", 5000) )
    s.sendto( "hello", 0, ("127.0.0.1", 4000) )
    return
send()

出力

hello ('10.1.1.2', 5000)

↑

複数プロバイダを利用してサービスを提供するときに使えそうなルーティング †

iproute2 を利用すると、複数のインターフェイスがある中から、パケットが入ってきたインターフェイスに返信するなんてことができるみたいだ。bind していない UDP ソケットであれば、適切なソースアドレスが選ばれるのだと思う。

・・・ひとつの IP から、両方のインターフェイスにアクセスがあったら問題になりそうだ。

しかしマルチホームで UDP 使おうとするとほんと厄介だなぁ･･･

2008/4/4 (金)

dm-crypt †

また脈絡なし。

LUKS っていうのを使うと、パスフレーズ以外の情報を覚えておく必要がなくなるっぽい。オフライン時に流失を防ぐという意味ではパスフレーズおよび暗号鍵がもれなければ良いので、強度的には十分であり、確かに便利かも。

losetup -e aes とか毎回やってるけど、確かに面倒だもんな。 mount をすると自動で聞いてきてくれるならば、確かに楽だ。

ESSIV を使うと、 IV (initialization vector) が予測可能であることに依存した Watermarking attack を回避できるらしい。 ESSIV が強度を向上させることはわかるのだが、 IV が予測可能ではあるがループしないような条件で Watermarking attack を行う具体的な方法が簡単には想像がつかない。同一 IV 同一データ同一キーとかになっちゃまずいのは簡単に想像がつくんだけど。

ESSIV 自体は IV = encrypt(sector_index, hask(key) ) として、IV を攻撃者から予測不能にする、という方法をとるらしい。実装で key をどこから取るかにも依存するのだろうけれど、生 key を使わないのはメモリとかから漏れることを防止するためだろうか。

↑

mdadm + udev †

array を --create で作成しようとして、デバイスファイル(/dev/mdX とか)がないと怒られる場合、-a ( --auto ) オプションを調べてみるとよい。(from 2ch debian スレ過去ログ)

2008/4/1 (火)

ext3fs †

分裂文章だがとりあえず残しておく。

ext3fs のジャーナルには 3 モードあって、tune2fs で調整できるようだ。

journal_data: フルジャーナル。データとメタデータのアトミックな更新が保障される。
journal_data_ordered: データを先に書いて、メタデータのみジャーナル？。ディスクの空き領域のゴミを拾うことがない。
journal_data_writeback: メタデータ更新後にデータを書く。データの書き込みが行われる前に落ちると、データが書かれる予定だった領域に書かれていたゴミを、ファイルとして取り込んでしまう可能性がある。

Linux 上でフルジャーナルができるのは ext3 だけらしい。 e2fs -> reiserfs(reiser3) -> XFS と使ってきていて、 fsck が不要だという理由で linux-2.4.1x の頃からカーネルにパッチ当てまでして XFS を利用していた。しかし XFS は2, 3ヶ月に一度程度の、結構な頻度でカーネルスタックトレースを吐いて落ちる。 1 つのパーティションやディスクで落ちると、他のディスクでも動作しなくなる上、データの破壊がそれなりの頻度で発生する。

場合によって fsck が発生するにせよ、結構な頻度でエラーとデータの破壊が発生してしまう XFS よりは、安定して使えそうで、パフォーマンスが落ちるのを我慢すれば、さらにフルジャーナルが利用可能な ext3 を使うほうがよさそうだと思い始めている。

ちなみに fsck をやらないと、どんな害があるんだっけな。起動しっぱなしであれば、そもそも動作しないものだし、（孤立した領域とか i-node とか、）ディスクに多少ゴミが残る程度であれば、定期的な実行は無効にしちゃっても良いと思う。

2008/3/26 (水)

Software RAID by mdadm + Encrypted Filesystem with dm-crypt †

簡単にできるっぽい。最近は自宅のマシンでもコア数増えて CPU パワーあまってるし、メンテ出来るならば広汎にやってもよいとおもう。会社のでもやってもよいと思うのだけれど、どうしようかな・・・ハードウェアエラーに対する耐性が落ちるのをどれだけ影響があると見るか、なのかなぁ。

スピードを重視するならば、アルゴリズムに AES とかサーペントを使わずに TwoFish、データは RAID5, swap は RAID0 にしておけと書いてある。RAID0 にする意味があるということは、一応スピードに関して暗号化の計算量がネックではなく I/O 速度がネックになってるってことか？あと、conservative な Journaling をする、ext3 を使え、とある。メタデータだけのジャーナリングじゃやばいと。

会社の場合、データを暗号化してあるから HDD そのまま修理に出して OK という理屈にならずに、何が何でもデータ初期化ツールで一回消せ、とか言われそうだから、ルールに関係なく守りたいような、よほど重要なデータをアクセス管理付で保護する時くらいしか意味無いか。オフィシャルなデータ消去方法として認めさせるのは無理だろうし。

↑

システムの構造 †

FileSystem - LVM2 - dm-crypt - mdadm RAID - device

ってなるみたい。たしかに、

FileSystem - LVM2 - mdadm RAID - dm-crypt - device

とかやっちゃうと暗号化が冗長度に応じて 2 倍以上必要になってうざいもんなぁ。

2008/3/23 (日)

労働の性質 †

かれこれ多分 6 時間くらいは調査検討している気がするんだが、仕事しているときとぜんぜん疲労感が違う。

昔（あえて昔と書こう）は仕事していても今日のような感じであまり疲れることがなかったのだが、最近は 2, 3 時間で疲弊してきて標準の勤務時間が終わるころにはやる気を使い果たした感じで帰る気満々になってることが多い。

歳のせいかと思っていたけど・・・まぁ、さっさと帰る気になる、というのも、それはそれでよいことだと思うのだけれど、あまり疲れ果てずに帰りたいものだ。

↑

dm-crypt とか LVM とか †

何が入っているか良くわからないデータがあるので、外付けディスクにとりあえず丸々暗号化して吐き出しておこうか。
パーティション丸々にイメージを作成しての cryptoloop だと効率悪そう。
dm-crypt ってのがあるらしい
LVM とかと関係あるんか？

などというチェインで、LVM を調べている。複数物理デバイスを 1 パーティションにできるらしいけれど、障害発生率は直列システムとして上昇するんだよな？復旧とか簡単なのだろうか・・・

そのレベルは RAID とかで対処よろwww とかなんかなぁ。

何が入っているか良くわからないデータ、ってちょっと変な日本語だ。ディスクの特定領域に何が入っているか良くわからなくて、細かく調べるのもちょっと面倒、ということなんだが、うまく表現しづらい。

↑

障害耐性 †

結局、2ch で実験結果を見つけた。参考になる。GJ >>135 だ。物理ボリューム PV1, PV2 があったとして、 PV2 を利用していない状態で PV2 のみが飛んでも問題なく復旧できる。データが存在する PV2 が完全に飛ぶとかなりのデータが飛ぶ。（意図的ではないものの、ストライピング的な動作をしているため、多分半分以上）

PV2 の部分損傷については実験されていなかったので、操作の練習を兼ねて自分でやってみると良いんかな。

http://pc11.2ch.net/test/read.cgi/linux/1024122484/148-156

↑

まとめ †

LVM (LVM1) の後継として、LVM2 があり、それは device-mapper を利用して実装されているらしい。 device-mapper (dm) はブロックデバイスと論理デバイス？の間に入って、たとえば RAID 化や暗号化など、いろいろごにょごにょできるレイヤーみたいだ。

しかし、どうも名前が紛らわしい。こいつら、基本的に無関係なのね・・・ただ、device mapper はこれら双方の実装に関係がある、と。

dmraid: device mapper を使った偽ハードウェア RAID のサポート。(Intel Software RAID とか Silicon image のなんちゃら、とか。)
mdadm での raid: 完全に Linux の世界でのソフトウェア RAID. md=Multiple Devices

きっと、

VFS - FileSystem - LVM2 - device-mapper - device-driver - device

みたいな感じだと思われる。ところで、いわゆる buffer cache ってどこに入るんだろ？ device-mapper の上位のほうがパフォーマンスは出そうだが･･･

参考 URL

2008/1/27 (日)

Putty + GNU Screen + emacs でファンクションキーを使う @ Debian etch †

手許の環境で、上記の構成ではファンクションキーが使えていなかった。

CentOS4 では Fn が利用できたため調べてみたところ、下記の項目を .screenrc に追加することで利用可能となった。

# tell screen that xterm can switch to dark background and has function keys.
termcapinfo xterm 'VR=\E[?5h:VN=\E[?5l'
termcapinfo xterm 'k1=\E[11~:k2=\E[12~:k3=\E[13~:k4=\E[14~'
termcapinfo xterm 'kh=\EOH:kI=\E[2~:kD=\E[3~:kH=\EOF:kP=\E[5~:kN=\E[6~'

CentOS4 の /etc/screenrc を眺めていて見つけたのだがほかにも terminal の設定に関する hack がなにやらいろいろ書かれていた。

どうも、etch 標準の /etc/screenrc は、付加的な設定をいろいろ削除してあるらしい。

機能的に困った場合、GNU Screen オリジナルの screenrc や、他のディストリビューションの物を眺めてみるとよさそうだ。

ちなみに、上記の追加設定は、xterm の termcap/terminfo を拡張するもののようなので、 putty 側で端末タイプを変更することでも問題解決になるのかもしれない。

2008/1/23 (水)

読書ログ †

だいぶさぼってるな・・・最近読んだやつと、面白かったやつだけでも記録しておこう。

時砂の王 : 小川一水

エンターテインメントとしてよくできた時間物？小説。面白いし、ひさしぶりに SF 成分でゾクゾクできた。ここ最近読んだ十数冊では一番良かったと思う。一瞬の衝撃というか快感としては、エンダーのゲームに迫るくらいだと言ってしまおう。面倒なので箇条書きしちゃうと、

アイデア : （特にあら捜ししたわけではないが）破綻なくまとまっているし、十分に面白いと思う。

キャラ : 立場的には自然な振る舞いだけど、あれは、ツンデレと呼べる。きっと。

考証 : SF 的な前提に基づく考証にもとりあえず違和感を感じない

バビロニアウェーブ : 堀晃: 1988 年初版だそうで。ちょっともっさりしたかんじ。いうなれば、おっさんロマンチック SF 。ちゃんと全部読んだけど、そんなに好きじゃないかなぁ。
バビロニアウェーブ自体のアイデアは面白かった。どこかで、短編ならば良かったという感想を見たがそれに同意する。舞台装置なりガジェットをメインディッシュとしてしっかり味わうような短編ならば、この人の作品をまた読んでみても良いと感じる。

2008/1/15 (火)

Eee PC †

ちょっとほしいような。5万円のおもちゃか。 Debian つっこんで気楽に持ち運んだら面白そう。

もっとも、会社で個人利用している Vista が入っている 2 スピンドルのノート PC も 1kg くらいだし、重さからすると大差なかったりするんだよな。

それにも Debian いれてあるし。

2008/1/12 (土)

腱鞘炎？ †

手首痛い気がする。いやーん。

2008/1/5 (土)

超多言語フォント †

こちらのサイトによれば、Unicode の全文字集合を単一 TrueType/OpenType フォントで表示するのは、 MS も Apple もあきらめちゃったらしい。 ( MS と Apple は TrueType/OpenType 仕様の開発元。たぶん。)

まぁ、複数フォントをミックスしてレンダリングすればよいのだろうけど、気楽に使えるレンダラは世の中に広くあるのだろうが？手軽に実世界へのフィードバックが出来る実装が無いのでは、幻想の半分は潰えてしまっていると思う。データの管理は楽になるけど、統一的に表示できないのでは意味半減だ。

仕事でシステムの多言語化をしてるんだけど、 Unicode を利用しても単一フォントで済ませることが出来ないっていうのはネックになるかなぁ。最終的な UI のレンダラはある意味自前じゃないので、そいつが良きに計らってくれれば助かるんだけど。どうなんだろう。

↑

無ければ作る？ †

ところで、Arial Unicode MS 以外に超多言語向きフォントってないのだろうか。

品質にこだわらなければ、適当に複数 ttf をマージすればいいか？ FontForge とかで簡単に出来ないかな？。

2007/12/28 (金)

会社PC 壊れかけ †

個人用の Linux Desktop, Windows Desktop どっちもおかしい。 CPU ファンが壊れかけたり、ビデオカードのファンが壊れかけたり。こまったもんだ。

↑

etch 向け最新 Radeon 用ドライバ †

2008/1/20: まとめ記事を作製

ati もドライバを配布してるのだが、動作確認済み環境に Debian も含まれてた。

$ ./ati-driver-installer-8.443.1-x86.x86_64.run --listpkg
 ...
==================================================
 ATI Technologies Linux Driver Installer/Packager
==================================================
List of generatable packages:

Package Maintainer(s): Aric Cyr <*.*@gmail.com>
                      Mario Limonciello <*@gmail.com>
Status: Verified
Debian Packages:
        Debian/sarge
        Debian/oldstable
        Debian/sid
        Debian/unstable
        Debian/etch
        Debian/stable
        Debian/lenny
        Debian/testing
        Debian/experimental
...

なんて出てきて、

$ ./ati-driver-installer-8.443.1-x86.x86_64.run --buildpkg Debian/etch
Created directory fglrx-install.L27470
Verifying archive integrity... All good.
Uncompressing ATI Proprietary Linux Driver8.443.1
...
==================================================
 ATI Technologies Linux Driver Installer/Packager
==================================================
Generating package: Debian/etch
Package /home/ryu1/lab/ati/fglrx-driver_8.443.1-1_i386.deb has been successfully generated
Package /home/ryu1/lab/ati/fglrx-driver-dev_8.443.1-1_i386.deb has been successfully generated
Package /home/ryu1/lab/ati/fglrx-kernel-src_8.443.1-1_i386.deb has been successfully generated
Package /home/ryu1/lab/ati/fglrx-amdcccle_8.443.1-1_i386.deb has been successfully generated
Removing temporary directory: fglrx-install.L27470
$ ls -l
合計 61732
-rwxr-xr-x 1 ryu1 ryu1 48308870 2007-12-21 05:46 ati-driver-installer-8.443.1-x86.x86_64.run
-rw-r--r-- 1 ryu1 ryu1  5628992 2007-12-28 00:08 fglrx-amdcccle_8.443.1-1_i386.deb
-rw-r--r-- 1 ryu1 ryu1    40172 2007-12-28 00:08 fglrx-driver-dev_8.443.1-1_i386.deb
-rw-r--r-- 1 ryu1 ryu1  8130424 2007-12-28 00:08 fglrx-driver_8.443.1-1_i386.deb
-rw-rw-r-- 1 ryu1 ryu1     1123 2007-12-28 00:08 fglrx-installer_8.443.1-1_i386.changes
-rw-r--r-- 1 ryu1 ryu1  1092270 2007-12-28 00:08 fglrx-kernel-src_8.443.1-1_i386.deb

みたいに deb を作成してくれる。家の PC ではないのでまだ動作確認はできてないが、ここまでのところ、なかなか便利でよさそうだ。

製造元謹製だけあって、サポートしているデバイスは非常に多い。（まあ、vesa ドライバを使ってパフォーマンスを気にしなければ、そもそもほとんど動くのかもしれないけれど、デュアルヘッドがちゃんと使えるかとかは結構不安だ。）

↑

fglrx 1/1 追記 †

導入してみたところ、X 自体の動作には問題がなかったが、 X 終了後コンソールに戻るとコンソールがちらつく問題が発生した。

ちょっとちらつくとかいうヌルいものではなく、画面全体が真っ黒になるのと正常な状態で表示されるのが秒間数回程度きりかわるという、まったく以て目に悪い状態になった。

vesafb を導入/有効にして、vga=792 としてコンソールをフレームバッファで動作させたら問題が解決した。

↑

環境情報 †

fglrx 8.443
Xorg 7.1.0-19
linux-kernel 2.6.22-6
ASUS Vintage-AH1
- Socket 939 Athlon64X2
- ATI RS482
- ULi M1573

↑

カスタムカーネルでのフレームバッファコンソール †

使っていたカーネルで vga= を設定しただけではフレームバッファコンソールが使えず試行錯誤したのでメモしておく。試行は少ないのだけれど、毎回カーネルコンパイルなので時間がかかってしまった…

CONFIG_FB_VESA=Y

だけじゃなく、

CONFIG_FRAMEBUFFER_CONSOLE=Y

も必要。（気づけば当たり前だけれど。）

CONFIG_FRAMEBUFFER_CONSOLE=M

になっていて、コンソールが表示されずにしばらく悩んでしまった。

↑

カスタムカーネルの利点 †

昔、パッチあてが必要なカーネル拡張を利用していたので、そのまま惰性でカスタムカーネルを利用している。

debian stable （ときによっては old stable）を主に使っているので新しめのデバイスが使えないときとかに、ちょっと便利なことがある。

↑

make-kpkg の並列動作（並列コンパイル） †

環境変数で CONCURRENCY_LEVEL を指定することで make -j を指定できる。core 2 個で倍速ですよー。

2007/12/22 (土)

サラシモノ仲間 †

実名だしてる勇者がいるということで捜索、無事懐かしいお顔を発見。名前で検索してもひっかけてくれるのね。

似たような対象に向けたコンテンツってことは、同年代が掲載されてる可能性が高いってことか。ほかにも知り合いが載ってたりするんだろうな。

2007/12/5 (水)

サラシモノ †

匿名だけど、先輩紹介とかでリクナビに載るみたいだ。

2007/10/23 (火)

缶ポーション †

普通に美味い。このサイズでアノ味だったら大変なことだけれど。

次の20件>>

コンテンツ

ツール

自分用

最新の15件