【雪だるま】bbsd⇔各cgi間のI/F仕様について考え・詰めていくスレッド
■ このスレッドは過去ログ倉庫に格納されています
雪だるま作戦において開発をすすめているbbsdでは、
+- [ フロントエンドサーバlive22x1 ] -- ユーザは
[ バックエンドサーバlive22 ] -+- [ フロントエンドサーバlive22x2 ] -- live22xという代表名で
制御プログラムbbsd +- [ フロントエンドサーバlive22x3 ] -- これらにアクセス
| | | dat直読みや、
dat subject.txt subback.html bbs.cgiやread.cgiやofflaw.cgi、
書きこみログ(芋掘り)ファイルなど (こちらは基本的に書き込み操作なし)
(書き込み操作はこちらで)
# 復帰/削除cgiなどについては、さてどっちかな => 今後の課題
という形で「ユーザの相手」と「各種ファイル処理」を複数のサーバに分業することにより、
さらなるパフォーマンスの向上を目論んでいます。
つまりこの場合、dat/subject.txt/subback.htmlは
バックエンドサーバで動作するbbsdというプログラムがリクエストに応じて生成し、
更新や場合によっては削除する形となります。
ということで、bbs.cgiをはじめとする従来2ちゃんねるで動いているcgiでは、
これらが同じサーバにあるつもりでファイル操作をしていましたが、
上記に示すように、少なくとも元本は同じサーバにはなくなるため、
何らかの形で対策を考慮する必要があります。
また現在、ID生成の種やSamba24や
timcount/timeclose等の規制関係で使用している一時ファイル等、
複数のフロントエンドサーバが同じ情報を、
何らかの形で共有する必要があるものもあります。
このスレッドではこれらの処理方法や実装方法について考えながら、
bbsdに持たせたい・持つべきな機能をあぶり出し、実装仕様を詰めていくことを目標にしています。 >>273- 乙です.動き出したようですね<呪文対応
BBS_DELETE_NAME ですが,「あぼーん」と違う設定の板があるとか,
この項目を将来的に SETTING.TXT から廃止する予定があるとか,
そういうことがあればその部分の処理を変えた方がいいのかも知れませんが,
どうなんでしょうか.
レス削除の $range は,例えば
-4,8-13,18,20-24,26,29-
のように柔軟な指定が可能になってます."-4" は "1-4" と等価で,
"29-" は例えば最終レス番が 40 なら "29-40" と等価です.
26,29-,20-24,8-13,18,-4 (順不同な指定)
-4,8-13,11,18,20-24,22-23,26,29- (重複するレス番がある)
というような指定であっても問題ありません.
ただ,"24-20" のように - の後ろの数値が小さい指定や,
最終レス番が 40 のスレで "38-41" のように範囲外の数値を
指定するとエラーになります.
スレのファイル自体削除は,dat そのものを削除しますので,復活はできません.
ゴミ箱送りが機能しないのは,やはりホスト名の問題ですね.フロントも live22 という
名前ならゴミ箱の名前が live22tr になりますが,現状だと live22xtr にしてしまうので.
とりあえずスレ移動で代用するのがいいのかな...... >>288
> BBS_DELETE_NAME ですが,「あぼーん」と違う設定の板があるとか,
> この項目を将来的に SETTING.TXT から廃止する予定があるとか,
> そういうことがあればその部分の処理を変えた方がいいのかも知れませんが,
> どうなんでしょうか.
私は、今の仕様でいいかなと思っているです。
削除人の方々は、どうなのかしら。
> レス削除の $range は,例えば
> -4,8-13,18,20-24,26,29-
> のように柔軟な指定が可能になってます."-4" は "1-4" と等価で,
> "29-" は例えば最終レス番が 40 なら "29-40" と等価です.
> 26,29-,20-24,8-13,18,-4 (順不同な指定)
> -4,8-13,11,18,20-24,22-23,26,29- (重複するレス番がある)
> というような指定であっても問題ありません.
> ただ,"24-20" のように - の後ろの数値が小さい指定や,
> 最終レス番が 40 のスレで "38-41" のように範囲外の数値を
> 指定するとエラーになります.
おー、すごいですね。
であれば、API仕様(ここに書く予定)の変数を、rangeにしてこよう。
> スレのファイル自体削除は,dat そのものを削除しますので,復活はできません.
やはりそうですか。
呪文のほうでは、実はファイルを移動しているのかな。
> ゴミ箱送りが機能しないのは,やはりホスト名の問題ですね.フロントも live22 という
> 名前ならゴミ箱の名前が live22tr になりますが,現状だと live22xtr にしてしまうので.
> とりあえずスレ移動で代用するのがいいのかな......
そうなるですね。
で、そもそもlive22はメモリディスク仕様だったりして、
live22trはメモリディスク上になかったりするので、
そのままではEXDEVか何かになるかもしれんです。 >>289
>> スレのファイル自体削除は,dat そのものを削除しますので,復活はできません.
>やはりそうですか。
>呪文のほうでは、実はファイルを移動しているのかな。
従来のスレ削除ではどうなってるのか知りたいですね>ご存じの方
>で、そもそもlive22はメモリディスク仕様だったりして、
>live22trはメモリディスク上になかったりするので、
>そのままではEXDEVか何かになるかもしれんです。
*.dat は別ファイルを作成した上で内容転送,*.html は単純な rename() になってます.
移動先では一番下に追加ということで,index.html に表示されないぐらい下なら *.html が
なくてもとりあえず平気でしょうけど,そうじゃない場合にどうかってところですか...... >>290
なるほどです。
パラノイアにやるならhtml/htmlを作り直すんでしょうけど、
たぶんそこまでやらなくても、いいような気がするです。 復帰・sage復帰の呪文も、対応できたと思います。
今後、対応ができた呪文は、live22xに対して唱えてくださいです。 で、今後の方針ですが、、、。
各パーツを完成させて、実行するためのAPIの仕様をここに公開しようと思うです。
で、対応のさせ方を全部書いたうえで、
あとは、呪文のおもりをされている方に、個別に対応していただこうかなと。
たぶん、それが一番問題が少ないと思うです。
で、もし対応される方が既にいない呪文、というのがあった場合は、、、。
その時は、みんなで困りましょうと。 >>289
> BBS_DELETE_NAME ですが,「あぼーん」と違う設定の板があるとか,
> この項目を将来的に SETTING.TXT から廃止する予定があるとか,
> そういうことがあればその部分の処理を変えた方がいいのかも知れませんが,
> どうなんでしょうか.
これって、SETTING.TXTで多い設定は「あぼーん」と「あぼーん!」の2種類っすね。
たまにこれとちがって空文字列やら「おぼーん」やら「半漁人さん」という
設定になっている板があります。もちろん実際にはそうはなりませんが。。
で、最近、レス削除の時に、「あぼーん」のかわりに「うふーん」やら、
スレストのときに「スレは止めても愛は止まらない!」とか書いてあるときがあるけど、
あれってどうなっとるんやろなぁ。。 >>294 最終段落
何か、新しい呪文だと思うです。
このへんのメッセージを変えるAPIは、、、別途考えようっと。 てゆうか、「あぼーん」を変えるのは、ちょっと今の仕様だと難しいかもですね。
「愛は止まらない」にするとかはSunOSさん提供のAPIで、できるですが。 >>294-296 なるほど.となると......レス通常削除用 API に引数追加して
「あぼーん」に相当する文字列を CGI 側から指定してもらうとかするのがいいんですかね. どの呪文もこの2つを相当使っているようなので、
以下の共通APIを準備することにした。
@dat = &GetDatFromBackend($ita, $key);
@sub = &GetSubjectFromBackend($ita);
で、共通判定部分を準備した。
if (&IsSnowmanServer) {
雪だるま;
} else {
通常;
}
のように使用可能。
昨日仮対応した呪文も、追ってこれに書き換えよう。 > 昨日仮対応した呪文も、追ってこれに書き換えよう。
完了。
対応例:
# 雪だるまサーバ対応 -- 12/15/2005 by む
if (&IsSnowmanServer) {
@dat = &GetDatFromBackend($FORM{'bbs'}, $FORM{'key'});
} else {
open(DAT,"<$ondat");
@dat = <DAT>;
close(DAT);
} で、追加でひとつお願いです。
スレッド削除は、ファイルの実体を移動することで実装している、
という情報がありました(ごくたまに、誤削除されたものを戻している人がいます)。
ということで、bbsdに以下のAPIの追加をお願いできますでしょうか。
処理名: datの移動処理(スレッド削除に相当)
動作: 板$bbsのキー$keyのdatを、指定したパス名で移動(保管)する
- 入力: $bbs, $key, パス名
- パス名はpublic_html/testからの相対パス
- datがある場所と移動先は同じパーティションにあるとは限らない
よろしくおながいいたしますです。 あぼーん<>あぼーん<>あぼーん<>あぼーん<>あぼーん
ぬるぽ<>ぬるぽ<>ぬるぽ<>ぬるぽ<>ぬるぽ
停止しました。。。<>停止<>停止<>真・スレッドストッパー。。。( ̄ー ̄)ニヤリッ<>停止したよ。
停止しました。<>停止<>停止<> 停止いたしますわ。ごきげんよう。 <>停止したよ?
こういうのを見るとfrontから一行分指定できたほうがよさそう。 >>302
既に、そうなっているですね。< bbsd 【鮟鱇鍋】雪だるま作戦に思いを馳せながら雑談するスレッド Part30
http://aa5.2ch.net/test/read.cgi/nanmin/1134460312/177
1時間に1回、countidsしてclearidsしていると。 どうでもいいんだけど
/_service/IPnum-xxxx-xx-xx.txt
って書き込みIP数なの
それとも読み込みも含めたIP数なの? >>305
> 読み込みも含めたIP数
それはPV********.txtじゃないの? レスの通常あぼーん:
my $errmsg = bbsd($bbs, "delete:$key", $range, $deletename, "$logfilename:$logline");
# 引数追加で $deletename に「あぼーん」などの文字列を指定.
スレッド削除($path へ移動; EXDEV 対策済み):
my $errmsg = bbsd($bbs, "delete:$key", '*', $path, "$logfilename:$logline");
# ゴミ箱逝きには move を使ってもらって,お役ご免になりそうなスレ用 delete をこの仕様に変更.
以上実装しますた. >>307
はや。おつです。
落ち着いたら、bbsdの入れ替え & APIへの組み込みをば。 そういえば、スレストの処理が微妙に従来と違うような。
いままでは、24レスのスレがスレストされたら、subject.txtには(24)って表示だったはずなのに、
>>310のスレは(25)って表示になってるですね。
あと、移転された場合も、従来は、レス数表示は移転された時点のレス数のまま、
スレタイも「移転しました。。。」ではなく移転される前のままだったけど、
移転しました。。。 (1)ってなってるように見えるです。
(通常復帰があった場合は確かにそうなるし、これは完全には確認はできてないですが、、) >>311 乙です.ただ......細かい bugfix をしましたので,お手数ですが再度更新お願いします<bbsd
>##############################################################################
># スレをsubject.txt/subback.htmlから消去(dat落ち処理とかで)
># 入力: 板名、キー
>##############################################################################
>$errmsg = &PurgeSubject($ita, $key);
こういう形になってるとわかりやすそうですね.で,bbsd の purge コマンドの引数は
$keys となってるのがミソでして,もちろん単一のスレキーでもいいんですが,
複数のスレキーを ',' で区切って列挙しても Ok になってます.
>>312 それはですね......bbsd では,内部で保持している subject データが
dat の状態を正しく反映しているという前提で各種処理を行っているので,
dat の実際の状態と乖離したままにしておくと弊害が出かねないため
そのようにしています.また,dat の状態を正しく反映するためのオーバヘッドも
bbs.cgi に比べるとずっと小さくなっているということもあります. しつもん
誤爆レス削除の復旧も、お願いすれば出来たんですけど。
スレ削除と同じで。
レス削除・透明削除でも
どこかに削除前のdatは持っててくれてるのかしら。 >>313
更新したです。
で、purgeは複数指定できるですか。さすが。
>>314
なるほどです。
たぶん、呪文内で保存しているんだと思います。
保存の仕方により、bbsdやその上の部分(私が今組んでいる)のAPIで
フォローする必要があるかどうかが決まるのかな。
そのへん、どうなんですかね。> 知っている方
# 削除系は、技術情報がちと。 >>315
で、そういうことであればスレ削除と同じで、残す機構を用意すればよさげですね。
対象はレス削除と透明削除ですか。
で、>>307 にも言えるのですが、既に移動先に同じ名前のファイルがあったら、
どのようなことになるのかしら(EEXISTとかかな)。 少し更新。
http://mumumu.mu/bbsd-delete-apilist.txt
で、たぶん ResSakujo ResSakujo2 ResToumeiSakujo には
SureSakujo と同様、退避先パス名を追加するようになりそうな予感。 live22xではなく、live22に対して実行することになる呪文:
相当する呪文があるかどうかではなく、そういう機能を持った呪文ということで。
・SETTING.TXTをいじる呪文
・1000.txtをいじる呪文
・過去ログ削除の呪文
・強制dat落ちの呪文(手動むぎゅ)
・強制倉庫送りの呪文(★漏れとかの時に使用しているもの) → 動作確認済み by 私
・キャップを操作する呪文 → 動作確認済み by anglerさん
・削除(退避)したものを復活させる呪文
・dat落ちしたものを復活させる呪文
・芋掘り機 → おじさんから既に宣言あり で、たぶんですが、
・SETTING.TXTをいじる呪文
は、私の知っているものについてはlive22xで起動かけたら、
「この呪文はバックエンドサーバで実行してください」
っていうのを表示するCGIを、仕込んでおくかんじで。 >>316
>で、>>307 にも言えるのですが、既に移動先に同じ名前のファイルがあったら、
>どのようなことになるのかしら(EEXISTとかかな)。
現状では単なる rename() のエミュレーション,つまり上書きになります.
EEXIST になるようにした方がいいですかね.
で,レスあぼーんでもデータ退避ですか......あぼーんの度に dat 全体を
保存していると HDD を食い潰していきそうなんで差分で保存した方が
合理的だと思いますが,そうなるとどのようなフォーマットで保存すべきかとか,
あと退避したデータからロールバックする際に,直近のデータから復元するのは
問題ないでしょうけど,何世代も前のデータから復元する際に途中に透明あぼーんが
あるとそのままではずれてしまうでしょうし......そのあたり従来のあぼーん呪文では
どうしてるんでしょうね.
また,bbsd 以外のプロセスが dat を操作することに関してですが,例えば dat 落ちの
ようにファイル自体を rename() や unlink() するのは比較的安全だと思いますが,
dat の中身を書き換えるような操作には脆い面もあります.どのような操作かにも
依存しますが,レス追記とバッティングすると追記されたレスが消失するかもとか,
*.html 生成時には対応する dat を mmap() しますので,生成される HTML が崩れるとか
最悪の場合地雷 (SIGSEGV / SIGBUS) を踏むとかいった可能性もあるので......
となると,レスあぼーんのロールバックは bbsd 側で I/F を用意した方が
良さそうにも思いますが,従来の呪文でどのような処理をしているかがわからないと
なかなか具体的に作りづらいという面もあります...... >>320
> 現状では単なる rename() のエミュレーション,つまり上書きになります.
> EEXIST になるようにした方がいいですかね.
そうしていただけると助かります。
> そのあたり従来のあぼーん呪文では
> どうしてるんでしょうね.
いつだったかに管理人とおじさんに聞いた話を思い出しつつあるのですが、
確か「レス削除系でも、毎回全部dat全体を保存している」ということらしいです。
で、ファイルがあるかどうか調べて、
あったら何らかの規則で(見てませんが、例えば.0とか.1とか)、
保存しているんではないでしょうか。
「削除」という行為の、2ちゃんねるにおける「重み」を考えると、
そのぐらいはしているような、気がしますです。
で、管理人がそういった形でのデータの「あふれ」を気にするはずもなく、
おじさんが静脈系のプログラム(F22ともいう)を作って、
定期的に後始末をしていると、ぼやいていたのを聞いたことがあります。 >>320
>また,bbsd 以外のプロセスが dat を操作することに関してですが,例えば dat 落ちの
>ようにファイル自体を rename() や unlink() するのは比較的安全だと思いますが,
>dat の中身を書き換えるような操作には脆い面もあります.
私も、そう思っているです。
なので、特にレス削除系は、基本的にフロントからbbsd経由で
統一的に操作するようにしたいところです。
>となると,レスあぼーんのロールバックは bbsd 側で I/F を用意した方が
>良さそうにも思いますが,従来の呪文でどのような処理をしているかがわからないと
>なかなか具体的に作りづらいという面もあります......
確かに、そのとおりですね。
ロールバックも基本的に呪文でやっているはずなので(違うかもですが)、
これもフロントでやるようにしたほうが、いいかもです。
あるいはもし呪文でやってなかったなら、
そのための「復活の呪文」を新たに作って、それをぢぇんぬさんに配布してもらうかんじか。
# やっぱり、もう1段階覚悟を決めて、
# 標準セットの呪文を教えてもらって、読んでみるしかないのかなぁ、、、。 $key = スレキー;
$nowtime = UNIXたいむ;
ログ保存($key$nowtime);
一度削除系CGIの仕様を詳しく聞いた方が・・・。
俺の口からはいえない。 >>323
なるほど。
どこのどなたかは存じませんが、ありがとうございます。
同一秒の間に同じスレへの削除が起こらなければ、いけるようになっていると。
で、そうやっているってことは、
昔のbbs.cgiのスレ立て重複防止装置のところを書いた人と
仮に同じ人が書いているとすれば、
$newtimeを+1して、、、ってのを、大丈夫になるまで繰り返しているんでしょうね。
ぢぇんぬさんに、相談してみるです。 呪文だけ教わっても、アカウントがなければ作業は出来ないから
作業を押し付けられることはないと思うんですが(ぼそ)
削除ログのcgiをいじられる上で気になるのは、
書き込みログとの整合性をどこかで取ってる筈なので、
そちら(IP・リモホ)の消しすぎや漏れが出ないかどうか、です。。
ご相談のメールを、ぢぇんぬさんと管理人に発射したです。 >>325
第一段落:
某ホテルで「(アカウントは)いつでも作るですよ」って管理人に言われて、
ものすごい勢いで、首を横に振った私がいるです。
第二段落:
そうですね。
書き込みログはバックエンドにしかないので、そのへんも問題になる可能性ありか。
まずは「ご相談」のお返事を見てから、次の行動をってかんじで。 うはw 予想通り>「いつでも」&「ものい勢いで」
あとは「削除の呪文を唱えた人のログ」もあるはずなので
そちらの方の記録もできるかってことですかね。
いろいろお疲れ様です。宜しくお願いします。 >>329
削除でログが消える期間が短くなる、と聞いてますよ。
329さんがcgi制作の中の人ならごめんなさいですが。 >>328
>あとは「削除の呪文を唱えた人のログ」もあるはずなので
>そちらの方の記録もできるかってことですかね。
そっちは、bbsdのほうで対応するためのI/Fが用意されているです。 スレ削除(退避)時に同一パス名が存在した場合に EEXIST にするのは対応完了です.
あぼーん/ロールバック関連については,もうちょっと様子見で...... >>332
おつです。入れ替えてきます。
> あぼーん/ロールバック関連については,もうちょっと様子見で......
こちらも了解。 >>333
完了です。
- || (fd_new = open(new, O_WRONLY|O_CREAT|O_TRUNC, 0644)) == -1
+ || (fd_new = open(new, O_WRONLY|O_CREAT|O_EXCL, 0644)) == -1
なるほど。
# bbsd.cをちびちびと読み始めようかと思っていたりするんですが、
# なにぶん、中身がすごくて(いい意味です)。
# 何というか、コメントではなく、中身をもって語らしめよ、みたいな。 >>334 確かにコメントがほとんどないのは不親切かも......w
とにかくがーっと書いててコメントまで気が回らなかったんですが,
bbsd.c のおもりをどなたかに委ねるとかいうことになったら,
わかりやすいようにしなきゃですね. >>335
> bbsd.c のおもりをどなたかに委ねるとかいうことになったら,
> わかりやすいようにしなきゃですね.
どきどき。
面白いと感じていただける間は、ぜひお願いしますです。
私も、面白いと感じていられる間は、やりますです。
で、bbs.cgi は「おじさんや私じゃなくても大丈夫な状態にする」ことが目的だったので、
もうしつこいぐらい、コメントにつぐコメントだらけになっているです。
%wc -l bbs-main.cgi
4569 bbs-main.cgi
%grep # bbs-main.cgi | wc -l
1193 >>336 まぁ,よほどのことがなければ自分の側から投げ出すってことはないと思うんで.
もっとも,天変地異はいつ起こるかわからないとか,そういうレベルの話だと神のみぞ知る,ってところですが. >>337
それは、お互い様すね。
今日はたぶんここはこのぐらいで、たぶん、また明日以降に。
# さっきのメールの返事、管理人からはいつもどおりの「おつです。おつです。」、、、。 >>338 乙でした.ではまた明日以降にでも.
># さっきのメールの返事、管理人からは(ry
(w 4500 行かぁ・・・
大分類して、requireとかuseにするという手もあるのかな。 >>341
これはこないだの某ホテルでも、話題になったすね。
そろそろ、やる時期かも。 ぢぇんぬさんから、>>324 のお返事をいただきました。
ということで、ぼちぼち、すすめていこうかなと。 呼ばれて飛び出て(ry
こら、そこ。
冬休みとか言わないように。 >>343
乙です、超乙です。鬼乙です。
なんかあったら電波飛ばしてくださいですー。
私のほうでも出来るだけここ覗くようにしますです。 >>344
でたなー。
>>347
どもです。ハードな作業いつもおつです。
で、メールでのお返事をここでしてしまったりしますが、
このスレはoperateの中でもハードコアなほうらしいので、
スレの技術的な内容が仮にアレだったとしても、
あんまり気にすることはないと思うです。
ようは、できるだけこれまで通りに、
場合によってはこれまでより効率よく安全に使えるといいなという、
単にそれだけのことです。
今後、作業を徐々にすすめていくことになると思いますので、
呪文を使う上で何か不具合があったとか、妙なことが起きたとか、
これまではこうやってたけどこういうことができるといいなとか、
そういうことがあれば、忌憚なくここに書いていただけると。
# それらに対応できるかどうかは、別の問題とゆうことでひとつ。 > このスレはoperateの中でもハードコアなほうらしいので、
一番ハードコアですよ、ここ
perlの追っかけなど、技術動向に強い人じゃないとついてけない いや、あのアンカーはあっている(ということにしよう) いんどメーターを起動。結果95いんど。どうみても(ry さて、ここもぼちぼち動かそうかなと思います。
本格対応は、お雑煮食べながらという感じになりそうな予感ですが。
で、やはりどうも必要になりそうなので、
とりあえず汎用のファイルコピー用APIを、bbsd側で作っていただけるとありがたいです。
パス1 を パス2 に単純にコピー、
パス2が既に存在したら EEXIST エラー、といった感じで。 >>360 そうですね.ロールバック対応が完了すれば,呪文も一通り対応完了でしょうし.
>とりあえず汎用のファイルコピー用APIを、bbsd側で作っていただけるとありがたいです。
>パス1 を パス2 に単純にコピー、
>パス2が既に存在したら EEXIST エラー、といった感じで。
了解です. ファイルコピー:
my $errmsg = bbsd($srcpath, 'cp', $dstpath, "$logfilename:$logline");
実装しますた. >>362
おつです、おつです。
今何か超速い番組やってるんで、
入れ替えは、のちほど。
# 元気に動いて、実況を支え続けているです。はい。 bbsd 更新したです。
これでひととおりのAPIがそろった気がするので、
こちらも、ぼちぼちと。 おふろ入っている間に思いついたので。
Samba24とか、timecount/timecloseとかの
DB管理系だけを、別のbbsdでお守りすることにして、
そのbbsdは、フロントエンドのどれかに持たせるというのはどうかなと。
で、つまり、bbsdのDB管理系部分だけの機能を有効にするような
起動オプションがあると、うれしいのかもなぁと。
ということで、本日はここまでで。 >>367 の心は、
こういうふうにすれば、バックエンドのbbsdを
少しでも軽くできるんじゃないかなぁと、そうゆうことで。 いずれにせよ面白そうなので、ちと考えてみるです。
というかたぶんここで、例によって。
・野球系・サッカー系を一かたまりにして、効率よく
・www/www2/menuをグレードアップ
あたりが命題で、すぐ使えるのは、
・live16 live18 live20
あたりですか。 >>367-368 そういうことであれば,起動オプションを新設するまでもなく
現状の bbsd を普通に立ち上げればいいと思います.
板ディレクトリと SETTING.TXT があって subject.txt がない状態なら,
そのままで DB 管理専用 bbsd として使えるかと.
DB 管理系 API を呼び出すだけなら,subject や dat の操作は一切行いませんし. >>371
おぉ、すばらしいです。
あとで、やってみるです。
これで、規制系DBをフロント(というか別サーバ)にもっていけると。 対応したです。
これで、live22のbbsdからこれらの仕事を分離できたと。
560 名前: ◆MUMUMUhnYI [sage] 投稿日:2005/12/27(火) 04:23:13 ID:hh69QxeR0 ?
# 051227 bbsd複数体制(書き込み・IDの種用とDB保持用)に対応
# Samba24、●スレ立て、timecount/timecloseのDBのおもりを別サーバで
# これらに関してはbbsdがダウンしていてもとりあえず書き込みは可能に by む >>373 により、Samba24のデータをlive22x1のbbsdで面倒見るようになったので、
例の数値が出るサーバが、live22x1に変更になったです。>どくどくさぼてんさん 今後の作業をすすめていく場所ができました。
荒らすか(仮)@2ch掲示板
http://snow.2ch.net/alaska/
ローカル雪だるまで動いています。
各種呪文等は、今後ここでごにょごにょと対応を進めていくことになるのかなと。 >>375
削除の呪文を唱えるのに、かなり手間取るようなのですが
せめて板名を変えてもらえませんか?
現状の板名では
荒らし依頼や電番・サイト攻撃などの書き込みが集まる悪寒がします。
運営の人には面白い駄洒落なのかもしれませんが
荒らし公認ととられかねない板名は、やめて欲しいです。 >>376
> 削除の呪文を唱えるのに、かなり手間取るようなのですが
そうなんですか。
snowは「ローカル雪だるま」(= datそのものはsnowサーバに普通に存在)なので、
スレ削除とかスレ移動等の後に復帰の呪文が追加で必要になりますが、
呪文自体が「かなり手間取る(例えばlive22x => live22にしないと効かない)」ことは、
ないと思うです。
板名ですが、おじさん流の洒落すね。
私は正直あんまり気にしてないですが、ちょっとびっくりしたです。
(フォルダ名alaskaをお願いしたのは私ですが、その洒落は私は全く思いつかなかった) >>377 に自己突っ込み
で、もし仮に「かなり手間取る」が「別途復帰の呪文が必要」のことだとしたら、
それは「このとおりです鋭意なんとかします今は許してください」しかないです。
ごめんなさい。
ドウモスミマセン、コノトオリデスのAA↓ 要するに>>376さんは
削除が大変なんだからせめて削除対象になるレスを増やすような板名はやめちくれ
ってことかな そういう話ですか。>>379-380
SETTING.TXTを変えるのは私でもさっくりやれますが(板名にこだわりないし)、
kakolog.html とか kako/ とかは、どうすればいいのかな。 とりあえず、SETTING.TXTだけ変えてみた。 隠し板扱いだし、そもそも書き込み自体があんまりないような気がする。
そんなに気にしなくてもいいんじゃないの? 対外的(要請板取り扱いみたいなの)があるとやっぱり問題かとも思うけどねぇ
まあないか。 探知はされてるよ
http://snow.2ch.net/test/read.cgi/alaska/1135699588/5-6
>>381
>kakolog.html とか kako/ とかは
これそこらじゅうでむちゃくちゃになってるから
窓口決めといて >◆cZfSunOs.さん&rootさん、関係各位
本年もよろしくお願いします。
live22xのsage復帰ですが、一度で上手くいかずに何度か呪文を唱える事になりました。
呪文を唱えるたびに、42→36→34→33のようにsubjectのスレッド数が変化しました。
(上手くいっていれば一度で42→33になるはずです)
何らかの問題が潜んでいるのか、今回だけなのかわかりませんが、とりあえずご報告します。
またlive22x復帰する機会があったら、挙動をよく見ておきます。
http://qb5.2ch.net/test/read.cgi/operate/1127134565/686-688
よろしくお願いします。 >>386 こちらこそよろしくお願いします.
で,ご報告ありがとうございました.う〜む......sage 復帰でスレが subject から消される条件は
if (stat(*worker->paths, &st) && errno == ENOENT)
つまり dat ファイルへの stat() が失敗しかつ errno が ENOENT な場合ということなので,
何らかの原因で ENOENT 以外だったんでしょうか.いずれにせよこのあたり要観察ですかね.
# 番外編として,本来マルチスレッド環境で MT-Safe であるべき errno に虫がいるかも
# ってのもあり得なくはないのかも...... >>386-387 について......「要観察」といっても,現状だと ENOENT 以外が発生しても
何が起きたか見当もつかないんですよね.ということで,ENOENT 以外が発生したら
エラーリターンになる($errmsg にメッセージを返す)ようにしますた. ■ このスレッドは過去ログ倉庫に格納されています