MODEの概要及び制限事項

02481, Today: 001, Yesterday: 001 Hits


【 MODEの概要 】

MODEとは何か?

+e [ exception ] 及び +b [ ban ] の使用方法

対象 : チャンネル

+e (入室禁止設定の例外) は +b (入室禁止設定) に対し、例外設定を施す と言う意味であり、広域な範囲で入室を禁止された場合、禁止によりチャ ンネルに参加出来ない人が居たとします。その人もチャンネルに参加出来なくなるの で、その特定の人のみ JOIN を許可する為の設定が出来ます。

ex) +b *!*@*.example.com
+e *!tomocha@*.nara.example.com

このようにした場合、*!tomocha@*.nara.example.com に該当しないすべての *!*@*.example.com のホストの人はJOIN出来なくなります。例外として、チャンネル オペレータが ban されている人をチャンネルに invite したときのみ、JOIN 出来ま す。そのとき、NOTICEで

tomocha carries an invitation (overriding ban on *!*@*.example.com).

のように表示され、ban されているが、invite により JOIN してきた場合、該当す る ban マスクが上記のように表示されます。
反対の -b, -e と言うのもあり、特定のマスクをはずすことも出来ます。

+I [ Invite Only ] の使用方法

対象 : チャンネル

+I とは、チャンネルモードが+i (invite only) で有るとき、該当するマス クがある人のみチャンネルに参加できます。 また、チャンネルオペレータを持っている場合、+I に記述されていなくて も、invie をすることによりチャンネルに参加させることが可能です。 反対の -I と言うのもあり、特定のマスクをはずすことも出来ます。

+m [モデレート] の使用用途

対象 : チャンネル

例えば、勉強会やミーティング等が有ったとしましょう。そこで、logger (ロガー:議論等の内容を記録する人)たちのみ発言をすることが可能となります。 要はラジオと同じような感覚で利用すると言うことですね。また、ニュースチャンネ ル(ニュースを黙々と流すラジオみたいなチャンネル)でも利用されることがありま す。全くの別の使い方としては、abuserが大量にJOINしてきて意味の分からない内容 を大量にコピー&ペーストしたりする場合の一時的処置にも使うことが有ります。

+m を設定されたチャンネルの場合、チャンネルオペレータ若しくは発言権を持ってい ないと発言が出来なくなります。詳細は発言権のパラグラフを参照してください。

+v [ voice ] の使用用途

対象 : ニックネーム(ユーザ)

最初の方にも書きましたが、+m されているチャンネル、若しくは ban されている場 合発言が出来なくなります。そのときに、+v (発言権)を貰うか、チャンネルオペレ ータ権限を貰うことによって会話に参加することが出来ます。また、-v もあり、発 言権を剥奪することも可能です。

【 +b/+m されて発言が出来ません。 】

これは ban された場合、チャンネルに JOIN 出来ません。しかし、チャンネルオペ レータの持っている人に invite して貰えば、JOIN することが可能です。しかし、 そのままでは発言をすることが出来ません。 解決方法としては、ban をはずして貰うか、または、発言権(+v)を貰う、チャンネル オペレータ権限を貰うことによって解決が出来ます。

また、チャンネルモードに +m を設定されている場合も同様で、発言が出来ず、エラ ーが表示される事が有ります。そのときは以下のようなメッセージが表示されること になります。

404 <nick> <channel> :Cannot send to channel

そのようになったときには、チャンネルオペレータを持っている人から発言 権(+v)を貰うことで解決が出来ます。

