nDiki : ファイルシステム

1999年1月26日 (火)

orion に Tripwire ASR 1.3 をインストール

Tripwire Security Systems, Inc. より Tripwire ASR 1.3 (tripwire-1.30-1.tar.gz) を入手し orion にインストール。 なお ASR は Academic Source Release の略。

tripwire はシステム中の実行可能ファイル、設定ファイルなど指定したファイルの変更があったかどうかを検証するツール。 システムがクラックされた場合、裏口を開ける機能をつけくわえた実行可能ファイルなどがインストールされたり、すでにあるものを置き換えたりされる可能性がある。 tripwire は事前に作成したファイルの情報のデータベースと、現在のファイルの情報を比較することによってこのような変更を検出することができる。

なおここでは、以下の環境、条件でインストール、設定を行った。

まずはパッケージ展開。適当な作業ディレクトリ上で。

 $tar zxvf tripwire-1.30-1.tar.gz
 $cd tripwire-1.30-1

次に Makefile の編集。 以下の2つの変数を値を書き換える。

 DESTDIR = /MO/tripwire/bin
 DATADIR = /MO/tripwire/var

次に OS 毎の設定ファイル。Ported をみると, conf-linux.h を使うようにかいてあるが、みあたらないので conf-sunos-4.1.h で代用する。

$emacs ./configs/conf-sunos-4.1.h

以下の通り変更する。

 #define DIRENT
 を
 #undef DIRENT
 に

最後に include/config.h を編集する。

 $emacs include/config.h

ここでは、os 別のインクルードファイルを読み込むようにするのと、各種ファイルへのパスを設定。

 #include "../configs/conf-svr4.h"
 を
 #include "../configs/conf-sunos-4.1.h"
 に。また以下の変数の値を変更。
 #define CONFIG_PATH "/MO/tripwire/etc"
 #define DATABASE_PATH "/MO/tripwire/var"

そして make。

 $make
 $make test

次に MO を準備する。 マウントする前にシングルユーザモードにし、インストール、ならびにデータベース作業中に他の誰かが悪行をできないようにしておく。

 $su
 #mkesfs /dev/sdb
 #mkdir /MO
 #init S
 #mount -t ext2 /dev/sdb /MO

そしてインストール

 #make install
 #mkdir /MO/tripwire/etc
 #cp configs/tw.conf.linux /MO/tripwire/etc/tw.config
 #emacs /MO/tripwire/etc/tw.config

とりあえず tw.config には自分でコンパイルしたカーネルファイルの指定を追加しておく。

そしてここから実際に使用。 まずは、現在のファイルの情報に関するデータベースを作成する。 終了すると、tripwire を実行したディレクトリに databases/tw.db_orion が作成される(orion の部分はホスト名がはいる)。 これを /MO/tripwire/var に移動しておく。

 #cd /MO/tripwire/bin
 #tripwire -v -initialize
 #mv databases/tw.db_orion /MO/tripwire/var

以上が終了したら、一旦 MO ディスクを抜き、書き込み禁止にしておく。 そしてマルチユーザーモードに戻す。 リブートしてしまう。

 #cd /
 #umount /MO
 #sync; sync; shutdown -r now

とりあえず検証してみる。Read-only でマウントし /MO/tripwire/bin/tripwire を実行する。

 #mount -t ext2 -r /dev/sdb /MO
 #/MO/tripwire/bin/tripwire

一応何も変更は検出されないはず。 と思ったら、いくつか追加されたファイルと変更されたファイルが検出。 モジュールの依存関係ファイルやら何やら。 これらのファイルはおいおい設定でチェックしないようにしなければ。

今後は cron 等で定期的にチェックするようにする設定を行う必要がある。 今日はもう遅いのでやめ。

なお本来は、tripwire のインストール場所、ファイルの位置などはできるだけわかりにくいようにする必要がある。 公開などしてはいけない(ここであくまでも例で、具体的な位置は異なっている)。

  • UNIX Magazine 96/7 pp.93-101
  • LINUX JAPAN Vol.5
スポンサード リンク
[ 1月26日全て ]

2004年1月5日 (月)

[ Debian ] GRUBソフトウェアRAID1 ブート設定

年末にうまくいかなかった「ソフトウェアRAID1なHDD2台両ブート」に再チャレンジ。 というか、既にネットワーク構成変更までに期限がないので頑張らないと。

