mirror of
https://github.com/unrealircd/unrealircd.git
synced 2026-07-08 04:23:13 +02:00
- Added release notes (not finished yet).
This commit is contained in:
+72
-68
@@ -1,77 +1,81 @@
|
||||
Unreal3.2.7 Release Notes
|
||||
Unreal3.2.8-cvs Release Notes
|
||||
==========================
|
||||
|
||||
[ New stuff and known issues is listed below ]
|
||||
<<FIXME>>
|
||||
|
||||
==[ GENERAL INFORMATION ]==
|
||||
- If you are upgrading on *NIX, make sure you run 'make clean' and './Config'
|
||||
first, before doing 'make'
|
||||
- The official UnrealIRCd documentation is doc/unreal32docs.html
|
||||
online version at: http://www.vulnscan.org/UnrealIRCd/unreal32docs.html
|
||||
FAQ: http://www.vulnscan.org/UnrealIRCd/faq/
|
||||
Read them before asking for help.
|
||||
- Report bugs at http://bugs.unrealircd.org/
|
||||
- When upgrading a network, we assume you are upgrading from the previous
|
||||
version (3.2.7). Upgrading from 3.2.6 or 3.2.5 should be ok as well.
|
||||
However, if you have a network running with servers that are several versions behind
|
||||
(eg: 3.2.1) then you might experience small (desynch) problems.
|
||||
Please also minimize the time you have multiple versions running, a few days or
|
||||
one week is generally not a problem, but having mixed versions on a network for several
|
||||
weeks or months is not recommended.
|
||||
- The purpose of the sections below (NEW, CHANGED, MINOR, etc) is to be a SUMMARY of
|
||||
the changes in this release. There have been XX+ changes, and trying to mention them
|
||||
all would be useless, see the Changelog for the full list of changes.
|
||||
|
||||
[ Strategy change ]
|
||||
==[ NEW ]==
|
||||
- set::level-on-join: this defines which privilegs a user receives when creating a
|
||||
channel, default is 'chanop', the only other available setting is 'none' (opless).
|
||||
- Away notification through WATCH: This allows clients to recieve a notification
|
||||
when someone goes away or comes back, along with a reason, a bit like IM's.
|
||||
There's probably no current client supporting this but it would be a nice feature
|
||||
in notify lists. Client developers: see Changes file for full protocol details.
|
||||
- Spamfilter: Slow spamfilter detection: For each spamfilter, Unreal will check,
|
||||
each time it executes, how long it takes to execute. When a certain threshold is
|
||||
reached the IRCd will warn or even remove the spamfilter. This could prevent a
|
||||
spamfilter from completely stalling the IRCd. Warning is configured through
|
||||
set::spamfilter::slowdetect-warn (default: 250ms) and automatic deletion is
|
||||
configured by set::spamfilter::slowdetect-fatal (default: 500ms).
|
||||
You can set both settings to 0 (zero) to disable slow spamfilter detection.
|
||||
This feature is currently not available on Windows.
|
||||
- SSL: set::ssl::server-cipher-list can be used to limit the allowed ciphers
|
||||
- SSL: To specify when an SSL session key should be renegotiated you can use
|
||||
set::ssl::renegotiate-bytes <bytes> and set::ssl::renegotiate-timeout <seconds>.
|
||||
- UHNAMES support: This sends the full nick!ident@host in NAMES which can be
|
||||
used by clients for their IAL. mIRC, Klient, etc support this.
|
||||
- There have also been some behavior changes, which can be considered NEW, see
|
||||
next section.
|
||||
|
||||
Unreal3.2.7 will be released on 14th July 2007 - marking 8 years since the first UnrealIRCd
|
||||
release. With this, we've decided to do a rather big change in strategy. Fact is, the Unreal3
|
||||
code base has gone stale and is not suitable to service your IRC networks for 8 more years.
|
||||
==[ CHANGED ]==
|
||||
- IPv6: On IPv6 servers you no longer have to use ::ffff:1.2.3.4 IP's for IPv4 in the
|
||||
config file, you can use the simple 1.2.3.4 form, as they are converted automatically.
|
||||
- When someone is banned and /PARTs, the part reason (comment) is no longer shown
|
||||
- ChanMode +S/+c: now strips/blocks 'reverse' as well
|
||||
- Smart banning is now disabled by default because it was too annoying, this means that
|
||||
f.e. if there's a ban on *!*@*.com then you can still add a ban on *!*@*.aol.com
|
||||
- except ban { } now also protects against ZLINEs and ban ip { }
|
||||
- Modules: user modes and channel modes without parameters (eg: +X) no longer have
|
||||
to be PERManent, this means they can be upgraded/reloaded/unloaded on-the-fly.
|
||||
|
||||
We've been working to improve this code base but run into serious issues constantly due to old
|
||||
code laying about and design decisions in the past by previous coders that has locked us into
|
||||
an IRCd that can hardly evolve.
|
||||
==[ MAJOR BUGS FIXED ]==
|
||||
- Zip links issue (Overflowed unzipbuf)
|
||||
- Crash issue with 3rd party modules that introduce new channelmodes w/parameters
|
||||
- Mac OS X: Various issues which prevented the IRCd from booting up
|
||||
- A few rare crash issues
|
||||
|
||||
In light of this, and through that people have worked on a IRCd from scratch, in C++ - InspIRCd.
|
||||
InspIRCd was made by people who initially used Unreal, but foresaw that something radical was
|
||||
needed to fix the IRCd code base so many IRCds share.
|
||||
|
||||
InspIRCd was partly inspired by Unreal and this means that it will be easier for us to move on
|
||||
to the logical step - we're forking InspIRCd (through a tight cooperation with them), to give
|
||||
you Unreal4.0. For more information on the new core, see http://www.inspircd.org - any documents
|
||||
dealing with module coding, server protocol, etc, works for Unreal4 too - as we will be
|
||||
the project that extends from bare (InspIRCd) to colourful and featureful (UnrealIRCd),
|
||||
and the goal is to be able to move modules from Unreal to InspIRCd without problems.
|
||||
|
||||
The target is for both development teams to work what's their speciality - we're dedicated
|
||||
to give our users service, implement features and maintain stability and innovate, where
|
||||
InspIRCd also has some of these qualities, but focuses more on a base IRCd that can be extended
|
||||
with new features through modularity and maintaining a stable core that just works and performs
|
||||
well.
|
||||
|
||||
The fork will not be a hostile one - the idea is to have a shared core (InspIRCd) and we work
|
||||
together on inventing and implementing new ideas that can be added through the module system,
|
||||
and we will work alone on features that InspIRCd coders may not want to touch and reverse.
|
||||
|
||||
We hope to shape InspIRCd in our image and provide an Unreal4 that feels like an Unreal3 - same
|
||||
configuration format, same quality documentation, support, etc, and in the progress give you
|
||||
users the ability to have a "modern" IRCd that can handle loads and loads of users, and still
|
||||
give you the choice to choose what features your network wants to use.
|
||||
|
||||
The Unreal3.2 branch will continue mostly as bug fixes - and adding ability to link to Unreal4,
|
||||
so we're not giving up on you people who want to keep on running Unreal3, but when this link is
|
||||
stable (in 3.2.8 - based off 3.3), and Unreal4 is as feature complete with Unreal3, we stop
|
||||
supporting Unreal3.
|
||||
|
||||
So, how will this affect you? We could need a hand. Enter the development wiki on
|
||||
http://dev.unrealircd.com/unreal4_development - aid out and find out what we're missing in
|
||||
Unreal4 to make it an IRCd you'd switch to. Test the SVN, find bugs we introduce, and we hope
|
||||
this cooperation between InspIRCd and UnrealIRCd will lead to a new age in IRCd development
|
||||
and for IRC networks in general - since we have many new ideas we can try out together.
|
||||
|
||||
Hang out in #unreal-devel on irc.unrealircd.com - we're interested in having you along. Making
|
||||
modules should be slightly easier from now on.
|
||||
|
||||
[ New stuff ]
|
||||
|
||||
- Updated c-ares to 1.4.0, TRE to 0.7.5
|
||||
- chmode +L does no longer require chmode +l
|
||||
- Oper blocks now can have CIDR, as in "userhost *@127.0.0.1/32";
|
||||
- Services coders: SVSNOLAG/SVS2NOLAG (described in Changes) will allow a user
|
||||
to avoid fake lag (ie, flood as much as he/she wants).
|
||||
- More intelligent accept() handling - that is, take in multiple times at a time instead of one
|
||||
per I/O loop
|
||||
- A lot of bug fixes, basically.
|
||||
|
||||
[ Known issues found in testing ]
|
||||
|
||||
- CHROOTDIR does not work nicely together with the new patch where you can do hardcoded
|
||||
IRC_USER / IRC_GROUP (setuid / setgid with names), due to having to look up password files.
|
||||
- Spamfilter warn does not work with /setname
|
||||
- Documentation is not complete
|
||||
- There is a problem with bans getting truncated we are still trying to investigate. Happens
|
||||
in 3.2.6 too.
|
||||
==[ MINOR BUGS FIXED ]==
|
||||
- CGI:IRC: Several IPv6 issues, both on IPv6 IRCd's and CGI:IRC gateways
|
||||
- IP masks in oper::from::userhost sometimes didn't match when they should
|
||||
- (G)ZLINE's on IPv6 users were sometimes rejected
|
||||
- CHROOTDIR works again
|
||||
- And more... see Changelog
|
||||
|
||||
==[ KNOWN ISSUES ]==
|
||||
- Regexes: Be careful with backreferences (\1, etc), certain regexes can slow the IRCd
|
||||
down considerably and even bring it to a near-halt. In the spamfilter user target it's
|
||||
usually safe though. Slow spamfilter detection can help prevent the slowdown/freeze,
|
||||
but might not work in worst-case scenario's.
|
||||
- Regexes: Possessive quantifiers such as, for example, "++" (not to be confused with "+")
|
||||
are not safe to use, they can easily freeze the IRCd.
|
||||
|
||||
==[ ADDITIONAL INFO ]==
|
||||
* See Changelog for more details
|
||||
|
||||
Reference in New Issue
Block a user