Page 1 of 2

Unreal 3.2-RC2 Released

Posted: Sun Mar 07, 2004 7:37 pm
by codemastr
Today, Unreal3.2-RC2 was released. This release is primarily to fix the problems that were discovered in RC1. Fixes include numerous changes to the remote include system, spamfilter fixes, etc. Also, a couple new changes were made to the spamfilter system to make it more useful along with a spamfilter.conf that contains signatures for some common exploits/trojans/worms that appear on IRC. If you are running RC1 or older, it is definately suggested that you upgrade!

Code: Select all

Unreal3.2-RC2 Release Notes
============================

==[ GENERAL INFORMATION ]==
* This is the second (and hopefully last) Release Candidate.
  After this we intend to release 3.2 final.
* If you are upgrading, make sure you run ./Config and make clean 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/
* This is a recommended release because various crashbugs have been fixed.

== [NEW FEATURES (see unreal32docs.html for more information) ]==
* Lots of spamfilter improvements.
  * 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 translated 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/[linewrap]
        nicepage/virus=blah Come watch me on my webcam
  * The spamfilter { } blocks also have a new 'reason' and 'ban-time' field.
  * The user will now receive a notice 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).
      After this all commands for the user are disabled except: PONG, ADMIN
      and NOTICE/PRIVMSG's to the virus-help-channel.
      Also any ops (+oaq) in the virus help channel will receive a notice
      explaining which filter the user matched (so they can help the user out).
  * Added set::spamfilter::except which allows you to specify targets where
    spamfilter should not take action. Useful for spam-report/help chans.
    Ex: set { spamfilter { except "#spamreport,#help"; }; };
  * there's now a 'spamfilter.conf' file with some effective spamfilter rules.
* Added '/tempshun' command (/tempshun nick reason, /tempshun -nick).

==[ MAJOR BUGS FIXED ]==
* The ircd was unable to boot on some OSs because unreal removed tmp/
* crash: if an invalid regex was entered (eg: in spamfilter) the ircd could crash
* crash: The TRE regex library could be crashed in case of some (advanced) regexes.
* crash: several remote includes problems (also non-crash)
* crash/security: an user-triggerable crash bug
* Fixed problem with 'tkl update' which could lead to server fights in some cases.

==[ MINOR BUGS FIXED ]==
* allow::options::noident now actually works
* Fixed compile problem on Solaris
* Some OperOverride + ExtModes fixes (eg: globop w/can_override couldn't set +T)
* +qaohv'ing a network service was disallowed
* chanmode +f was often reset on synch when it was already the same at both sides
* Spamfilter single-target are now supported, eg:
  spamfilter { regex "blah"; action kill; target private; };
  previously the ircd didn't warn about this (but it didn't work).

==[ CHANGED ]==
* Updated /credits. Now includes everyone who has sent in donations,
  thanks to everyone!
* Various help.conf/docs updates as usual
* New hooks for module coders and other module system improvements.
* Modulized A LOT of commands (34): this allows better "hot patching"
  and leaving out commands (eg: loading all m_*.so mods except m_addline.so).
* Moved SQLINE system (and ban nick) to TKL and introduced "holds",
  this might later be used by services for nick enforcement.
* Restricted class::pingfreq to 30-600.. anything higher and you might get
  mysterious (mass) disconnect issues... Anything lower is dumb too.
* Added checking for insane listen port ranges (eg 6667-7000).
* Improved DCC blocking (like dcc to channels)
* Made some numerics more clear by including the channelname (+V/+O/+A)

Posted: Mon Mar 08, 2004 7:36 am
by Ron2K
codemastr hasn't posted anything about this here yet, so I'll draw everyone's attention to the fact that 3.2-RC2 had a major bug in it, so 3.2-RC2fix has now been released to correct this.

If you have RC2 and don't know whether you need to upgrade or not, check this out:
codemastr on the UnrealIRCd homepage wrote:If in /version you see 'Unreal3.2-RC2' then you must upgrade. If you see 'Unreal3.2-RC2fix' then you are fine. All of the downloads on the website have been updated with the fixed version. Additionally, for *nix users, you can simply apply the Patch available at http://www.unrealircd.com/32rc2fix.patch and recompile. We appologize for the inconvenience.