Debian GNU/Linux Woody CD-ROMでブート

 bf24 ide0=0x1440,0x1436 ide1=0x1438,0x1432

で起動。cfdisk ではがつんと1パーティションにしてしまう(何度もパーティションを切りなおすのが嫌になったのと、やまだ君のところは1パーティションでやっているという話から)。

ドライバのところでは NIC が ELECOM Laneed LD-10/100 AL PCI Fast Ethernet Adapter なので via-rhine を追加。

後は普通に進めて再起動

GRUBインストール

 apt-get install grub raidtools2 emacs21 wget lv

GRUB

 grub-install --root-directory=/boot /dev/hda

stage1 ファイルが grub から見えないでエラーになる場合があった。 その場合は、再起動したら成功するようになった。

 update-grub

再起動。OK。GRUBで起動するようになった。

kernel オプションの追加

/boot/grub/menu.lst の kopt を編集

 # kopt=root=/dev/hda1 ro ide0=0x1440,0x1436 ide1=0x1438,0x1432

コメントマーク(#)を残さなければならない事に最初気がつかず。

 update-grub

再起動。OK。

kernel アップデート

年末に作ったRAIDを有効にしてある Linux kernelインストール。 /etc/kernel-img.conf に

 postinst_hook = /sbin/update-grub
 postrm_hook = /sbin/update-grub
 do_bootloader = no

を書いておいてから、

 dpkg --install kernel-image-2.4.18_gate.1.0_i386.deb

再起動。OK。

hdc を RAID1 に

cfdisk /dev/hdc で1パーティションに切り、タイプを fd に。 その後 /etc/raidtab を編集。

 raiddev                 /dev/md1
 raid-level              1
 nr-raid-disks           2
 chunk-size              64
 nr-spare-disks          0
 persistent-superblock   1
 device                  /dev/hdc1
 raid-disk               0
 device                  /dev/hda1
 failed-disk             1

書いたら hdc を RAID1にし、ext3 ファイルシステムを作成。

 mkraid /dev/md1
 mkfs.ext3 /dev/md1

hdc へシステムをコピー

シングルユーザモードで再起動し、/dev/md1 (hdc) へコピー。

 cd /
 mount /dev/md1 /mnt
 cp -a /bin /mnt/
 cp -a /boot /mnt/
 cp -a /cdrom /mnt/
 cp -a /dev /mnt/
 cp -a /etc /mnt/
 cp -a /floppy /mnt/
 cp -a /home /mnt/
 cp -a /initrd /mnt/
 cp -a /lib /mnt/
 cp -a /opt /mnt/
 cp -a /root /mnt/
 cp -a /sbin /mnt/
 cp -a /tmp /mnt/
 cp -a /usr /mnt/
 cp -a /var /mnt/
 cp -a /vmlinuz /mnt/
 cp -a /vmlinuz.old /mnt/
 mkdir /mnt/mnt
 mkdir /mnt/proc

/mnt/etc/fstab を編集し /dev/hda1 のところを /dev/md1 に。RAID1ディスクをルートパーティションにする。 書き換えたら

 /umount /mnt

し、再起動

 kernel /boot/vmlinuz-2.4.18 root=/dev/md1 ro ide0...

で起動できる事を確認。

GRUB での起動でも /dev/md1 を root に

/boot/grub/menu.lst を編集。kopt を

 # kopt=root=/dev/md1 ro ide0=0x1440,0x1436 ide1=0x1438,0x1432

に書き換え、update-grub。

hdc から起動できるように

grub-install で hda から起動できるように先にしてあるが、次に hdc 側からも起動できるように。 この段階では grub-install だとエラーになるので、grub で直接。

 grub
 grub> device (hd0) /dev/hdc
 grub> root (hd0,0)
 grub> install /boot/grub/stage1 d (hd0) /boot/grub/stage2 0x8000 (hd0,0)/boot/grub/menu.lst
 grub> quit
  • hda - 奥のラック - IDEカードの背面から遠い側のコネクタ
  • hdc - 手前のラック - IDEカード背面側のコネクタ

という構成になっているので hda 側のケーブルを抜き、hdc だけ接続した状態で起動してみる。OK。

hda 側を消して RAIDに参加 (失敗)

両方のHDDを接続してroot=dev/md1 で再起動。 cfdisk /dev/hda し、1パーティション・type fd に。

/etc/raidtab を編集。 /dev/hda1 を failed-disk から raid-disk にする。 で、

 raidhotadd /dev/md1 /dev/hda1
 md: trying to hot-add to md1 ...
 md1: disk size 80413248 blocks < array size 80418112
 /dev/md1: can not hot-add disk: too small disk!

あれ? cfdisk で確認。

 /dev/hdc
   16 Heads, 63 Sectors, 159560 Cylinders
   82348277760 bytes

 /hdc1 82348.28MB

 /dev/hda
   255 Heads, 63 Sectors, 10011 Cylinders
   82348277760 bytes

 /hda1 82343.28MB

おーまいがー。一緒に買ったディスクなのだが、パーティションを切ると5MB違う。

さて。 hda を /dev/md2 にして /dev/md1 -> /dev/md2 してから再度、hdc を /md2 にして... というのも思い浮かんだのだが、やっぱりあきらめて最初からやりなおす。 hda と hdc のケーブルを入れ換えて hdc 側に(ほんのちょっと)小さいディスクを配置。

  • hda - 手前のラック - IDEカード背面側のコネクタ
  • hdc - 奥のラック - IDEカードの背面から遠い側のコネクタ

で最初から、やりなおして次のセクションへ。

hda 側を消して RAIDに参加 (成功)

両方のHDDを接続してroot=dev/md1 で再起動。 cfdisk /dev/hda し、1パーティション・type fd に。

/etc/raidtab を編集。 /dev/hda1 を failed-disk から raid-disk にする。 で、

 raidhotadd /dev/md1 /dev/hda1

リカバリが始まる。

 lv /proc/mdstat

ちゃんとリカバリしている模様。年末にやった時は一瞬で終わってしまったのだが、あれ本当にリカバリしていたのかなぁ。今回はじめて recovery している様子が見れた。一安心。 560min ほどかかる予定。

swap 作成

RAID1上だと遅いんだろうな。メモ512MBなので、一応作っておく。

 dd if=/dev/zero of=/var/swap bs=1024 count=524288
 mkswap /var/swap
 swapon /var/swap
 lv /proc/swaps
 emacs /etc/fstab
 /var/swap none swap exec,dev,suid,rw,sw 0 0

RAIDのリカバリが時間がかかるので、hda 側でブート設定は明日にもちこし。 他の設定をちゃっちゃか始める。

以下予定

hda 側でのブート設定。

 grub
 grub> device (hd0) /dev/hda
 grub> root (hd0,0)
 grub> install /boot/grub/stage1 d (hd0) /boot/grub/stage2 0x8000 (hd0,0)/boot/grub/menu.lst
 grub> quit

で両方のHDDでブートできることと、データが複製されている事の確認をする事。

[ 1月5日全て ]

2005年1月17日 (月)

サーバのファイルシステムトラブル

dselect からアップデートをかけている時にエラー。 read only で書き込めないという主旨の。

???

チェックすると一般ユーザからも root からも全く書き込めない。

 EXT3-fs error (device md(9,1)) in start_transaction Jornal has aborted

エラーでまくり。 やばい。

libc6 とかのアップデート中なのでビビる。

[ 1月17日全て ]

2006年1月16日 (月)

USB HDD 上に ext3 ファイルシステムを作ろうとしたらフリーズ

[HD-H300U2 会社で使っている Linux サーバ (DELL PowerEdge 2600)内のファイルについて、バックアップをとっていないのがずっと不安であった。 なので、まずは外付け HDD を接続して pdumpfsバックアップしておくことにした。

以下の実作業は松下君が行ってくれたもの。

電源内蔵の HDD BUFFALO HD-H300U2 を購入。 比較的人気なのか、市場では品薄の様子。

購入時は FAT32 で1パーティションでフォーマットされている。 なんかいろいろソフトが入っているみたいだけれど、まあ使わないからいいや。 さっそく接続して mkfs.ext3ファイルシステムの作成。

ここでトラブル。

inode table を書き込んでいる途中で進行状況を示す数字のカウントアップがだんだん遅くなっていき最後には止まってしまった。 おかしいなと思っているうちに Linux 自体がフリーズ。 SSHWebも接続できないし、コンソールも反応なし。

一瞬「マズ。もしかして間違えて、システムの入っているパーティション指定しちゃった?」と思ったが、再起動すると問題なく立ち上がって一安心。

うーん。原因はなんだろう。いまだに Red Hat Linux 8.0 で Linux kernel も 2.4.20 のままなんだけれど、そのあたりに何かあるのだろうか。

[ 1月16日全て ]

2006年1月17日 (火)

ファイルシステム作成はノート PC でやっておいた

昨日のHDD問題であるが、今日再度試してみたもののやはり途中で止まってしまう。

しょうがないので自分のノート PC 上で ext3 ファイルシステムを作成してからあらためて接続。 マウントは DELL PowerEdge 2600でも問題なくできた。 cron で毎夜実行している pdumpfsバックアップ先を、USB HDD 側に変更しておく。 ちゃんと書き込めているか後で確認。

[ 1月17日全て ]

2006年2月23日 (木)

Debian Linux kernel 2.6.15 ビルド

ThinkPad X31 用に 2.6.15 の Debian kernel パッケージ構築を行う。 インストールしてある Debian 標準の 2.6.15 のパッケージの設定 /boot/config-2.6.15-1-686 をベースに設定を行いビルド

 #apt-get build-dep linux-image-2.6.15-1-686
 #exit
 $mkdir -p /usr/local/src/linux
 $cd /usr/local/src/linux
 $tar jxvf /usr/src/linux-source-2.6.15.tar.bz2
 $cd linux-source-2.6.15
 $cp /boot/config-2.6.15-1-686 .config
 $make menuconfig
 $make-kpkg clean
 $fakeroot make-kpkg --revision=sebastian.1.0 kernel_image
 $cd ..
 $su
 #dpkg -i linux-image-2.6.15_sebastian.1.0_i386.deb

ブート後 Kernel panic。

標準の設定では IDE 関係がモジュールになっているのを見落していた。もう一度設定を修正してビルドしなおして起動。 Linux を使い始めたころ ext2 をモジュールにして失敗したことがあり、ファイルシステム関連は忘れずチェックするようにしているのだが、IDE 関連はノーチェックだった。

MADWIFI

 module-assistant prepare
 module-assistant auto-install madwifi
[ 2月23日全て ]

2006年6月10日 (土)

WiKicker における PageName 最長文字数

WiKicker では PageName を エンコードした文字列を URI に埋め込んだり、サーバで保存する際のファイル名にしたりしている。 このため、PageName の最長文字数はそれらの最長文字数に依存しているはずである。

今まで確認を後回しにしていたのだが、新しい機能の追加の際に確認しておく必要があるので調査してみた。

WiKicker実装

WiKicker実装がらみとして最長を決める要素としては

がある。

仕様等による制約

  • HTTP では URI の長さには制限なし (RFC2616 3.2.1)
  • Web サーバは Request-URI が長いと 414 Request-URI Too Long を返す (RFC2616 10.4.15)。Apache は LimitRequestLine ディレクティブにより、URI を含むリクエスト行のサイズを制限することができる(配布時には 8190)。
  • Internet Explorer が扱える URL の長さは 2083文字。
  • ext2ファイル名は 255文字まで(増やすこともできる)。
  • 手元の Linux 2.6.15 で試したところ、パス名は 4095文字まで。

WiKicker で問題が出ない PageName 最長文字数

上記の中ではファイル名による制約が一番大きい。

WiKicker 内部でファイル名として base64 (の亜種) でエンコードしたものを使っているので、元の文字列はは最長 189バイトまでなければならない。base64 だと3バイトで4文字になるため、189バイトで 252文字となる。

WiKicker ではここでさらにファイル名に ',v'、'-lock' をつける事があるので、実際には元の文字列は最長 186 バイトまでとなる。

PageName が 186 バイトまでだとすると、URL エスケープしたとして558バイト。 WikiEngine のスクリプトの URL や他のパラメータとあわせても、これぐらいなら大丈夫のはずである。

ということで WiKicker では Linux 上だと通常 PageName は 186 バイトが最長と言ってよさそうだ。 日本語の文字はだいたい UTF-8 で3バイトになるので、62 文字までということになる。

そのうち、WiKicker に制約チェックを入れることにしよう。 そのうち。

[ 6月10日全て ]

2006年8月8日 (火)

Linux で使えるデスクトップ検索ツール Beagle でローカルファイルを検索

Windows だと Google Desktop でローカルファイルの検索ができるのだが、残念ながら Linux 版はでていない。 そこで Beagle を入れてみることにした。

Beagle はデーモン形式のバックエンドと、検索インタフェースであるフロンエンドに分かれたているデスクトップ検索ツールである。

ファイルシステム上にあるテキストファイルだけでなくメールや、Firefox でアクセスしたページ、OpenOffice.orgMicrosoft Office のファイルなどをインデックス化し検索できるようにすることができるらしい。

ちなみに今まで

ローカルファイルの検索

メールMew 4 での検索(with Namazu)。
nDiki 記事howm で記事ソースデータを検索 (方法)、あるいは www.naney.org 公開記事を Google で。
メモhowm
開発中のソースコードEmacsgrep-find でだいたい事足りる。たまに ack。
仕事のメモできるだけ社内 Wiki社内 Blog に書いておいて Hyper Estraier
その他grep 程度。

といった感じかな。

それ以外はだいたいファイルの位置をうろ覚えしているので、何カ所か探せば見つかることが多い。

問題はうろ覚えの場所になかった時。 その時はなかなか見つからない。

そんなファイルを見つけるのが楽になれば、導入効果あり。

インストールして試してみる

Linux kernelinotify を有効にする

まずは Linux kernel の設定を確認。inotify が有効になっている方が良いらしい。 この間ビルドした時の .config を見て

 CONFIG_INOTIFY=y
 CONFIG_EXT2_FS_XATTR=y
 CONFIG_EXT3_FS_XATTR=y

となっていることを確認。

/home の extended attributes を有効にする。

/etc/fstab を編集し、

 /dev/hda4 /home ext3 defaults 0 2

 /dev/hda4 /home ext3 defaults,user_xattr 0 2

に変更する。書き換えたら、

 mount -o remount /home

でマウントしなおす。

Beagleインストール

Debian パッケージインストール

Beagle を起動

一般ユーザで

 beagled

で起動する。停止は

 beagle-shutdown

で。

Beagle を設定
 beagle-settings

で設定 UI を起動し、インデックスに含めたくないディレクトリなどを設定。

検索してみる
 beagle-search

検索 UI を起動し検索してみる。 日本語も OK のようである。

GNOME 環境をほとんどインストールしていなかったので、検索結果からファイルを開けずつまらなかたので gonome-control-center、gnome-panel あたりをインストールして環境設定等をしてみた。

KDE 系のクライアントもあるので別途いろいろ確認

Firefox 拡張

xpi ファイルを入れておく。 後は普通に閲覧したページが、Beagle でインデックス化されて検索できるようになる。

設定してしまえば、以前開発して使っていた WWWOFFLE + Namazu よりお手軽である。

感想

デーモンが逐次インデックス化していくので、明示的定期的にインデクサを走らせなくていいというのは楽でいい。

日本語関連がどの程度うまく検索できるのか、検索結果は使いやすい順に出力されるのかが未知数。 しばらく遊んでみて便利かどうか確かめてみたい。

[ 8月8日全て ]

2007年2月2日 (金)

DiKickergrep 検索機能を追加

DiKicker には自動リンクベースの記事串刺し表示機能があって、同じキーワードを含む記事をまとめて読むことができる。 結構便利なのだが、この機能ではキーワードの設定は Blog の書き手に委ねられている。

社内で DiKicker を一部使ってもらっているのだけれども、それら他人の Blog を読んでいると「あのキーワードで串刺し表示したいな」と思うことがしばしばあることに気がついた。 やはり任意の文字列で串刺し表示する機能が欲しい。

書き手にとっても「自動リンクキーワードにするような文字列ではないけれども、串刺しで読みたい/探したい/見せたい」と思うことが少なからずある。

ということで、検索ベースの串刺し表示機能を実装してみた。

grep ベース

実現には全文検索を行う必要があるが「設置・運用の手間」「ディスク容量」という点から、事前にインデックスを生成するような方法は今回は避けようと思う (www.naney.org 上で自分が使う上での制約からくる理由が一番大きかったりする)。

ということで今回は grep 型で実装することにした。 もともと WiKicker の方の検索機能も現在のところ grep 型である。 WiKicker では自前で WikiPage をスキャンしているが、DiKicker では grep コマンドに任せることにした。 こういうのは専用の grep を使った方が速いはず。呼び出しは

 grep -Flre $escaped_string dir...

というオプション指定。Web ページとしてのページングなどは、自動リンクによる串刺し表示機能のものを流用。

で試したところ www.naney.org サーバでは、load averages が 1 以下の時でだいたい50秒前後。対象ファイル数は 2800弱。予想より時間がかかる。

ただし1回実行した後、ファイルがファイルシステム/OSメモリ上にのっている状態では 0.1秒程度で完了する。

検索結果ページの permalink が検索エンジンにそれなりに捕捉されて、定期的にアクセスがあるようになれば、ファイルがメモリにのっている割合が増えるであろうから平均して実用に耐えられる速度が出るかもしれない。

今後は様子をみながら検索結果のキャッシュ等を処理を整備していく予定。

[ 2月2日全て ]

2007年12月23日 (日)

aufs を使って Web サイトのドラフト作成する

この nDiki はローカル PC 上で Emacs で記事ファイルを書き、出来上がったら UnisonWeb サーバと同期させる形でアップロード・公開している。

この方法で一つ問題なのは「書きかけの記事ファイル」の扱いが面倒なこと。 書きかけの記事ファイルがある状態で Web サーバと同期するとそれが公開されてしまうのでまずい。しかし完成している記事ファイルがあるならばそちらは同期して順次公開したい。 同期する時には書きかけの記事ファイルを退避させればいいのだが、思いっきり面倒。

ということで手元で公開用 (Web サーバ と同期用)のディレクトリツリーと、ドラフト用(ローカルの Web サーバでのレビュー用)のディレクトリツリーを分けられるようにすることにした。 この2つのディレクトリツリーの差分となる草稿・更新ファイルは aufs を使うことで簡単に管理することができる。

aufs

aufs は stackable unification filesystem の一つ。 同様なものとしては UnionFS がある。 UnionFS よりも aufs の方が評判が良いようなので今回は aufs を使うことにした。

aufs では複数のディレクトリ(ブランチと呼ぶ)をオーバーレイさせて、1つのディレクトリとして扱うことができる。 公開用ディレクトリツリーに、ドラフト用ディレクトリツリーをオーバーレイさせることで、元のディレクトリには変更を加えることなく透過的に変更できる仮想的なディレクトリツリーを作ることができる。

aufsインストール

Debian GNU/Linux sid へはkernel 再構築とあわせて module-assistant でインストールした。

マウント

以下のように3つのディレクトリを作ってマウントする。

/home/naney/www.naney.org
公開用ディレクトリツリー。本番モノ。公開サーバと同期する。
/home/naney/draft.naney.org
草稿や修正されたファイルが書き込まれるディレクトリツリー。
/home/naney/next.naney.org
公開用ディレクトリツリーに、草稿や修正されたファイルが仮想的にオーバーレイされたディレクトリツリー。プレビュー用。
 mount -v -t aufs -o br:/home/naney/draft.naney.org=rw:/home/naney/www.naney.org=ro none /home/naney/next.naney.org

公開ディレクトリツリーは read only に、草稿用のディレクトリツリーは read - write になるように指定する。

これで /home/naney/www.naney.org 以下はいじらないまま、/home/naney/next.naney.org 上で草稿を書いたりファイルを編集したりすることができる。 /home/naney/next.naney.org 以下で追加したファイルや、変更したファイルは aufs が /home/naney/draft.naney.org 上に保存してくれる。

完成したものを /home/naney/draft.naney.org から /home/naney/www.naney.org に順次反映させ(移動し)、公開サーバへ同期することで公開していくことができる。

手元ではいろいろ書き散らせておけるのは、これは便利。

マウントオプションは他にいろいろあるようなので、こまかい設定は見直すかも。

その他

ファイルシステムレベルの処理なので、アプリケーション側では何も手を加えなくてもよいのが良い。

今回は公開用とドラフト用としたが、公開用と未公開用をローカルでミックスして表示するようにしたり、複数ユーザのコンテンツディレクトリを仮想的に1つにまとめたりと、いろいろ面白い使い方ができそうだ。

[ 12月23日全て ]

About Me

Naney Naney (なにい)です。株式会社ミクシィで SNS 事業の部長をしています。

nDiki1999年1月に始めたコンピュータ日誌を前身とする NaneyWeb 日記(兼パーソナルナレッジベース)です。ちょっとしたノートは nNote にあります。

※内容は個人的見解であり所属組織とは関係ありません。

月別インデックス
Process Time: 0.055909s / load averages: 0.46, 0.40, 0.40
nDiki by WATANABE Yoshimasa (Naney)
Powered by DiKicker