README.patches (history)
(New page: <pre> The available patches for 2.8*mu servers are: Tp8 = TimeStampPre8 - A protocol which disallows netsplit ops and channel desynchs. Bquiet - does not allow a pe...) |
m (README.pacthes (history) moved to README.patches (history): Typo!) |
Current revision as of 17:50, 14 January 2009
The available patches for 2.8*mu servers are:
Tp8 = TimeStampPre8 - A protocol which disallows netsplit ops and channel
desynchs.
Bquiet - does not allow a person who is banned to speak over the channel
Silence - Cuts off flooding at local server
Anc = Anti-Nick collide - *Intentional* nick collides are impossible with
this wonderful patch.
W = Wallops - lets you send messages to other IRC ops
ban = BanInformation - Lets you see who did a ban and when, as well
sw = /stats w - lets you gather statistics on average client connects
To = TopicInformation - Lets you see who set the topic for a channel and when
S = Signon Time - Tells you when a local user signed onto IRC
Cl = Client connect - Notifies opers on your server of client connects/
disconnects (with disconnect reason)
TT = Trace Times - displays the time (in secs) since your server last heard
anything from a client/server, when you do /trace.
KL = K-line comments - Allows you to modify the lame "no ghosts allowed" default
comment to whatever you wish, or alternately, display a
file to a rejected client.
OF = Oper fail patch - displays a warning to current ops when someone fails
in entering the right oper password.
MC = Mixed case patch - useful for those pesky clone bots and hacked logins;
disallows userids which have mixed case or control chars
N = Note - allows you keep a "note" for other users, amongst other things
-----------------------------------------------------------------------------
Explanations for these patches follow.....
Help on patches written by Mandar Mirashi (mmmirash@mailhost.ecn.uoknor.edu)
Mmmm on IRC.
=============================================================================
TIMESTAMP
=============================================================================
Author: Carlo, carlo@sg.tn.tudelft.nl, Run on IRC.
Info on TS protocol:
TSpre7
------
Effects of the TS protocol:
> No mode wars possible.
When you take someones op there are three possibilities:
- You were too late (You was already de-opped on your server).
- You take it (On the *whole* net).
- You start taking it (on your server, but it is 'bounced' (ie your mode
change is cancelled); This occurs when you try to do mode change
direct after a net re-connection in a situation were you hacked op by
net-break riding.
> No desynchronisation possible.
> No unnecessary MODE msg send. You can't send 'double' mode's that don't
make sense. Servers don't send unnecessary MODE's either.
> Hacking op is from now on *only* possible by admins that hacked their
servercode, and therefor easier to prosecute. Also you can 'hack' op still
exactly like now (by riding net break) on an *opless* channel.
> The protocol is fully compatible with older servers: It is invisible
and it works with old servers like this: Every 'block' of direct connected
2.8.x.TS servers will stay synchronized, Hacking op is impossible by means
of riding a net break between two TS-servers on channels that were created
within that block. In all other cases the same happens as without TS.
Here follow technical details implemented in TSpre7:
------
Reference: 2.8.14/15.TSpre7
Full list of TS-MODE-Change protocol:
-Mode changes (originating by clients) are refused only:
1) from a client that is directly connected and has no chan ops on
the channel on its server.
2) when not being a change of the internal state of a server (Well, refused
is to strong, propagation of the mode is just unnecessary and thus not
done).
3) from someone flagged as de-opped-by-server. (flag is reset when this
person is opped again by anyone) (The server detecting this mode change
cancels the mode change, by bouncing it upstream, thus keeping the net
synchronized).
-An extra parameter is added behind MODE changes *done* by servers, sended
*to* other servers. It is a Universal Time in ascii seconds. This extra
parameter is NOT sended when it is 0 (can happen with old servers on the
net), 0 means <NONE> rather then Jan 1st 1970 :).
This parameter is the creationtime of the channel being: the universal time at
which the channel was created by a *local* client; or the non-zero received
creation time from an other server (as parameter with a mode change) that
was earlier then its own; or equal 0 when the channel was created by
a non-local client and no MODE with TS was received (yet).
-Of the channel_flags is 1 bit more used: CHFL_DEOPPED, set when de-opped
by a server (compare CHFL_CHANOP, set when channel operator). It's reset
when opped. (And starts reset on joining (creation?) of a channel, this
will be changed to 'set' on join, when all servers have TS; making detection
of op hacking by admins a bit easier).
-Timestamps (sended by TS-servers) are handled as follows:
Received TS Own TS Bounced/Propagated
equal equal propagated
later >0,earlier if ops: bounced with own TS
if no ops: propagated with own TS
(own TS is sended upstream too, to make sure
TS stays synchronized).
earlier later TS copied, propagated
none any propagated, own TS sended.
>0 none if ops: propagated, no TS sended, own TS stays 0.
if no ops: TS copied, propagated.
-A mode change +/-o nick (+/- v) from a person that is deopped by a server
results in a -/+o nick back up stream (and is not propagated) if it was
an attempt to change the internal state of the receiving server.
-kick is handled as mode -o, internal state 'not on channel' being 'already
de-opped'. Bounce includes JOIN and restoring o and v flags.
(Effect: You don't even *see* the kick on one side, on the other side
the person joins again and gets his flags back from the bouncing server).
-A received TimeStamp that claims a creation time *earlier* then that
this server dissapeared from the net results in a HACK: notice (with
time difference in seconds). Bye OPER.. (This meaning, to hack op
on an existing channel that was created 15 minutes before you disconnected
your server, you will have generated a HACK notice: Clock set back at least
900 seconds by <nick>.) (Not yet implemented, prob. in pre8).
TSpre8
From: Carlo Kid - Runaway <carlo@sg.tn.tudelft.nl>
Subject: *** IMPORTANT; RFC
To: wastelanders@rush.cc.edu (New Wastelanders MailingList)
Date: Thu, 14 Apr 94 18:03:38 METDST
Mailer: Elm [revision: 66.33]
Status: RO
Hi, please read this carefully and respond if you think it will result
in INCORRECT behaviour under any circumstances:
Here follow technical details implemented in TSpre8:
------
Reference: 2.8.17.TSpre8
Full list of TS-MODE-Change protocol:
-Mode changes (originating by clients) are refused only:
1) from a client that is directly connected and has no chan ops on
the channel on its server.
2) when not being a change of the internal state of a server (Well, refused
is to strong, propagation of the mode is just unnecessary and thus not
done).
3) from someone flagged as de-opped-by-server. (flag is reset when this
person is opped again by anyone) (The server detecting this mode change
cancels the mode change, by bouncing it upstream, thus keeping the net
synchronized).
4) When a '0' as timestamp is received, originating from a server (see below).
Then the whole mode is ignored, a HACK notice is sent to all ops and the
string is propagated as received.
-An extra parameter is added behind MODE changes *done* by servers, sent
*to* other servers *containing* a +o, -o, +v or -v.
It is a Universal Time in ascii seconds.
Whenever a HACK is detected, a HACK: notice is sent to all local opers,
and the full MODE is propagated with a '0' as timestamp, generating
a HACK notice on all other servers.
Otherwise this parameter is the creationtime of the channel being: the
universal time at which the channel was created by a *local* client;
or the non-zero received creation time from an other server (as parameter
with a mode change) that was earlier then its own; or equal 0 when the
channel was created by a non-local client and no MODE with TS was received
(yet).
-Of the channel_flags is 1 bit more used: CHFL_DEOPPED, set when de-opped
by a server (compare CHFL_CHANOP, set when channel operator). It's reset
when opped. It starts *set* on joining (creation?) of a channel, making
detection of op hacking by admins a bit easier.
-Timestamps (sent by TS-servers) are handled as follows:
Received TS Own TS Bounced/Propagated
equal equal propagated
later >0,earlier if ops: bounced with own TS
if no ops: TS copied, propagated
earlier later TS copied, propagated
0 or none any HACK generated, 0 propagated, own TS is kept
>0 none TS copied, propagated.
-A mode change +/-o nick (+/- v) from a person that is deopped by a server
results in a -/+o nick back up stream (and is not propagated) if it was
an attempt to change the internal state of the receiving server.
-kick is handled as mode -o, internal state 'not on channel' being 'already
de-opped'. Bounce includes JOIN and restoring o and v flags.
(Effect: You don't even *see* the kick on one side, on the other side
the person joins again and gets his flags back from the bouncing server).
-A received TimeStamp that claims a creation time *earlier* then that
this server dissapeared from the net results in a HACK: notice (with
time difference in seconds). Bye OPER.. (This meaning, to hack op
on an existing channel that was created 15 minutes before you disconnected
your server, you will have generated a HACK notice: Clock set back at least
900 seconds by <nick>.)
From: Carlo Kid - Runaway <carlo@sg.tn.tudelft.nl>
Subject: TSpre8 can work! :)
To: wastelanders@rush.cc.edu (New Wastelanders MailingList)
Date: Wed, 20 Apr 94 11:44:39 METDST
Mailer: Elm [revision: 66.33]
Status: RO
Well... it took me a few days (a night and some dreams actually), but
I think I found a solution for the problem I mentioned during the meeting :)
Let me first repeat the problem:
- I stated that TSpre8 would prevent op hacking by admins, but... later
I realized that that was impossible the way wanted it :(
My idea was at first: Simply generate a HACK notice when a server
comes on the net with a creation time earlier then when it did split off
(and earlier then my own creation time). This sounds nice, but in
even this simple case it doesn't work:
Server A and B, users a and b:
A -- B
|
@a TS=100
Split at t=200
A B
|
@a
b joins at t=300
A(TS=100) B(TS=300)
| |
@a @b
Net joins:
A -- B
| |
a b
Both are de-opped: b because he sends a TS of 300 with is greater (later)
then 100 (correctly: he used the netbreak). And a is deopped with a
HACK notice by B, because he introduces 1) a TS earlier then the existing
TS (100<300) and 2) the 100 is earlier then the time the split occured.
The reason why this goes wrong is simply because B *forgets* the channel
AND the TS of 100, after the split... If B would *keep* in memory that
the channel existed on A and with what TS, it would be possible, but only
at cost of a lot of extra memory usage...
Now my new idea :) It allows hacking, but only in not so very interesting
cases... And at least it makes it extremely difficult for a newbee, so we
might at least catch 99% before they understand how it works :)
(This explanation should not be on a public ftp site anymore after a while :)
New rules:
- Servers that are OFF the net for more then one day are forgotten.
- New servers (or forgotten servers), are always bounced except on channels
that have no ops (when they create a channel of their own thus :) unless
the receiving server is younger then one day and the introduced TS is
earlier then the start up time (minus 10 minutes :/) of the receiving server.
'Birthdays' of those servers are also kept.
- A server that splitted off while a channel already existed, and thus
has a creation time earlier then the "received squit time" of that
server, is not allowed to introduce an earlier timestamp then the
creationtime of the channel (HACK), and also not an equal TS when
younger then one day.
- A server introducing a server with an earlier "time of received squit"
inherrits that time as its own "time of received squit".
This allows to hack op on a channel that didn't exist when you splitted
(not interesting). You also can't keep a server off the net till you need
it (a telnet connection), because those can't do anything for one day long,
unless they send the TS *equal* to the existing TS (The only exception :(),
having to connect between two and one days before the hack, break between
zero and one day before the hack but before the channel existed, connect
and hack with equal TS.
What do you think? Just for fun? :)
Apart from that it would be suspicious when someone connects/breaks every
24 hours a "test" server, channels that exist longer then one day are
unhackable.
The "disadvantages" are: servers that break off the net for *longer* then
one day, but keep a channel up with an op, on *both sides of the net, will
be completely de-opped after reconnection.
*** IMPORTANT:
I am absolutely not sure ;) if there aren't any other disadvantages or
unwanted effects :) Please, think this over and mail me if you find some
objection...
Run
From: Carlo Kid - Runaway <carlo@sg.tn.tudelft.nl>
Subject: 2.8.19.U3 RELEASED
To: wastelanders@rush.cc.edu (New Wastelanders MailingList)
Date: Sun, 22 May 94 14:15:41 METDST
Cc: carlo@sg.tn.tudelft.nl
Mailer: Elm [revision: 66.33]
Status: RO
Hi all :)
Proud to present: 2.8.19.U3 :)
I have spend *enormous* amounts of time in TESTING this version,
and I really hope it is completely bug free, but the changes are
very big, so maybe persons who only want to upgrade/compile ONCE
should wait a little longer then the compile cracks we have here ;)
For real testing we need the HUBs though! So please, don't hesitate,
Delft (a HUB) is running it already for a long time, also linked to
other 2.8.19.U3 test servers.
Before I'll tell about whats new in U3, I want to especially thank
President for the tremendous help in testing TSpre8 -- I would never
have been able bring up the stength to go through the difficult
periods without him being there to listen to my technical complaints ;)
=======================================================================
NEW in .U3
----------
First all, TSpre8.
It did not become what I hoped/expected to be possible :(
Hacking will still be possible, but at least it will be a LOT
more difficult when you don't know what you are doing, and I think
we WILL catch (new) admins that think they can abuse their powers
to be GOD on "their" channel.
Especially, nobody will be able to hack *anything* with a normal nick.
And because server modes are more obvious a hack, this alone is a
step forward against admin hacking prevention imho.
The .patch file is
-rw------- 1 carlo users 65142 May 22 01:29 irc2.8.19-TSpre8.patch
big.
I'll now brows through it and mentions changes in the order they appear
in the .patch file, arbitrary order thus ;)
Zombies
-------
As mentioned before on 'wastelanders', I changed the internal way a KICK
is handled, to be able to stop illegal -hacked- kicks from *outside* the
channel. This has no effect on server-server protocol nor on server-client
protocol. But because this way it is possible to keep (a little) memory
for channels you're not on (being kicked from) I thought it would be no
more then logical to stop people from joining the usual 10 ten channels
at the same time, *including* the ones you are kicked from (because they
occupy memory). This memory is released when you 1) Try to rejoin (so with
all people having a auto-rejoin-on kick NOTHING changed at all), or 2)
when you do a part - this is new and only intended to use when you do
NOT have auto-rejoin, when you do not even WANT to rejoin, or try, assuming
you might not be banned, when you have been kicked like this of a lot of
channels and all together are "on" 10 channels so you NEED to leave one
before you can join another... For this rare case, you must know on
*which* channels you "are", therefor this is visible when you do a
/names, or /who or /whois to yourself. It is never visible for others.
Example:
12:07 * Run (Daryl@sg.tn.tudelft.nl) has joined channel #wasteland
*** Mode change "+o Run" on channel #wasteland by Wasted
*** #wasteland : created Fri May 13 17:08:34 1994
<Macro> Hi Run !
*** You have been kicked off channel #wasteland by Run (Test)
*** Run is Daryl@sg.tn.tudelft.nl (/msg Run profile)
*** on channels: !#wasteland
*** on irc via server Delft.NL.EU.undernet.org (Runaway Server
+[130.161.188.188])
*** Run is away: Writting E-mail
*** Run is an IRC Operator
*** Run has been idle for 642 seconds.
As you can see, the channel is marked with a '!' to show you are NOT
not that channel... Both, a part #wasteland as well as a join (being
not able to actually join because of ban, invite-only, key or limit), will
remove you from this channel. The part will be sent back to (only) you, and
everything has turned out to be 100% compatible with ircii protocol.
Finally, of course the channel is removed when everyone is kicked and/or
left the channel (a channel with only zombies is removed immedeately).
#define RPL_CREATIONTIME 329
--------------------------------
A new numeric is sent when you ask for a MODE of a channel, by doing
/MODE #channel
without parameters.
The reply is the same as before, but followed by a new numeric 329:
/MODE #wasteland
Delft.NL.EU.undernet.org 324 Run #wasteland +t
Delft.NL.EU.undernet.org 329 Run #wasteland 768845314
To supress this, you'll have to add something like:
ON ^329 *
to your .ircrc file. If you want to see this new numeric, you would
add
On ^329 "*" echo *** $1 : created $stime($2)
It turns out that ircii clients ask for this mode when you join a
channel, therefor you will see the creationtime when you join a channel,
I'll leave it as an exercise to suppress this, but still being able to
see it when you specifically ask for it :)
New ircd.conf line
------------------
This is IMPORTANT :
In order for Uworld to work you MUST add those lines to your ircd.conf file:
U:Uworld.undernet.org::*
U:Underworld.nl::*
The later to allow the backup Underworld.nl to still function.
If you forget this, or do it wrong, your server might refuse to accept
certain mode changes from Uworld.undernet.org and start *bouncing*
modes done by lusers that got op from it. The name of servers allowed
to hack have to be agreed upon totally, by all admins. If one admin
removes his U: line, the service will not work always correctly.
When a server does a mode change that is detected to be a hack, you
will see -as an oper, or +s luser- this notice:
-> *uworld* opcom MODE #wasteland +o Mmmm
!Uworld.undernet.org! Run is using Uworld to : MODE #wasteland +o Mmmm
*** Notice -- HACK: Uworld.undernet.org MODE #wasteland +o Mmmm
*** Mode change "+o Mmmm" on channel #wasteland by Uworld.undernet.org
Normally, this HACK notice would NOT take effect! You still *see* the
HACK notice for the U: line server(s) but then they DO take effect.
Every other message (some including the word HACK) do also take effect,
and are only a warning that someone is MAYBE hacking...
I didn't see it occur yet.
Removed bugs
------------
I did find some bugs in TSpre7, never thought that was possible :)
I forgot what it exactly was, but under (very rare) circumstances it
could be pretty serious :/
One rather important thing is that now the TimeStamp is sent during a
net re.join when there are no ops. Before it was possible to create
a partly TimeStamp less net on an opless channel. TSpre8 garantees
that the TS is synchronized on the whole net at any time.
Other messages
--------------
Apart from the (true) HACK notice, you can get a:
BOUNCE or HACK: notice, which does take effect and is most probably
just a bounce of a mode done by an attacker: someone immedeately after
a net re.join with his net.ride ops trying to de-op the others.
I don't think this will happen often because it will be clear to all lusers
that it is useless to try.
NET.RIDE on opless #channel notice, you'll see this if someone does
really abuses a net break to get ops on some opless channel. The mode
does take effect however.
FULL bounce of modes
--------------------
When before someone would ride a net break, and try something, ONLY
his +/- o/v modes. Other modes like +mlk 1 \\|/\|/ would still take
effect. With TSpre8 this changed... All modes (except bans) are bounced
when someone rides a net break. Also the bouncing is more compact, while
with TSpre7 every o and v mode took one line, now all modes are kept into
one line.
More allowed
------------
Before you was (how lame) not allowed to mix things like k, o and v...
Now you are allowed, why not? Also you can use up to six parameters,
really gives you a power kick ;)
*** Mode change "+vvvvvv flux epa Skip Run Mmmm gyn" on channel #wasteland by
+Run
User friendly mask fixing
-------------------------
The lame way Avalon fixes a mask (for a ban) is like this:
/mode * +bb *.tudelft.nl Daryl@sg*.tn.tudelft.nl
becomes:
*** Mode change "+bb *.tudelft!*@* Daryl!*@sg*.tn.tudelft.nl" on channel
+#wasteland by Run
The same on a TSpre8 server gives:
*** Mode change "+b *!*@*.tudelft.nl" on channel #wasteland by Run
While just Daryl@sg*.tn.tudelft.nl results in:
*** Mode change "+b *!Daryl@sg*.tn.tudelft.nl" on channel #wasteland by Run
which what one would expect!
----------------------------------------------------------------
Goodluck with compiling,
Run
PS If you encounter any problems, realize it is VERY unlikely that
it is .U3, but if you really think so, then first try to compile
plain 2.8.19. If you succeed, save the Makefile the include/config.h
and the include/setup.h. Unpack .U3, replace those files and recompile.
With this I assume you don't put your ircd.conf inside the source
directories of course, that would still have the paths set wrong then.
A smart move is to make patch file once for your Makefile/config.h :
First ONLY edit the Makefile and config.h (or copy the them from a
working source tree to a empty directory), and then make a diff with:
diff -rc irc2.8.19.clean irc2.8.19.my.makefile > Makefile.config.h.patch
That really speeds up upgrading with later versions.
(irc2.8.19.my.makefile only needs to contain
irc2.8.19.my.makefile/Makefile
irc2.8.19.my.makefile/include/config.h )
Of course, keep the include/setup.h seperately.
### KILL for Mmm. Mmmm (stop it lamer (unnecessary flooding of alexbot))
=============================================================================
BQUIET
=============================================================================
Author: Carlo, carlo@sg.tn.tudelft.nl, Run on IRC.
Helpful ideas by: Aaron, agifford@sci.dixie.edu, Karll on IRC
In order to fight flooding, and as discussed on wastelanders, banning
someone on a channel will now also stop him from doing anything visible
on the channel. This allows to let someone see what you think of him
without even kicking him, he will leave by himself.
He will still be able to appologise by private msgs of course and then
he can be de-banned. A ban is this way a short cut for +m+vvvv everyone
excpet the flooder. Note that even NICK floods are stopped: When you are
on a channel where you are banned, you are not allowed to change your nick.
=============================================================================
SILENCE
=============================================================================
Author: Carlo, carlo@sg.tn.tudelft.nl, Run on IRC.
Helpful ideas by: Aaron, agifford@sci.dixie.edu, Karll on IRC
My solution to flooders with clone bots etc :)
Let the user that GETS flooded decide he doesn't want that and stop
the flooder right at his own server (the server of the flooder).
This is a new command, and the clients will need unfortunately a few
lines in their .ircrc before it can work.
Moreover, before this works, ALL servers must have .U3.
The lines I use at the moment are:
ALIAS SILENCE QUOTE SILENCE
ALIAS SILE QUOTE SILENCE
ON ^RAW_IRC "% SILENCE %" echo *** $*
It turns out that some auto-rejoin on kick lines, like Davemans toolbox,
disables the use of ON RAW_IRC, or at least makes it work incorrectly.
You should disable this auto-rejoin line and you could add the one I use
instead:
ON ^RAW_IRC "% KICK % % *" {
IF ([$3]==[$N]) {
//QUOTE JOIN $2
ECHO $MID(11 5 $STIME($TIME())) * You have been kicked off channel $2 by $LEFT($INDEX(! $0) $0) \($MID(1 256 $4-)\) } {
ECHO $MID(11 5 $STIME($TIME())) * $3 has been kicked off channel $2 by $LEFT($INDEX(! $0) $0) \($MID(1 256 $4-)\) }
}
which are 6 lines, not 8.
The way the silence patch works is as follows:
When you add a silence mask (using the same user friendly mask fixing)
like:
/SILENCE Tsunami*@
It will echo back to you how it is added:
*** Run!Daryl@sg.tn.tudelft.nl SILENCE +*!Tsunami*@*
Note that there is a '+' infront of the mask now.
You can also type:
/SILENCE +bot*
*** Run!Daryl@sg.tn.tudelft.nl SILENCE +bot*!*@*
If you want to silence one particular nick, you must add the '+', because
when you do:
/SILENCE nick
and 'nick' exists, you will get the silence list of nick. Just using
/SILENCE gives your own silence list:
*** Run bot*!*@*
*** Run *!Tsunami*@*
*** End of Silence List
However, check the silence list of someone ELSE make only really sense
when you already did sent a message to this person. Because a silence
mask only propagates to the server of the flooder when it is actually
necessary. For instance: You can add up to 5 silence masks and delete them
again and it will only be local to your own server. Only when someone
would message you, matching a mask, the mask propagates to the server of
the flooder. And stays there till you signoff, or till you delete it.
If you delete a mask, it follows the same path as the +masks...
As a result of this, +s lusers and opers will see the message:
*** SILENCE : Unknown command (from Lausanne.CH.EU.UnderNet.org)
When someone from *behind* a non .U3 server sends you a message
(Lausanne is this case). So, you will STILL be flooded ;) UNTIL ALL
servers are upgraded... (Or must do -s, but at least the net is flooded).
To: wastelanders@rush.cc.edu
From: agifford@sci.dixie.edu (Aaron Gifford)
Subject: HELP with HELP for SILENCE
Status: RO
Hey, here's a VERY VERY VERY rough draft of a HELP entry for SILENCE,
assuming it becomes a new command for ircII and not a replacement for
IGNORE either via new code, or aliases like:
ALIAS SILENCE { QUOTE SILENCE $* }
Anyway, PLEASE PLEASE PLEASE alter, modify, correct, add, hack-up, etc this
rough draft and send me your alterations. I just typed this up VERY
quickly because StGeorge is now running irc2.8.19.U3.1. The bug I mention
in the file will hopefully disappear very soon, so that text will have to
do likewise and vanish. :)
Here it is, draft #1 HELP for SILENCE:
Usage: SILENCE [<nick>]
SILENCE [+|-<pattern>]
SILENCE allows you to TOTALLY ignore all private messages (PRIVMSG's)
and notices (NOTICE's) from any user whose nick!user@host matches
the <pattern> parameter. The characters * and ? can be used
as wildcards in the pattern.
If you wanted to ignore all users from "somewhere.com" you would use:
SILENCE +*!*@somewhere.com
To ignore some with the nickname "Jerk" you would use:
SILENCE +Jerk
NOTE: The server will complete the pattern, storing it as "Jerk!*@*"
The only drawback of just SILENCE'ing someone by nickname only is
that the user could quickly change nicknames to avoid your pattern.
To remove a pattern, use a - before the pattern you want to remove.
When the command is used without any parameters, the server will list
all stored patterns you are currently ignoring with the SILENCE
command.
When used in the first form listed, you will see the SILENCE list for
the specified user. This list is not necessarily complete nor accurate
because of how servers share SILENCE information internally. You can
check to see if someone is ignoring you with SILENCE by first sending
that user a private message, then using the command to see the user's
SILENCE list.
Currently there is a bug in the servers (hopefully to be fixed soon)
that will add the nickname you specify to your SILENCE list when you
attempt to see that user's SILENCE list if that user is not currently
online.
Because SILENCE is a part of the IRC server protocol (on the Undernet)
it works much more efficiently than IGNORE, but is limited to a very
brief list of patterns. Also, you don't have as may options as you
do with IGNORE. If a user is flooding you, SILENCE is many times
more efficient than IGNORE because the offending user's PRIMSG's or
NOTICE's (including CTCP) are stopped at the server and never even
sent to your client.
See Also:
IGNORE
From: Carlo Kid - Runaway <carlo@sg.tn.tudelft.nl>
Subject: Re: HELP with HELP for SILENCE
To: agifford@sci.dixie.edu (Aaron Gifford) (Aaron Gifford)
Date: Wed, 25 May 94 12:29:37 METDST
Cc: wastelanders@rush.cc.edu (New Wastelanders MailingList)
In-Reply-To: <9405250313.AA18446@sci.dixie.edu>; from "Aaron Gifford" at May 24, 94 9:20 pm
Mailer: Elm [revision: 66.33]
Status: RO
> Here it is, draft #1 HELP for SILENCE:
>
> Usage: SILENCE [<nick>]
> SILENCE [+|-<pattern>]
>
As it is now (I do not consider what you mentioned as a bug, I was aware
of this effect and didn't choose to alter it), it really is:
Usage: SILENCE [+|-]<pattern>
Or : SILENCE <nick>
When you leave the '+|-' away A '+' is assumed.
The second possibility allows you to check your own silence lists, or
allows to check if you are silenced by someone after you did message
him but didn't get a respond (did ping him for instance).
Indeed, this could be interpreted as a pattern, when <nick> doesn't
exists.
> If you wanted to ignore all users from "somewhere.com" you would use:
> SILENCE +*!*@somewhere.com
SILENCE somewhere.com
would do.
> When used in the first form listed, you will see the SILENCE list for
> the specified user. This list is not necessarily complete nor accurate
> because of how servers share SILENCE information internally. You can
> check to see if someone is ignoring you with SILENCE by first sending
> that user a private message, then using the command to see the user's
> SILENCE list.
Mention that a EVAL CTCP <nick> PING $TIME() is better...
It would not be necessary to do the silence if the ping returns...
To determine between huge lag and silence, you have to do the silence
check after that.
If you add something like this in the manual, people will automatically
wait a while after the 'message' (ping), so that the servers have time
to send the silence mask back. Otherwise they might think they can do
a quick msg+silence at the same time. Nah... Not too important, unless
with huge lag + silence combination.
>
> Currently there is a bug in the servers (hopefully to be fixed soon)
> that will add the nickname you specify to your SILENCE list when you
> attempt to see that user's SILENCE list if that user is not currently
> online.
I didn't consider this as too bad...
But if people want it, I can change it so that you MUST add a '+' to
add a mask that doesn't contain a '.', '!' or '@'.
That would lead to 2.8.19.U3.2 and a very tiny patch for the people who
already compiled .U3
Run
=============================================================================
U3 - required additions to .ircrc
=============================================================================
From: Carlo Kid - Runaway <carlo@sg.tn.tudelft.nl>
Subject: Re: .ircrc codes for the new patches :)
To: lamberdc@dad.cs.tuns.ca
Date: Mon, 23 May 94 11:41:31 METDST
Cc: wastelanders@rush.cc.edu (New Wastelanders MailingList)
In-Reply-To: <9405222118.AA02415@dad.cs.tuns.ca>; from "Donald "WHIZZARD" Lambert" at May 22, 94 6:18 pm
Mailer: Elm [revision: 66.33]
Status: RO
> hiya All
> I was wondering if some one could send me a copy of the script/
> for the new patches including the ban , topic and client connecting patches.
>
> And whatever is now out with the new .19 code :)
>
> thanks
>
> -- Donnie
>
> aka WHIZZARD
The ftp.undernet.org:/pub/undernet/servers/Patches/README file:
These are lines you need to add to your .ircrc file in order
to use all posibilities .U3 profides you:
To see when a channel was created:
On ^329 * echo *** $1 : created $stime($2)
When your server has the .ban patch use this to see who did a ban and when:
On ^367 * if ([$4] != []) {echo *** $1 \($3 - $stime($4)) $2} {echo *** $1-}
---------------------------
When ALL servers upgraded to .U3, you can use this command:
ALIAS SILENCE QUOTE SILENCE
On ^RAW_IRC "% SILENCE %" echo *** $*
Use this as:
/SILENCE +mask
To add 'mask' to your silence list (will completely stop all private
messages from people matching 'mask' with their nick!user@host).
You can VIEW your silence list by typing:
/SILENCE
If you message someone and he doesn't react (like with ping), then you
can check if you match a silence mask he added by viewing his silence list
with:
/SILENCE nick
A mask can be deleted by using the command:
/SILENCE -mask
When the some messages you from behind a NON-.U3 server you will not
receive his message but the line:
*** Unknown command (SILENCE) (From server.name.undernet.org)
instead, so you will still be flooded.
We hope all servers will be upgraded within a few months.
------
And my ircd.motd from Delft* :
*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%
N E W : - This server now runs the official released
beta version 2.8.19.U3.1.ban
For you as users this means that:
-More security : .U3 contains the .TSpre8 patch with
disallows even ADMINs of servers to hack op on your
channel with a nick, most server modes are detected.
-The possibility to see the *creationtime* of a channel
(used with the TimeStamp (TS) protocol - unique on
undernet (disables the possibility of 'net.riding'))
-The possibility to stop EVERY kind of channel flooding
by *banning* someone : Now a ban stops not only
part/join floods, but also message floods and even
nick floods!
-The possibility to see who did when a certain ban.
-The possibility to stop anyone flooding you with
any kind of private messages at his *own* server!
(This will only work when ALL servers have upgraded)
To be able to use all of this, ftp to sg.tn.tudelft.nl
login: ftp ; password : anything ; file: /pub/README
Put those lines in your .ircrc initialisation file !
Have fun, Run.
----
Run
=============================================================================
U3.1 -> U3.2
=============================================================================
From: Carlo Kid - Runaway <carlo@sg.tn.tudelft.nl>
Subject: *BUG* .U3.1 found !!
To: wastelanders@rush.cc.edu (New Wastelanders MailingList)
Date: Wed, 25 May 94 16:45:39 METDST
In-Reply-To: <457.9405250732@ccws-09.brunel.ac.uk>; from "James T Lowe" at May 25, 94 8:32 am
Mailer: Elm [revision: 66.33]
Status: RO
> :->
> :-> Hiya..
> :->
> :-> Here's what I observed tonight:
> :->
> :-> *** Mmmm (mandar@roosevelt.ecn.uoknor.edu) has joined channel #friendly
> :-> *** Users on #friendly: @Mmmm
> :-> *** Mode change "-o Mmmm" on channel #friendly by Uxbridge.*
>
> Not surprising :
>
> #friendly RedRum H* cs93jtl@ccws-09.brunel.ac.uk
> #friendly Emmy H lamphear@cheshire.oxy.edu
> #friendly ChemBot H@ cmrobert@hellcat.ecn.uoknor.edu
>
>
>
> >From Norman :
>
> *** ChemBot is cmrobert@hellcat.ecn.uoknor.edu (Charles Michael Roberts)
> *** on channels: @#ChatZone
> *** on irc via server Norman.OK.US.undernet.org
> *** ChemBot has been idle 10 minutes
>
>
> and from Uxbridge :
>
> ** ChemBot is cmrobert@hellcat.ecn.uoknor.edu (Charles Michael Roberts)
> *** on channels: @#chatZone @#friendly
> *** on irc via server Norman.OK.US.undernet.org
>
> :-> But,
> :->
> :-> *** Mmmm has left channel #friendly
> :-> *** Mmmm (mandar@roosevelt.ecn.uoknor.edu) has joined channel #test
> :-> *** Users on #test: @Mmmm
> :->
> :-> works fine..
> :->
> :-> Is this due to the U lines? Uworld was in no way involved though :-(
> :->
> :-> I personally feel that uxbridge's retaining timestamps of old channels -
> :-> Run, can ya take a look asap. It can prove most distressing for our users :(
> :->
> :-> Thanks!!
> :->
> :-> Mmmm
>
>
Weeehhhw, yeah a real bug :/
RedRum and I looked for it for almost 4 hours before it was found...
I will release .U3.2 and a patch for .U3.1-U3.2 asap...
Description of bug:
When someone gets kicked (and doesn't (try to) rejoin), it is flagged
as a zombie. After a net-break, users are mutual re-joined on both
sides of the net. It turned out that a zombie is also rejoined after
a net rejoin.
What happened with ChemBot:
ChemBot was on #friendly via Norman (non TSpre8). It was banned and then
kicked. It tried to rejoin, but Norman didn't allow that (ban).
Delft never saw this try, and ChemBot stayed as a zombie on #friendly.
Then Delft-UxBridge broke and reconnected... Delft did send a JOIN for
ChemBot to UxBridge, ending up in a nick-desynced state.
When Mmmm joined #friendly, he was the first on #friendly on all of the
net except UxBridge... He was opped by Norman, but that is considered
as a HACK by UxBridge and was bounced (ChemBot was still there *with*
ops (those flags aren't reset when someone is marked zombie)).
The second time Mmmm joined, he again got ops from Norman which now
was accepted by UxBridge because this +o could be a BOUNCE of the de-op
by UxBridge (Generating a BOUNCE or HACK: notice on UxBridge).
Run
From: Carlo Kid - Runaway <carlo@sg.tn.tudelft.nl>
Subject: Release 2.8.19.U3.2
To: wastelanders@rush.cc.edu (New Wastelanders MailingList)
Date: Wed, 25 May 94 23:30:57 METDST
Mailer: Elm [revision: 66.33]
Status: RO
Hi all,
I released 2.8.19.U3.2
Fixed:
- Rejoining of zombies after net break :/ (ChemBot case)
- Silence command now give: No such nick, when doing /silence nick
- I fixed the way a kick is handle, because in a last minute
thought I realized MURC would get trouble otherwise, see below.
As usual you can get it from ftp.undernet.org:/pub/undernet/servers
Patches/irc2.8.19.U3.1-2.patch : If you already had .U3.1
irc2.8.19.U3.2.tar.gz : If start from scratch (DO SO!!!)
For those who use the irc2.8.19.U3.1-2.patch ...
------------------------------------------
*** EDIT include/patchlevel.h !!!!!!!! ***
------------------------------------------
This patch will change your version to irc2.8.19.U3.2 so if you run
.ban EDIT it !!!
=========================================================================
The change in KICK handling is as follows:
- A kick received from a local client, or for a local client or
from a direction in which the kicked client is located, is
simply handled as before: completely removed from channel, no zombie.
This means also that there is no client-server protocol change anymore:
/who, /whois and /names won't change.
- A kick received for a local client originating from a remote client
lets the server sent a PART upstream. Since this results for non TSpre8
servers in a remote "You're not on that channel" message, this
message is suppressed (would never occur anyway now we are completely
synced).
The reason why this was needed is mainly because MURC constantly kicks
people who have auto-rejoin disabled from different channels. With U3.1
they would get into problems after ten channels (needed to send extra
PART's).
Run
--
-------------------------------------------------------------------------------
| carlo@sg.tn.tudelft.nl | Run @ IRC |
| | Admin of Delft.NL.EU.undernet.org |
| * Don't expect anything of live, | and Ircserver.et.tudelft.nl |
| or you'll miss all the rest of it.| |
-------------------------------------------------------------------------------
=============================================================================
U3->U4, ANTI NICK COLLIDE
=============================================================================
Author: Carlo, carlo@sg.tn.tudelft.nl, Run on IRC.
Hi all...
After we dealt with channel msg-, join/part- and nick-floods (.bquiet),
and with private message flooding (.silence), now in a sort of follow up
to the anti net.break.ride (.TSpre7) and anti admin.hacks (TSpre8) we are
about to deal with one of the last vulnerabilities of our net:
nick-collision bots.
Called .anc (anti nick collision).
- - -
Socially spoken it does the following (I hope):
- Only kills the RIGHT person, when a nick collision occurs.
This would mean:
A) If someone tries to harash by connecting to servers that just broke off
and then take the nick of a person on the other side, both would be
killed on reconnection. But with the .anc patch on both connecting servers,
only the net.break rider will be killed.
B) Secondly, when your server (or side) breaks off and you connect to some
other server on the other side, it happens sometimes that due to lag you get
killed by a nick collision after reconnection of the net.
A and B differ strongly in the sense that in case A the *new* -the youngest-
nick must be killed, while in case B the *old* (lagged) nick must be
killed.
Technically this means that we have to look at the user@host.name too.
This gives rise to some incompatible changes, and therefor, this patch
must be done in two steps: First we deal with the nick-collision bots and
make the server compatible with both - the old and new protocol. And then
once all server upgraded, we deal with the last step: the nick collision
with yourself.
In the future there will be a third possible condition in which we can have
a nick collision: (long example follows, can be skipped)
C) The net breaks, and reconnects else where, and somehow a race condition
occurs between the 'SERVER' messages of the servers of one side.
For example:
Servers: Part A Part B1 PartB2
Nicks a(A),b(B) a(A),b(B) a(A),b(B)
Part A breaks off Part B:
<-- :b QUIT --> :a QUIT
<-- SQUIT serversB --> SQUIT serversA
Result: a(A) b(B) b(B)
A reconnects to Part B1, but immedeately breaks off again:
-->SERVERs A
-->NICK a
-->:a USER ...
Break:
-->SERVERs A
-->NICK a
-->:a USER ...
--> :a QUIT
--> SQUIT serversA
A connects to part B2, note that 'part B1 --> part B2' is lagged and the
"SERVERs A ... etc" didn't arrive yet on partB2.
Servers: Part B1 Part B2 Part A
Nicks: b(B) b(B) a(A)
-->SERVERs A
-->NICK a
-->:a USER ...
--> :a QUIT
--> SQUIT serversA
--> SERVERs B
--> NICK b
--> :b USER ...
<-- SERVERs A
<-- NICK a
<-- :a USER ...
Result *before* the lagged messages arive on Part B2:
Nicks: b(B) b(B),a(A) b(B),a(A)
-->SERVERs A
-->NICK a
-->:a USER ...
-->:a QUIT
-->SQUIT serversA
And when the lagged messages arrive on Part B2, the
'SERVERs A' get all ignored: "server exists", even more, Part B2 disconnects
Part B1... :/. Now we are going to deal with the "server exists" problem
*once* (attaching a timestamp to SERVER I think), in which case 'SERVERs A'
would only be ignored by Part B2. Then the 'NICK a' would cause a nick
collision with 1) Same user@host.name, 2) same server A, and 3) same
nick-TS ! This means: We need to ignore 'NICK nick' when is has the same
TimeStamp and the same user@host. But when the user@host differ, two people
signed on at exactly the same time with the same nick and we must kill
*both* to avoid a desync.
----
How to handle a nick collision, general
---------------------------------------
Up till now when a nick collision occurs, both nicks (when a nick change
from 'old' to 'new' is involved) are KILLed in ALL directions.. wiped off the
net thus.
But even with wiping off the net in mind, it doesn't make sense to kill in
old direction, it is sufficient to deal with "our side" of the net, because
every nick collision occurs on two servers, both can deal with their side.
As an example:
Servers: A B
Nicks: a(A) a(B)
Reconnection:
<-- NICK a
NICK a -->
As you see, if A receives the 'NICK a' from B, it only has to deal with
its own side, because it is certain that B will receive the 'NICK a' from
A and handle it too as a nick collision (and therefore this 'NICK a' *is*
already a 'KILL' message).
Thus, when we receive a 'NICK' that gives rise to the need of purging
a nick on *our* side, we deal with it by doing:
sendto_serv_butone(cptr,":%s KILL ...
which sends the KILL to all server connections except the link 'cptr' that
generated the nick collision.
Also then we have to destroy the memory usage of the killed client on our
own server, and disconnect him if it is ours, so we call exit_client().
Summary so far
--------------
Ok, we discussed when to kill who. Resulting rules are:
We receive a "NICK new" or ":old NICK new" from a server direction, and
we already have a registered 'new'. Then we have a nick collison and deal
with it as follows:
1) If the user@host differ,
and our 'new' is younger or equal, KILL our 'new'.
and our 'new' is older, ignore the 'NICK new', but kill 'old' on
our side if it was a nick change.
2) If user@host is the same:
and our 'new' is older, KILL our 'new'.
and our 'new' is younger, ignore the 'NICK new', but kill
'old' on our side if it was a nick change.
and our 'new' is equal, KILL our 'new',
and kill 'old' on our side too if it was a nick change.
Remarks:
The last case, where have a ':old NICK new' collission with
the same user@host and TimeStamp, can't be case C), but it
is possible that *we* did send a 'NICK new', and the server at
the other side kills 'old' off... So we have to do it too.
With this protocol we *ignore* 'NICK new' message, but of course
in most cases they will be followed by at least a ':new USER ...' and
probably
more like ':new JOIN #...'. This would cause 'Fake direction' errors and
the current protocol KILLs such a nick in *ALL* direction (???). Now, we
DON'T want to KILL the nick in the right direction do we? And killing the
fake direction nick makes no sense: it will be killed automatically due to
the fact we did send a 'NICK new' in that direction. Thus: we can/have to
remove the Fake Direction kills.
Of course, when we receive a 'NICK new hopcount :TimeStamp', we
*can't* compare with the user@host, because it takes some time before we
will receive the 'USER'... We also can't store the nick, because it must
be unique. To solve this, we need to change the protocol so that 'NICK new'
contains all information and the USER message will be redundant and removed
in a later patch. This also reduces net.bursts.
Attaching a TimeStamp (TS) to nicks
-----------------------------------
Whenever someone takes a new nick, which is available of course, either by
changing nick or by signing on, the local server attaches a TimeStamp (TS)
to the nick. Now there will be sent:
NICK new hopcount TS user host.name server.name :Real name
or
:old NICK new :TS
This is 100% compatible with the existing protocol.
When a server receives such a nick from a neighbouring server it copies the
TS, keeping track of the local change time. (When not all servers have
upgraded, and no TS is received, the .anc server will fill in the time
itself - being a slight advantage over keeping it 0. It also will assume
that the host.names are equal or not equal resulting a as many kills as
needed in the worst case).
Examples
--------
Servers: A B
Nicks: a(A),b(B) b(B),a(A)
Both change simultaneously to nick 'c', but 'a' slightly faster (at time=1,
and b at time=2):
c(A),b(B) c(B),a(A)
-> :a NICK c :1
:b NICK c :2 <-
Then A receives a ':b NICK c :2' where 2 > 1, and KILLs b on its own side.
B however receives ':a NICK c :1' where 1 < 2, and KILLs c on its own side.
Result: c(A) c(A)
Due to 'lag', more :c PRIVMSG .. from B to A can follow, resulting in a
fake direction. 'A' will simply ignore them and not kill c (kills for
fake direction are nonsense anyway).
In the case that someone signs on, taking the same nick as a nick change
we have almost the same:
Servers: A B
Nicks: a(A) a(A)
'a' changes simultaneously to nick 'c', but slightly faster (at time=1),
as a new 'c' signs on at B (time=2).
c(A) a(A),c(B)
-> :a NICK c :1
NICK c 1 :2 <-
Then A receives a 'NICK c 1 :2' where 2 > 1, and ignores it simply.
B however receives ':a NICK c :1' where 1 < 2, and KILLs c on its own side.
Result: c(A) c(A)
If the new 'c' was a little bit earlier, we get:
Servers: A B
Nicks: a(A) a(A)
'a' changes simultaneously to nick 'c', and slightly slower (at time=2),
as a new 'c' signs on at B (time=1).
c(A) a(A),c(B)
-> :a NICK c :2
NICK c 1 :1 <-
Then A receives a 'NICK c 1 :1' where 1 < 2, and KILLs c on its own side.
B however receives ':a NICK c :2' where 2 > 1, and KILLs a on its own side.
Result: c(B) c(B)
Last case, two people sign on (or during a net reconnection):
Server: A B
Sign on: c(A) c(B)
-> NICK c 1 :1
NICK c 1 :2 <-
Then A receives 'NICK c 1 :2' where 2 > 1, and ignores it.
and B receives a 'NICK c 1 :1' where 1 < 2, and KILLs c on its own side.
Result: c(A) c(A)
Note: the above didn't take equal TS's into account, and I assumed
user@hosts to be different: the nick collision bot cases.
A last possibility when someone starts hacking... a 'NICK new' twice
from the same direction, should not be accepted: we kill the earlier one
always.
Compatibility problems
----------------------
In the future, we want to also take 'user@host' into account... Therefor,
we need to start to ignore 'NICK new' and only act upon ':new USER ...'.
We can only do that if also 'USER contains the hopcount and TimeStamp'...
If we change the protocol immedeately to say:
:nick USER user host.name server.name hopcount TimeStamp :Real name
the 'hopcount' would be treated as realname, and we the rest would be
lost :(
We can also transfer the info to 'NICK', with:
:server.name NICK nick hopcount user host.name TimeStamp :Real name
and later forget the USER message. Although someone lamer uses
the C source line " if (sptr == cptr) ..." in m_nick() to determine if
it was a 'NICK new' or a ':old NICK new' :/ Geesh (unlogical). He should
have used " if (IsServer(sptr)) ...". You would need three upgrade steps
or we will have to do with:
NICK nick hopcount user host.name server.name TimeStamp :Real name
The nice thing about this is, that we can check how many parameters we
receive and then immedeately use the user@host if it is there... That way
the .acn will immedeately work once everyone upgraded once, and the second
step would only get rid of the 'USER' line between servers.
Run
=============================================================================
WALLOPS
=============================================================================
Usage: /WALLOPS <message>
Sends a message to IRC ops on-line. Remember that users who are /umode +w
can see wallops as well.
=============================================================================
STATS W
=============================================================================
Author: Michael Vanloon (michaelv@iastate.edu) - mlv on IRC
Help on /stats w :
I've been working on something I think would be quite a useful
addition to the ircd. It keeps track of the average number of local
clients, total clients, and total connections (including servers) over
various periods of time, currently over the last minute, hour, day and
week. It is invoked by "/stats w server.name". You may try it
yourself by "/stats w *.iastate.edu". A sample from
ircserver.iastate.edu looks like this:
*** Minute Hour Day Week Userload for:
*** 44.91 39.4 33 33 iastate.edu clients
*** 114.40 103.2 69 65 total clients
*** 120.40 109.0 73 70 total connections
*** * End of /STATS report
I'm debating changing it to show average connections over the last
minute, hour, day, prev. day, and prev. day, as I think the data
doesn't change enough after that to really be useful to justify
keeping it over an entire week.
On smaller, less used servers, it should add a negligible amount to
the resident memory consumed by the ircd. On a large hub such as the
*.bu.edu servers, penfold, or ircserver.iastate.edu, it might add as
much as 300k to the amount of memory the ircd attempts to keep
resident. The amount is determined solely by the number of
connects/disconnects the server processes over the span of time
measured.
The code is bulletproof and has undergone *extensive* debugging and
testing before I announced it here.
The reason I'm posting this is because I would like to know how many
people think this would be a useful addition to the server. In
addition, I'd like feedback on whether you think this should be a
standard part of the distributed server code. I think it should, but
Avalon wants me to post here first and see how others feel about it.
I'd appreciate your input.
I will be making a patched 2.7.2 server available with this included,
for those who would like to have this and stability too. I'll also be
hooking it into 2.8.x soon, and giving it back to Av to include in the
standard 2.8 distribution as it matures, if he sees fit to do so.
Thanks for your time...
--Michael (mlv)
IRC log started Wed Aug 18 21:52
*** Value of LOG set to ON
*mlv* it's the usage of your server
*mlv* average number of users on your server over the last minute, hour, day, yesterday, and the day before
*mlv* local clients, total clients, and total connections (clients + servers)
-ircserver.iastate.edu- Minute Hour Day Yest. YYest. Userload for:
-ircserver.iastate.edu- 23.00 23.0 16 17 11 iastate.edu clients
-ircserver.iastate.edu- 52.00 52.8 37 35 23 total clients
-ircserver.iastate.edu- 61.00 61.7 45 42 21 total connections
-> *mlv* hmm...so iastate had 23 local clients in the last minute?
*mlv* right... in the last minute the average number of local users on our server was 23
*mlv* 23.45 actually
-> *mlv* okie...gotcha... thanks :) one other thing
*mlv* there were an average of 23.1 local users on here over the last hour
*mlv* shoot
-> *mlv* is it possible to specify multiple domains?
-> *mlv* for e.g. uoknor.edu and okstate.edu cos those will be local to midway
*mlv* it could be coded in, but 1) my code doesn't support it out of the box, and 2) that would add more state info which would increase the memory usage a bit
-> *mlv* hmm...
*mlv* it's purely informational... i wouldn't worry about it, really that much
-> *mlv* okay...also, the Makefile on the ftp site seems hosed.....there's junk at the end...I tried both the .Z and the .gz
*mlv* i'm thinking about making it log by connection class... but i'll have to use a more efficient statistical algorithm (less precise) if i do that
*mlv* that way you could put all the local domains into certain classes
*mlv* oh yeah... it's harmless, just weird
-> *mlv* that'll work :)
-> *mlv* well...thanks for your help....will have a look at the stats w patch when you're finished with it :)
IRC Log ended *** Wed Aug 18 22:22
=============================================================================
BAN/TOPIC/SIGNON INFO
=============================================================================
Author: Paul Foley (pfoley@kauri.vuw.ac.nz) SIO on IRC
Help on Ban/Topic/Signon :
Since these patches allow the server to maintain additional information, the
server replies have been changes for the /mode #channel +b (#367), /whois
(#317) and an additional reply #333 has been added for topic info. The time
is returned as a long integer in UTC format in all cases. Since the existing
clients will ignore this additional information, you will need to either
patch the client, or in case you're using ircII, use the foll. /on statements
to take benefit of these patches :
on ^367 * if ([$4] != []) {echo *** $1 \($3 - $stime($4)) $2} {echo *** $1-}
on ^333 * echo *** Topic for $1 set by $2 on $stime($3)
on ^317 * if (index(012345679 $3) != -1) {echo *** $1 has been idle for $2 seconds. Signon at $stime($3)} {echo *** $1 has been idle for $2 seconds.}
Once you have done this, you can see info as follows:
/mode #wasteland +b
*** #wasteland (Mmmm - Thu Aug 19 04:44:24 1993) test!*@*
/topic #wasteland
*** Topic for #wasteland: We all love Axl Rose!
*** Topic for #wasteland set by rbarnes on Thu Aug 19 04:26:56 1993
/whois Mmmm
*** Mmmm is mandar@essex.ecn.uoknor.edu (Mmmm,I get high with a little help
+from my friends)
*** on channels: @#wasteland
*** on irc via server essex.ecn.uoknor.edu (MIDWEST HUB..HELPS YOU GET THERE
+SOONER)
*** Mmmm is an IRC Operator
*** Mmmm has been idle for 454 seconds. Signon at Wed Aug 18 23:47:19 1993
=============================================================================
CLIENT NOTIFY
=============================================================================
Authors: Patrick Ashmore (pda@engr.engr.uark.edu) - Twilight1 on IRC
Mandar Mirashi (mmmirash@mailhost.ecn.uoknor.edu) - Mmmm on IRC
Tony Vencill (vencill@iastate.edu) - Tony/Tonto on IRC
Help on Client Notify:
This patch allows all opers on your server to see clients connecting to your
server and disconnecting from it (with the reason why they disconnected).
This can help you identify troublesome clients, or redirect remote clients
to closer servers, or troubleshoot the reason why a client disconnected.
A sample output:
*** Notice -- Client connecting : Karll (agifford@sci.dixie.edu).
*** Notice -- Client exiting : Karll (agifford@sci.dixie.edu) [Bad link?].
PS: if you wish to selectively decide when you wish to see these connection
notices, use the foll. script
on ^server_notice "% % NOTICE -- CLIENT*" if (hideit != 1) {echo *** $2-}
alias show @ hideit = 0;echo *** You can now see clients connecting/exiting
alias hide @ hideit = 1;echo *** You will no longer see clients connecting/exiting
If you then wish to not see client connects/exits when you are opered, simply
type /hide. If you wish to see them again, type /show.
=============================================================================
TRACE TIMES
=============================================================================
Author: Tony Vencill (vencill@iastate.edu) - Tony/Tonto on IRC
Help on Trace Time:
This useful patch lets you identify the times since your server last
heard from any connected servers or clients. This time is displayed in
seconds, appended to each line of your /trace output. It can be very
helpful in identifying which servers are going to drop off or which
clients may ping timeout from your server.
A sample output:
/trace essex*
*** Serv [30] ==> 10S 8C cancun.caltech.edu *!*@essex.ecn.uoknor.edu 73
*** Serv [30] ==> 9S 6C imageek.york.cuny.edu *!*@essex.ecn.uoknor.edu 27
*** Serv [0] ==> 1S 0C inga1.acc.stolaf.edu[130.71.192.16]
+*!*@essex.ecn.uoknor.edu 58
*** Serv [0] ==> 1S 0C shadow.acc.iit.edu *!*@essex.ecn.uoknor.edu 97
*** Serv [0] ==> 1S 2C curie.ualr.edu Mmmm!mmmirash@essex.ecn.uoknor.edu 98
*** Serv [0] ==> 1S 1C piaget.phys.ksu.edu *!*@essex.ecn.uoknor.edu 117
*** Oper [0] ==> Mmmm[essex.ecn.uoknor.edu] 0
*** Serv [50] ==> 1S 0C pv1629.vincent.iastate.edu *!*@essex.ecn.uoknor.edu 7
*** Class 0 Entries linked: 6
*** Class 50 Entries linked: 1
*** Class 30 Entries linked: 2
=============================================================================
K- line comments
=============================================================================
Author: Mandar Mirashi (mmmirash@mailhost.ecn.uoknor.edu) - Mmmm on IRC
This extremely useful patch allows you to specify either a comment or an
interval in the 2nd field of the K line (instead of the previous format
of just a restricted interval). The "comment" can even be configured to
be a *file* name which can then be displayed to the client rejected via
the K line. All existing K lines will work as they are. This patch is
an *enhancement* to the K-lines.
e.g. (of a comment field)
K:*.sdsu.edu:Flooding.is.not.cool.lamer:masc0482
As far as possible, do not use a white space in the comment field, because
this breaks ircII's /stats k handling. You can use the period (.) or the
underscore instead (_).
e.g (of a file to be output to a rejected client
- #define COMMENT_IS_FILE in config.h)
K:*.netcom.com:/ecn/staff0/irc/servers/vinson/sorry.txt:*
=============================================================================
OPER FAIL
=============================================================================
Authors: Michael Vanloon (michaelv@iastate.edu) - mlv on IRC
Jon C Green (jcgreen@iastate.edu) - Jon2 on IRC
Bryan Collins (b@ctpm.org) - bwy on IRC
This patch notifies you if someone tries to gain oper on your server and
fails. The notice goes out only to the operators on the server.
*** Notice -- Failed OPER attempt by M (mmmirash@lincoln.ecn.uoknor.edu)
[crackit]
=============================================================================
MIXED CASE
=============================================================================
Authors: Michael Vanloon (michaelv@iastate.edu) - mlv on IRC
Jon C Green (jcgreen@iastate.edu) - Jon2 on IRC
"Here's a patch mlv and I wrote that prevents clients with mixed-case usernames
from connecting. I don't know of many sites that allow mixed-case, so it
is effective for stopping many clonebot attacks and also stops many
would-be username hackers." - Jon2
This has been slightly modified by Mmmm to give an option of ignoring the
case of the first character if desired (useful for those PC users who
intuitevely enter their first name with the first letter capitalised).
e.g.
*** Notice -- Invalid username: buankBOT[saucer.cc.umr.edu]
=============================================================================
NOTE
=============================================================================
Usage:
�NOTE� USER [&passwd] [+-flags] [+-maxtime] <nick!username@host> <msg>
- or SEND|SPY|FIND|WAITFOR|NEWS <same as USER args.>
* or SEND|SPY|FIND|WAITFOR|WALL|WALLOPS|DENY|NEWS|KEY <see USER args.>
�NOTE� LS|COUNT|RM|LOG [&pwd][+-flags][#ID] <nick!user@host> [date]
�NOTE� FLAG [&passwd] [+-flags] [#ID] <nick!username@host> <+-flags>
* �NOTE� SENT [NAME|COUNT|USERS] <f.nick!f.name@host> <date> [RM]
- �NOTE� STATS [MSM|MSW|MUM|MUW|MST|MSF|USED]
- �NOTE� SENT [NAME|COUNT]
* �NOTE� STATS [MSM|MSW|MUM|MUW|MST|MSF|USED|RESET] [value]
* �NOTE� SAVE
The Note system have two main functions:
1. Let you send one line messages to irc users which
they will get when they next sign on to irc.
Example: NOTE SEND <nick> Hi, this is a note to you.
2. Let you spy on people, to see when they sign on or off,
change nick name or join channels.
Example: NOTE SPY +100 <nick> (spy on nick for 100 days)
You may fill in none or any of the arguments listed above, including
* or ? at any place, as nick@*.edu, !username, ni?k!username etc...
Other usefull features may be NOTE WAIT <nick>, making nick and
you get a message when you both are on at the same time.
Note was developed 1990 by jarle@stud.cs.uit.no (Wizible on IRC).
*Usage: NOTE [<server>] ANTIWALL
* Switch off b flag for wall's which you have received on specified
* server. The person who queued the wall would be notified about
* the antiwall, and who requested this.
Usage: NOTE COUNT [&<passwd>] [+|-flags] [#<ID>] <nick!username@host>
Displays the number of messages sent from your nick and username. See
HELP LS for more info. See HELP FLAG for more info about flag setting.
*Usage: NOTE DENY [&<passwd>] [+|-<flags>] [+|-<maxtime>]
* <nick!user@host> <msg>
* DENY is an alias for USER +RZ (default max 1 day)
* This command makes it impossible for any matching recipient to
* queue any Note requests until timeout.
Usage: NOTE FIND [&<passwd>] [+|-<flags>] [+|-<maxtime>]
<nick!username@host> <msg>
FIND is an alias for USER +FLR (default max 1 day)
This command makes the server search for any matching recipient, and
send a note message back if this is found. If <msg> field is used, this
should specify the realname of the person to be searched for. Examples:
FIND -4 foo*!username@host
FIND @host Internet*
FIND nicky Annie*
FIND +7 * Annie*
Usage: NOTE FLAG [&<passwd>] [+|-<flags>] [#<ID>]
<nick!username@host> <+|-flags>
You can add or delete as many flags as you wish with +/-<flag>.
+ switch the flag on, and - switch it off. Example: -S+RL
Following flags with its default set specified first are available:
-S > News flag for subscribing.
-M > Request is removed after you sign off.
-Q > Ignore request if recipient's first nick is equal to username.
-I > Ignore request if recipient is not on same server as request.
-W > Ignore request if recipient is not an operator.
-Y > Ignore request if sender is not on IRC.
-N > Let server send a note to you if message is delivered.
-D > Same as N, except you only get a message (no queued note to you).
-R > Repeat processing the request until timeout.
-F > Let server send note info for matching recipient(s). Any message
part specify what to match with the realname of the recipient.
-L > Same as F, except you only get a message (no queued note to you).
-C > Make sender's nicks be valid in all cases username@host is valid.
-V > Make sender's "nick*" be valid in all cases username@host is valid.
-X > Let server display if recipient signs on/off IRC or change
nickname. Any message specified is returned to sender.
-A > Show what server matching user is on using X flag.
-J > Show what channel matching user is on using X flag.
-U > Do not display nick-change using X flag.
-E > Ignore request if nick, name and host matches the message text
starting with any number of this format: 'nick!name@host nick!... '
* -B > Send a message to every account who match the nick!user@host
* This creates a received list with flag H set. (see LS +h)
* -T > Send a message not all nicks on same accounts too using B flag.
* -K > Give keys to unlock privileged flags by setting that flags on.
* The recipient does also get privileges to queue unlimited
* numer of requests, list privileged flags and see all stats.
* -Z > Make it impossible for recipient to queue anything at all.
Other flags which are only displayed but can't be set by user:
-O > Request is queued by an operator.
-G > Notice message is generated by server.
- -B > Broadcasting message.
* -H > Flag list for who's received Broadcast message (B flag).
- Notice: Message is not sent to recipient using F, L, R or X flag.
- Using this flags, no message needs to be specified.
* Notice: Message is not sent to recip. using F, L, R, X, K, Z or H
* flag (except if B flag is set for R). For this flags, no msg. needed.
Examples:
FLAG * +cj : Switch on c and j flag for all requests.
FLAG +x * +c : Switch on c flag for all req. which have x flag.
FLAG nick -c+j : Switch off c flag and which on j flag for nick
*Usage: NOTE KEY [&<passwd>] [+|-<flags>] [+|-<maxtime>] <nick!user@host>
* KEY is an alias for USER +KR (default max 1 day)
* This command is for allowing no-opers to use oper-options by specifying
* the flag to unlock. Be careful with this option!
* Example: KEY +365 +s * would make it possible for everybody to use s flag.
Usage: NOTE LOG [&<passwd>] [+|-<flags>] [#<ID>] <nick!username@host>
Displays how long time since matching person was on IRC. This works
only after use of NOTE SPY. The log is protected to be seen for other
users than the person who queued the SPY request. To get short
output, do not specify any arguments. Example:
LOG : Print short log of all
LOG * : Print long log including real names of all
LOG nick : Print long log for user nick.
Usage: NOTE LS [&<passwd>] [+|-<flags>] [#<ID>]
<nick!username@host> [<date>]
Displays requests you have queued. No arguments would show you
all requests without the message field.
Use flags for matching all messages which have the specified flags set
on or off. See HELP NOTE FLAG for more info about flag settings. Time
can be specified on the form day.month.year or only day, or day/month,
and separated with one of the three '.,/' characters. You can also
specify -n for n days ago. Examples: 1.jan-90, 1/1.90, 3, 3/5, 3.may.
If only '-' and no number is specified max time is set to all days.
The time specified is always the local time on your system. Example:
LS !user would show you all requests to username@*
LS +x would show all your SPY requests.
LS #300 would show you only request #300.
Usage: NOTE NEWS [&<passwd>] [+|-<flags>] [+|-<maxtime>]
<group!username@host>
NEWS with no message is an alias for USER +RS (default max 60 days)
This command is for subscribing on a specified newsgroup from any
user(s) or host(s). Wildcards may be used anywhere. Example:
NEWS irc.note : Subscribe on irc.note
* NEWS irc.note@*.no : Send to group irc.note, but only for
* users at host *.no
* NEWS irc.note : Send to all for group irc.note
* NEWS Users@*.edu Hi : Send Hi to all users using note in your
* server located at host *.edu.
(Advanced users may use User +rs <...> <filter> where filter is a
string which must matches with field in received news message)
- Only opers can send news as default.
* To send news add message and use same format as subscribing, except
* that username field must matches with subscribed group as alt.irc!*.irc -
* everybody subscribing on a*.irc or *.irc or alt.irc... would get the news.
* A speciall case is the group Users which everybody using note in the server
* are member of.
Usage: NOTE RM [&<passwd>] [+|-<flags>] [#<ID>] <nick!username@host>
Deletes any messages sent from your nick and username which matches
with nick and username@host. Use flags for matching all messages which
have the specified flags set on or off. See HELP FLAG for more info
about flag settings, and HELP LS for info about time.
*Usage: NOTE SAVE
* SAVE saves all messages with the save flag set. Notice that the
* messages are automatically saved (see HELP STATS). Each time server is
* restarted, the save file is read and messages are restored. If no users
* are connected to this server when saving, the ID number for each
* message is renumbered.
Usage: NOTE SEND [&<passwd>] [+|-<flags>] [+|-<maxtime>]
<nick!username@host> <msg>
SEND is an alias for USER +D (default max 60 days)
This command is for sending a message to recipient, and let the server
send a note + a notice to sender if this is on IRC - if message is sent.
SEND foobar Hello, this is a test.
SEND +7 !username@*.edu Hello again!
-Usage: NOTE SENT [NAME|COUNT]
*Usage: NOTE SENT [NAME|COUNT|USERS] <f.nick!f.name@host> <date> [RM]
Displays host and time for messages which are queued without specifying
any password. If no option is specified SENT displays host/time for
messages sent from your nick and username.
NAME displays host/time for messages sent from your username
COUNT displays number of messages sent from your username
* USERS Displays the number of messages in [], and names for all users
* who have queued any message which matches with spec. nick/name/host.
* RM means that the server removes the messages from the specified user.
*Usage: NOTE SERVICE <nick> <note command>
* Useful in robots. Note will take the requests as if from <nick>
Usage: NOTE SPY [&<passwd>] [+|-<flags>] [+|-<maxtime>]
<nick!username@host> [msg]
SPY is an alias for USER +RX (default 1 max day)
SPY makes the server tell you if any matching recipient sign(s)
on/off IRC or change nick name. No message needs to be specified.
However, if a message is specified this is returned to sender including
with the message about recipient. Message could for example be one or
more Ctrl-G characters to activate the bell on senders machine.
As an alternative for using C flag, <msg> field could start with
any number of nicks on this format: %nick1 %nick2... %nickn, with
no space between % and the nick name you use. Spy messages would be
valid for any of the nicks specified.
SPY with no argument would tell you what users you have spy on who are
currently on IRC. The system logs last time the last matching person was
on IRC for each SPY request is queued in the server. See NOTE LOG for this.
You may use flag +A to see what server matching user is on,
and/or +J flag to see what channel. (Read HELP NOTE USER for more). Example:
SPY foobar!username@host <ctrl-G>
SPY +10 foobar
SPY +aj &secret * <ctrl-G>
SPY +365 +e !user nick!*@* <ctrl-G>
SPY % +7 foo!user
SPY +5 nicky %mynick %meenick
-Usage: NOTE STATS [MSM|MSW|MUM|MUW|MST|MSF|USED]
*Usage: NOTE STATS [MSM|MSW|MUM|MUW|MST|MSF|USED|RESET] [value]
STATS with no option displays the values of the following variables:
MSM: Max number of server messages.
MSW: Max number of server messages with username-wildcards.
MUM: Max number of user messages.
MUW: Max number of user messages with username-wildcards.
MST: Max server time.
MSF: Note save frequency (checks for save only when an user register)
Notice that 'dynamic' mark after MSM means that if there are more
messages in the server than MSM, the current number of messages are
displayed instead of MSM.
Only one of this variables are displayed if specified.
* You can change any of the stats by specifying new value after it.
* RESET sets the stats to the same values which is set when starting the
* server daemon if no note file exist. Notice that this stats are saved
* in same file as the other messages.
Usage: NOTE USER [&<passwd>] [+|-<flags>] [+|-<maxtime>]
<nick!username@host> <msg>
With USER you can queue a message in the server, and when the recipient
signs on/off IRC, change nick or join any channel, note checks for
valid messages. This works even if the sender is not on IRC. See HELP
FLAGS for more info.
Password can be up to ten characters long. You may specify password
using the &, % or $ character. & is equal to to $, except working much
better cause client use $ for other things...
The % character works like &, except it makes the queuing silent. It
makess also sense to use this without any following password.
If any request queued is equal to any previous except time and maxtime,
only maxtime is changed as specified. You then get "Joined" instead of
"Queued".
HELP FLAGS for info about flag settings. Username can be specified
without @host. Do not use wildcards in username if you know what it
is, even if it's possible. Max time before the server automatically
remove the message from the queue, is specified with hours with a
'-' character first, or days if a '+' character is specified, as
-5 hours, or +10 days. Default maxtime is 7 days.
Note: The received message is *directly* displayed on the screen,
without the need for a read or remove request.
NOTE USER &secret +WN +10 Wizible!jarlek@ifi.uio.no Howdy!
is an example of a message sent only to the specified recipient if
this person is an operator, and after receiving the message, the server
sends a note message back to sender to inform about the delivery.
NOTE USER +XR -5 Anybody <ctrl-G>
is an example which makes the server to tell when Anybody signs
on/off irc, change nick etc. This process repeats for 5 hours.
NOTE USER +FL @*.edu *account*
is an example which makes the server send a message back if any real-
name of any user matches *account*. Message is sent back as note from
server, or directly as a notice if sender is on IRC at this time.
Usage: NOTE WAITFOR [&<pwd>] [+|-<flags>] [+|-<maxtime>]
<nick!username@host> [<msg>]
WAITFOR is an alias for USER +YD (default max 1 day)
Default message is [Waiting]
This command is for telling the recipient if this appears on IRC that
you are waiting for him/her and notice that this got that message. Example:
WAITFOR foobar
WAITFOR -2 foobar!username@*
WAITFOR foobar Waiting for you until pm3:00..
*Usage: NOTE WALL [&<passwd>] [+|-<flags>] [+|-<maxtime>]
* <nick!user@host> <msg>
* WALL is an alias for USER +BR (default max 1 day)
* This command is for sending a message once to every matching user
* on IRC. Be careful using this command. WALL creates a list of
* persons received the message (and should not have it once more time)
* with H flag set. This list can be displayed using ls +h from the
* nick and username@host which the WALL request is queued from.
* Removing the headers (H) before WALL request is removed would cause
* the message to be sent once more to what users specified in list.
* WALL +7 @*.edu Do not do this! - Makes it clear for all users using
* IRC on host @*.edu the next 7 days how stupid it is to send such WALL's ;)
*Usage: NOTE WALLOPS [&<passwd>] [+|-<flags>] [+|-<maxtime>]
* <nick!user@host> <msg>
* WALLOPS is an alias for USER +BRW (default max 1 day)
* This command is same as WALL, except only opers could receive it.
=============================================================================