how install patch

Posted: Wed Mar 10, 2004 12:36 am
by counselor
All i get when i click on the link for the fix is a text file if you will, How do i install this into my unreal3.2 dir

Posted: Wed Mar 10, 2004 12:38 am
by codemastr
It's a patch file, and it only works if you downloaded 3.2rc2.

download the file, then
patch < 32rc2fix.patch

then run make

Posted: Thu Mar 11, 2004 3:43 am
by wut4
patch < 32rc2fix.patch

(Stripping trailing CRs from patch.)
can't find file to patch at input line 217
Perhaps you should have used the -p or --strip option?
The text leading up to this was:
--------------------------
|Index: src/channel.c
|===================================================================
|RCS file: /home/cmunk/ircsystems/cvsroot/unreal/src/channel.c,v
|retrieving revision 1.1.1.1.6.1.2.315
|retrieving revision 1.1.1.1.6.1.2.316
|diff -c -r1.1.1.1.6.1.2.315 -r1.1.1.1.6.1.2.316
|*** src/channel.c 4 Mar 2004 23:06:54 -0000 1.1.1.1.6.1.2.315
|--- src/channel.c 7 Mar 2004 21:50:07 -0000 1.1.1.1.6.1.2.316
--------------------------
File to patch:
Skip this patch? [y]
Skipping patch.
1 out of 1 hunk ignored

Posted: Thu Mar 11, 2004 3:45 am
by codemastr
When it says:
File to patch:

You have to enter src/channel.c, pressing enter basically tells it not to apply the patch.

Posted: Thu Mar 11, 2004 4:00 am
by wut4
I clicked enter too soon, I haven't added patches in the past, is it necessary to type in the file at each prompt?

Posted: Thu Mar 11, 2004 4:01 am
by wut4
Thanks!

Been Using win 32 rc1

Posted: Thu Mar 11, 2004 10:23 pm
by JessieJames
iam using win32 rc1 if i download rc2 is it already patched ?

Posted: Thu Mar 11, 2004 10:37 pm
by codemastr
Yes, all the RC2's available on the website (Win and Linux) are already patched.

Thanks

Posted: Thu Mar 11, 2004 10:57 pm
by JessieJames
Guess i should read more befor i panic thanks again

Posted: Sat Apr 03, 2004 12:32 pm
by mitchellj
This may sound like a stupid question, but when does a release move from CVS to release. Is it at random points, or is it when all crash, block and feature bugs are fixed, or something else?

Thanks in advance for a stupid question answer ;D

And no i am not asking when there is gonna be a release i am just asking how a release is decided upon, so i'll answer the other question before anyone else does, "The longer you keep asking the longer it will take"

Posted: Sat Apr 03, 2004 5:17 pm
by codemastr
Usually what we try to do is first come up with an estimate about how long we think it will take. So we'll say something like "release sometime next month." But it's not a fixed date. Like say we planned to release tomorrow. Well if someone comes today, and reports a major bug, then we push back the release.

As for features though, no the features really have nothing to do with determining it. We may say we want to get a specific feature in before a release, but we never try and get them all in. If we did, we'd never make any releases! Additionally, now that we are in RC (Release Candidate) that means there will be no new features until after 3.2 final, just bug fixes. The purpose of the RC process is to fix bugs, not to create new ones.

Basically though, a release moves when we feel confident that the new version is more stable/bug free than the previous, and that most if not all of our goals for the release have been met.

Posted: Sun Apr 04, 2004 11:12 am
by mitchellj
Ahh thanks :)

That makes sense :P

So judging by the bugs, you think there will be a RC3 at the current rate or just a Final?

Posted: Sun Apr 04, 2004 12:56 pm
by AngryWolf
Your question was already answered in the .RELEASE.NOTES file and in Syzop's FAQ.