/etc/cron.daily/tmpwatch

Red Hat系ディストリビューション限定の話だが、/tmp ディレクトリに削除されては困るファイルを放置してはいけない。10日アクセスがないと削除されるのに全く気付いてないぬるぽな人は割といるかもしれない、、と推測してこのエントリを記す。

flags=-umc
/usr/sbin/tmpwatch "$flags" -x /tmp/.X11-unix -x /tmp/.XIM-unix \
-x /tmp/.font-unix -x /tmp/.ICE-unix -x /tmp/.Test-unix 240 /tmp
/usr/sbin/tmpwatch "$flags" 720 /var/tmp
for d in /var/{cache/man,catman}/{cat?,X11R6/cat?,local/cat?}; do
if [ -d "$d" ]; then
/usr/sbin/tmpwatch "$flags" -f 720 "$d"
fi
done

上記は CentOS 5.4(final) の /etc/cron.daily/tmpwatch の中身だが、/tmp からは一部のソケットファイルを除いて10日間アクセスがないものを削除している。その他 /var/tmp/ は30日。/var/ 以下の一部のディレクトリも同様である。

----

詳しくは man 8 tmpwatch であるが、一定時間アクセスがないものを削除、というのは割と使えるかもしれない。キャッシュファイルとか、ね。

windows.kde.org

(※ 上記は Windows 7 上のものです。)

普段 Linux、そして KDE をこよなく愛する自分にとって、**やむなく使っている** Windows でお気に入りのKDEアプリケーションが動いたらどんなに素敵だろう、と以前から思ってはいた。けど、今やそれは絵空事ではなくなっている。

まだ個々のアプリのインストーラーを配布するという形にはなっていないが、windows.kde.org(※1) には cygwin のインストーラーのような形でアプリケーションを選ぶことができる KDEのインストーラーが提供されている(※2)。しかも、KDE全体をインストールする必要すらない。上記の画像のように Konversation のみを選ぶことも可能になっていた。自分が試したところでは、 KDE 4.4.4 ベースでコンパイルされたアプリが選べるようになっていた。

不安な方は、スクリーンショット と KDE Techbase のドキュメントを見てからチャレンジするとよいだろう。

もう自分には Limechat はいりませんっ！(｀ー´)

----

※1 え、windows.kde.org なんて知らなかったって？ どれくらい前からあったんでしょうね。僕も昨日知りましたから（藁
※2 cygwin で X を入れればWindows上でKDEも動かすことはできていた。ただ、この状態では X や KDE を入れずに個々のアプリをインストールできる状態ではなかった（はず

pgrep, pkill

http://www.freebsd.org/cgi/man.cgi?query=pgrep&apropos=0&sektion=0&manpath=FreeBSD+8.0-RELEASE&format=html
http://www.linux.or.jp/JM/html/procps/man1/pkill.1.html

その昔、俺が大学に入って間もないときは「名前にマッチするプロセスに対して一気にシグナルを送る」というのは意外に大変だった。当時は以下のような長ったらしいことをしていたので、今でもそうする癖がついている

ps -wef | grep i-want-to-kill-this-process | awk '{print $2}' | xargs -n 1 kill -9

しかし今やこんなことは無用だ。以下のように1コマンドで可能だ。名前にマッチするプロセスIDを探すのだってpgrep一発である。良い時代になったものだ(´ー｀; )

pkill -u mumumu i-want-to-kill-this-process

ただ、pgrep, pkill ともに環境依存ではある。Solaris, Linux, FreeBSD にあることは確認しているが、drryたんによると標準の Mac OS X には存在しないようだ。

＃どうも未だに癖が抜けないのでjournal
＃killallはどうなのって言われそうだけど、、

misc_register - Linux kernel API

http://d.hatena.ne.jp/TRANSii/20080911/p1

major番号、minor番号をいちいちregister, unregisterしてデバイスファイルをudev経由で作りたくねーよ的な要求は必ずあると思うのだが、さりとて上記のような正規かどうかもわからな いAPIを使うのも躊躇われるので悩ましいところである。

----

とはいえ、Linux kernel プログラミングで３分クッキングは素晴らしい試みだと思う。

やってみて思うのは、C言語がたとえわかっていても前提知識が多すぎる。内部のAPIやディレクトリ構造がバージョンごとに当たり前のように変わる。まあ、後者は開発者たちが一致して決めたポリシーだし、今のプロジェクトのまわし方だと十二分に理に叶っていることなので文句はないのだけれども。

前者の前提知識の量にしても、ひるがえってWebを見たところでそれなりにあるわけだから、まぁ、、というところだろうか。

Kubuntu 8.10 Intrepid

http://www.kubuntu.org/news/8.10-release

うーん、Beta からちっとはマシになってると思ったのだが、、多少は改善されてたけど大筋は変わってなかった（藁

• kdm で greeter を表示できずに止まる
• コンソールから startx しても、日本語入力周りが恐ろしく不安定。ターミナルに何か入力しようとすると止まる

これじゃあ使えないなあ、、KDE 4.1.2 は魅力なのだけれども、、しばらくは 8.04 LTS でいきますかのぉ。KDE 4 はまぁテストマシンでSVN版を試し続けるとしよう。

Quit watching Fedora

FedoraまわりのMLを、announce を除いて全て unsubscribe した。

＃ぢょーさんには「まだ見てたのかよ」とか言われそうww

Fedora から Core という名前が消えた後の変化の波で興味を失ったのが一番大きいわけだが、結局はデベロッパとしてそれっぽい居場所を見つけられなかったのが一番なんだろうな、と。それ以前に、当時は本当に無力だった(今もだけどね）。

とはいえ、開発者へのバグ報告の作法を教えてくれたり、IRCで英語でやりあったり、翻訳したり等々、コミュニティというものにはじめてどっぷりと浸からせてくれたのは Fedora であったことは間違いない。この経験は間違いなく今に生きている。

courier-imap + postfix + cram-md5 on Debian Etch

自宅のメールサーバはずっと Fedora 7 で運用しつつ、bind や courier-imap + postfix はソースで最新版を維持しつつずっとやってきた。少し前に Fedora 7 の End of Life(サポートの期限切れ）が発表された のだが、これを Fedora 9 にするのは、、手順はわかっているものの俺にとっては相当心臓に悪い。

ということで一昨日、維持のコストをさらに下げるべく、Debian Etch に入れ替えた。

だが、やはり流儀が違う(主に設定ファイルが分割されている点)のと、Postfix がデフォルト chroot だったこと、postfix が 2.1 系から 2.3 系にあがったこと等が災いして設定に手間取った。挙句の果ては設定ミスでとある重要なところにメールを bounce させてしまってしこたま怒られる始末。

特に authdaemond の設定には手間取ったが、/usr/share/doc/courier-authlib/README.authdebug.html を読んでデバッグしてなんとか現状にこぎつけた次第である。

----

こ れによって Postfix は 2.3.8 になった。いざ運用してみると以前の 2.1 系と比較して劇的にパフォーマンスが向上しているように見える。以前は load average が 1.5 位は普通だったのに、現在は 0.3 以下を維持している。素晴らしい。