新規記事投稿

フォロー記事投稿

記事のキャンセル

12月24日に、ＴＡＤさんは書きました。

＞＃元記事をみると２年も経っていますね。(^^;;

うぐぅ、全然アップデイト無かったですからね... (^^;

＞データベースファイルのパーミッションですが、
＞'606'固定だとSetUIDモードで動いていないサーバでhttpdのユーザ(cgiの実行ユーザ)と
＞一般ユーザのグループが一緒の環境で、そのファイルを消すことができなくなる場合が出てきませんか。

消すのはディレクトリの権限で制限するので、この場合は関係なさそうですね。
むしろ問題となりそうなのは、グループが一緒の場合、ユーザに読めなくなるので
バックアップ出来ない事かしら?

＃ もっとも、わざわざ認証データベースまでバックアップすることはしないかな?

＞＃＃うちの環境ではなぜか604で作成されてしまいました。
＞＃＃-rw----r--   1 nobody  users  16384 Dec 24 14:14 auth_dbm.db

あぅ、そうそう、うぇぶ会議室のファイル作成モード設定にはもともと問題があるのを
忘れていました。(^^; つまりスクリプトのどこでもumake()設定をしていないため、
サーヴァが設定したumaskのままファイルを作っていたのでした。

記事ファイルについては、いったん作ってから、chmod()していたので顕在化して
いませんが、dbmファイルはなんていう名前で出来るのか調べるのが面倒だったので
作成時に設定した値のままになっているので、サーヴァのumaskが利いてしまっているのです。

これを避けるには、site.plの中でサーヴァの特性に合わせたumaskを切るのがいいかなぁ
デフォルトは、umask(0000);で、SetUIDなサーヴァなら、umask(0077);に変える、
dbm_open()では0666で作る、ぐらいが良いかなぁ

＞＞データベースファイル(auth_dbm.*)は部屋毎に貯めていきます。
＞＞容量が大きくなりすぎる様なら、定期的に消してしまっても、まあ、良いです。
＞
＞あと、データベースファイルにため込む認証キーの最大件数を設定しておけると
＞データベースファイルのサイズが放って置いても無制限に大きくならずによいかなと思います。

まあ、そうなんですけど、最大件数を制限するとなると、あふれた場合古いほうから
消していかなくてはならず、(時間|容量)コストがかかるんですよね。
それに、標準的な会議室の最大記事数が1000として、1件当り100バイトずつ食ったとしても
100kBに過ぎないので、会議室ごとにためておく分には問題にはなるまい、と踏んだんですが、
実際どのくらい食うかはつかっているデータベースの効率に拠るので、よく分からないです。

＃ そんなに重要物では無いから、容量が厳しいところでは消しても平気だよ、ぐらいの感じかしら。