また、海外の人も JOIN して来るような大きなチャンネルで発生することもあります。 原因はfakeが発生した場合です。fakeとは、サーバスプリット (IRCサーバ間のリンクの切断)が発生し、後に復帰したときサーバに過大な負荷が 掛かります。その時に、お互いの設定情報が伝わり、整合性をとろうとサーバが頑張 っているときに、+b を付けたりすると、上手くIRCサーバ間でのチャンネル の整合性が取れないことが稀に起こります。そのようなケースが発生した 場合、サーバA では +b されており、サーバB では +b がついていない、若 しくはチャンネルオペレータの情報が サーバA と サーバB の間で不一致等が発生す ることを fake と言います。 そのような場合にも、“ Cannot send to channel ”が表示されます 。この際、同一サーバ上および、整合性の取れているサーバ間での 発言に関しては問題なく発言ができますが、fake の発生しているサーバ間 では発言および、チャンネル情報が上手く伝わらないことがあります。このような状 態になれば、発言毎にエラーメッセージが出るため気持ちの良い物ではありません。 このようになった場合、根本的な解決方法は無く、自然と解決するのを待つ しか有りません。

【 ホスト名とIPアドレスの関係 】

すべてのマスクの書き方に共通しますが、+b +e +I のマスクを書くとき、ホスト名 で書くと、逆引きできていない場合、該当しませんよね?しかし、IRCには便利な機 能があり、IPアドレスでマスクすると、逆引きに関係なく、適用されます

例えば、 192.168.100.10 の逆引きが host10.example.jp だったとしましょう。 勿論 ban 等に、 *!*@*.example.jp としてきても良いでしょうが、192.168.100.10 としても、逆引きが出来る、出来ないにかかわらずにかかわらず、 ban が出来ます。

言い換えれば、 その人が /29 なり /28 なりのアドレスブロックを持っていたとし、 逆引きがバラバラだったりする場合にも有効です。

【 MAXBANS 】

以外と知られていない制限事項として、MAXBANSと言うのがあります。 struct_def.h のソースを見ると、以下のように有ります。

#define MAXBANS         30
#define MAXBANLENGTH    1024

これは何を示しているかというと、+b, +e, +I の合わせた合計になります。 すなわち、MAXBANS が 30 という値になっていると言うことは、+b, +e, +I の合計が30個までしか設定出来ないと言うことになります。 MAXBANLENGTH については、全体の +b, +e, +I のbyte数になると思います。 すなわち、どちらかが先にlimitにいってしまうと、それ以上設定が出来なくなるよ うになります。その際、エラーメッセージに以下のように表示がされます。

Channel list is full

また、RFC2812にも以下のように記述があります。

478 ERR_BANLISTFULL 
"<channel> <char> :Channel list is full" 

が、しかし、例外があり、30個以上設定することが可能です。 方法としては、かなり鬼畜的な手法であり、勧められた物では有りませんが、 サーバスプリットを利用する事により、30個以上の設定が可能となります。 サーバスプリットとは、IRCサーバ間の接続が切れ、各々のサーバが孤立する事です。 このようなケースが発生した場合、30個以下まで消さない限り、追加、編集が 出来なくなり、“Channel list is full”と表示されるようになります

方法は、A と B のサーバがネットワークで繋がりリンクしていたと仮定します。 後にネットワーク的なトラブルにより、サーバスプリットが発生し、各々のサーバが 独立した状態になったと仮定します。その際、スプリットする前には、複数の人が チャンネルオペレータ権限を持っておりスプリット後に、チャンネルオペレータが 各々のサーバに別れたとします。そのときに、チャンネルオペレータを持っている人が、 +b, +e, +I を複数設定した場合、各々のサーバでは30個未満設定されたとします (お互いのサーバ上のチャンネルに設定した合計が30個を越える物とする。)

後にスプリットが解消し、元の通りにサーバが接続された場合、A と B とのサーバで 整合性をとるために、チャンネルオペレータ情報、+v, +b, +e, +I 等をサーバが付けた ように見えます。 このようにして、サーバに付けさせたように見せかけることにより、30個以上の設定を チャンネルに付けることが可能となります。もし、この手法を用いて30個以上の設定を チャンネルに設定した(させた)場合、チャンネルには30個以上のMAXBANSが設定 されているため、合計30個以下になるまで、追加、修正をすることが出来なくなります。

上記の手法を使うことにより、先ほど「+b/+m されて発言が出来ません。」で書きま した、fakeと言うことが発生することも十分のあり得るため注意が必要です。

Copyright (C) 1998-2004 tomocha
Last update: 2004-07-08
tomo@gyojya.jp