===================================================================
RCS file: /home/cmunk/ircsystems/cvsroot/unreal/Changes,v
retrieving revision 1.1.1.1.2.1.2.1.2.2414
diff -u -r1.1.1.1.2.1.2.1.2.2414 Changes
--- Changes 30 May 2007 21:10:04 -0000 1.1.1.1.2.1.2.1.2.2414
+++ Changes 4 Jun 2007 17:21:12 -0000
@@ -1726,3 +1726,5 @@
"UnrealIRCd is not running" as opposed to "kill: 3426: no such process" etc.
- #0003368 patched by Stealth giving users access to do /module on remote
servers
+- #0002677 reported by aquanight, removing listen::options::remoteadmin,
+ listen::options::mask, set::options::no-stealth
===================================================================
RCS file: /home/cmunk/ircsystems/cvsroot/unreal/Changes,v
retrieving revision 1.1.1.1.2.1.2.1.2.2394
diff -u -r1.1.1.1.2.1.2.1.2.2394 Changes
--- Changes 13 May 2007 16:48:38 -0000 1.1.1.1.2.1.2.1.2.2394
+++ Changes 13 May 2007 17:56:05 -0000
@@ -1666,3 +1666,4 @@
- A bug was introduced in the patch for #0003139. Patched by WolfSage
- #0002533 reported by Dodge_Ram, patched by WolfSage, regarding notices
not being sent when /*line and /shun are used to request stats
+- Removed class.h and minor references to aClass. Patched by WolfSage
new commands SVSNOLAG/SVS2NOLAG (syntax: SVSNOLAG [+|-] NickName). Obviously, care
should be taken when giving such access to a user since he/she will be able to flood
at full speed and could possibly take down the entire IRCd (well, everyone on it).
Suggested by avb, coded by djGrrr.
- DOMAINNAME is removed from ./Config reported by satmd (#0003063).
- THROTTLING and FAST_BADWORD_REPLACE cannot be configured in config.h reported by raymondvrolijk (#0002937).
- /sqline supports sqlining for channels. #*ble* will forbid channels and *ble* will forbid only nicks (not channels).
Forbid message showed by numeric ERR_FORBIDDENCHANNEL (448) reported by aragon and Jase (#0000935, #0003012).
- conf_deny NOTICE message is replace by ERR_FORBIDDENCHANNEL.
to document it right now, just want to get it off my cvs queue ;P.
Syntax is 'WATCH A +TestUser' to have someone with away notification on your watchlist.
error message if the kick should be denied. The upper layer (thus NOT you) takes care
of OperOverride.
- Modulized channel mode +Q (src/modules/chanmodes/chmode_upQ.c)
(unmentioned: ripped out old MODE_FLOODLIMIT stuff -- 2 lines)
As a consequence of this the last parameter you get in your hook is now 'oldnick' rather
than 'newnick'. So the new nick is in sptr->name now and oldnick in last parameter.
- Added HOOKTYPE_PRE_CHANMSG, this should now be used for blocking/morphing text.
It has the parameters: sptr, chptr, text, notice
- HOOKTYPE_CHANMSG now no longer allows one to block the text (use HOOKTYPE_PRE_CHANMSG for
that). It's also moved to after the message was actually sent.
- Added HOOKTYPE_KNOCK (sptr, chptr)
- Added HOOKTYPE_MODECHAR_FIXME. Internal for now, will be replaced with a proper
HOOKTYPE_MODECHAR later (and arguments will change). It's just an internal hack for
chmode +f for now ;).
- Updated indent.pro to use length=110. It still does not indent how I want it to be though,
so don't use it yet ;).
- Moved channel mode +f to src/modules/chanmodes/chmode_f.c, interestingly enough this took
longer than recoding extcmodes paramter support and moving chan mode +j.
It's not only looking like a complex channel mode, it actually *IS* one ;).
TODO: make sure it actually works, and fix sjoining (partly not implemented yet->crash) ;p
for everything. Recode of extcmodes partially complete (only 30% or something), using a
FAST 'slot system' now in the channel structure for paramter modes instead of linked lists.
Besides the slot system being faster, it also causes less memory fragmentation (and
memory fragmentation actually causes slower CPU as well, especially when running for a
long time). Channel modes are still permanent and all.
I'm first going to move modes to modules and then later on have a go at making them non-
permanent (already know exactly how to do it, but other things go first ;p).
Documentation on how all this works will be added later as well. It's really work-in-progress
at the moment, which means: the API might (or 'will') change.
Channel modes will be in src/modules/chanmodes, named chmode_<modechar>.c, that's the
general rule at least.. Some will be 'packed together' like the RFC modes s/n/t/k/l/etc.
Channel mode 'j' has been moved to src/modules/chanmodes/chmode_j.c which seems to work ok.
Details (aka: documentation) about which loadmodule's will be needed for which modes
(like I said, since some will be bundled in for example an 'rfc' module) will also be added
later. For now it doesn't matter much, since there's only j ;).
Side note: some +j code is still in the core (only eating 4 bytes per-user and 4 bytes
per-channel, though), and will remain there for now.
I did the work of above in 2 days, so ehm.. it's still far from complete, but I don't want
to wait for one BIG commit which changes half of the ircd :P.
Added hooks (needs to be documented, like all other hooks, one day ;p):
HOOKTYPE_CAN_JOIN: called from can_join(), seems more logical than PRE_LOCAL_JOIN, also
more nicely passes the key and link stuff.
HOOKTYPE_CAN_SEND: not implemented yet. will be called from can_send()
HOOKTYPE_CLEANUP_CLIENT: called from free_client()
HOOKTYPE_CLEANUP_USER: called from free_user()
HOOKTYPE_CLEANUP_USER2: called from exit_client when freeing a user.. I know, this
might sound redundant, but then again.. some things REQUIRE a certain order (like before
freeing membership links).. Or at least I don't want to break the current logic ;).
in a netjoin when there was no need to (nothing to synch).
- Added spamfilter::except which allows you to specify targets
(eg: channels) where spamfilter should not take action. Requested by Fury
(#0001586). Ex: set { spamfilter { except "#spamreport,#help"; }; };
- Improved 'viruschan' spamfilter target:
- better msg after the forced join
- +oaq's in set::spamfilter::virus-help-channel receive a notice about
which filter the user matched.
- it disables all commands except PONG, ADMIN, and msg/notices to
set::spamfilter::virus-help-channel.
- Made snomask +S also show the spamfilter reason field.
- Added class::pingfreq checking, should be 30-600 now.. else you might
get mysterious (mass) disconnect issues.
- Lol, I made /connect dissapear during modulizing ;).
- Fixed a few wrong macro's (ircstrdup/ircfree) in s_conf.c causing
very weird behavior... This also fixes a bug where set::spamfilter::ban-reason
would have the value of ban-time.
- Improved spamfilter again.
- The new syntax is:
/spamfilter [what] [type] [action] [tkltime] [reason] [regex]
[tkltime] specifies the duration of any *lines placed by this rule.
[reason] specifies the *line, kill and/or block reason.. no spaces
allowed, but '_' will be escaped to a space.
In both cases you can simply use '-' to skip and use the default.
Ex: /spamfilter add p block - - Come watch me on my webcam
/spamfilter add p gline 3h Please_go_to_www.viruscan.xx/
nicepage/virus=blah Come watch me on my webcam
- A message is now shown if the msg/notice/dcc is blocked.
- There are 2 new spamfilter action types:
'dccblock' will mark the user so (s)he's unable to send any files by DCC.
'viruschan' will part the user from all channels and join
set::spamfilter::virus-help-channel (default: #help).
this action might be improved to do more later.
- Internal: added EXTTKL PROTOCTL, this determinates if 10 parameters
instead of 8 are supported for m_tkl (used by spamfilter add).
This new system needs some testing... :)
spamfilter::word to spamfilter::regex to make it even more clear (since we match
on the whole line and have nothing to do with words.. 'word' doesn't make sense).
- Updated docs with some better regex examples, reported by AngryWolf (#0001520).
integration now, no.. it doesn't work at all yet but most of the internal stuff
has now been done (but I temporarely need to work on other things now).
moved/added a lot of regex stuff, banaction/spamfilter helper functions, etc
into s_misc.c. [note: current code has some bugs but since the stuff isn't
used that's no problem... it's also a bit ugly, do NOT mail me about these things ;p]
- Enabled talk-trough-+M for opers (just like +m)
- Disabled talk-trough-+m/+M for opers if NO_OPEROVERRIDE is defined
- Display zlib/SSL version in /version (oper only)... will prolly be improved later.
- updated doc/compiling_win32.txt
Instead of 1 big list of *lines, it's now an array to easily distinct between types.
Also made tk->usermask static (USERLEN+2) instead of dynamic.
These changes should give enough speed improvement to make the new anti-spam/anti-ads
feature fast enough.
These bans look like ~<type>:<stuff>. Currently the following bans are available:
~q: quiet bans (ex: ~q:*!*@blah.blah.com). People matching these bans can join
but are unable to speak, unless they have +v or higher.
~c: channel bans (ex: ~c:#idiots). People in #idiots are unable to join the channel.
~r: gecos (realname) bans (ex: ~r:*Stupid_bot_script*). If the realname of a user
matches this then (s)he is unable to join.
NOTE: an underscore ('_') matches both a space (' ') and an underscore ('_'),
so this ban would match 'Stupid bot script v1.4'.
These bantypes can also be used in the channel exception list (+e).
+e ~r:*w00t* makes anyone with 'w00t' in their realname able to join,
and +e ~c:#admin makes anyone in #admin able to join, etc..
This system allows modules to add extended bantypes too.
This feature requires some additional testing, also the module interface will
probably be changed in the next few weeks, and perhaps more extended bans will
be added before next release.. we'll see...
with the same oper block. Suggested by kain.
- Made /dns oper-only (the ircd command, not your client /dns command :p).
- Various help.conf fixes. Reported by nukie (#0001373).
this will currently produce a lot of warnings with -Wall.
- Fixed 159 of 184 warnings detected by the above, the other warnings are false.
Most warnings had to do with long vs int, and thus the format strings (%d->%ld)
or the vars (int->long) have been changed (many of these were time_t/TS vs int).
Only a few rare crashbugs were discovered.
- Module coders: for HOOKTYPE_LOCAL_CHANMODE the 'sendts' parameter was changed
from type 'int' to 'time_t', while in most circumstances (like on ia32)
you won't notice, I suggest you to update your callback functions anyway.
- Possibly fixed an issue with set::modes-on-join and mode +f, it could have
set random remove-chanmode times in the default chanmode line.
- Added 'action' field to ban version { } which can be: kill: kills the user (default),
tempshun: shun the specific connection only, kline/zline/gline/gzline/shun: place
a ban on *@IP. Time of those bans can be specified in set::ban-version-tkl-time.
It's up to the admin to take a good decision, sometimes zlines are best (=won't use
much sockets but will reconnect quite quickly), sometimes tempshun (=will use 1 socket
but generates nearly no network traffic), sometimes klines/glines, etc..
- Changed some useless stuff.
- Enabled EXTCMODE by default, I presume it's stable but can't promise anything.
- Module coders: changed 'allowed' callback function for umodes&snomasks,
from 'aClient *sptr' to 'aClient *sptr, int what'.
'what' will be MODE_ADD if trying to add and MODE_DEL if trying to remove.
- Added checks for /sethost&/chghost to same host.
- Added remove-chanmode-after-X-minutes in +f.
The format is +f [30j#R5]:15, where 5 is the "do -R after 5 minutes". For a default
action like +i you would have to do the same: +f [30j#i5]:15 (remove 'i' after 5 minutes).
Additionally, 2 config items are added:
- set::modef-default-unsettime, if this is set to for example '5' then things like
+f [30j]:15 will be transormed into +f [30j#i5]:15. It's just a default, the user can still
override it. By default this feature is not used.
- set::modef-max-unsettime, specifies the maximum amount of time for the <time> parameter,
by default this is set to 60 (=1 hour), the value should be between 0 and 255.
I didn't do the extended tests I usually do but it seems stable, also the docs are updated
but are probably updated again later to make it a bit more readable.
Feel free to report any bugs as soon as you discover them.
The only thing I could think of is: _usually_ only 1 server will have the -i/-R/.. timer
running, so if that server splits (or even worse dies) it will only be -i/-R/.. at that server
and when they sync back they merge chanmodes so +i/+R is set again.
I don't consider this a huge problem but maybe it can be inconveniently, if people have
a lot of trouble with this I'll have to consider a 50% recode of the +f system :/.
stskeeps