Hi all!
Today I released ngIRCd 21.1, a bug-fix only release for ngIRCd 21.
This release doesn't contain new features, but fixes a few "glitches" in
ngIRCd 21 that have been reported over the past few months. The NEWS file
lists the following:
• Don't ignore but use the server password when PAM is compiled in but
disabled. Thanks to Roy Sindre Norangshol <roy.sindre(a)norangshol.no>!
• doc/Platforms.txt: Update from master branch.
• doc/Services.txt: Update information for Anope 2.x.
• configure: add support for the LDFLAGS_END and LIBS_END variables to
add linker flags and libraries at the end of the configure run
(CFLAGS_END has been implemented already).
• Update Copyright notices for 2014 :-)
There are no security fixes included, nevertheless all installations
should update: ngIRCd 21.1 is fully backwards compatible and the update
should be straight forward, no configuration changes are required.
You can find the NEWS file (listing all new and changed features) and the
ChangeLog file (listing all changes in greater detail) in the distribution
archives as well as online:
• <http://ngircd.barton.de/doc/NEWS>
• <http://ngircd.barton.de/doc/ChangeLog>
And even more information can be found here:
• Homepage: <http://ngircd.barton.de/> (<http://ngircd.mirror.3rz.org>)
• Bug tracker: <http://ngircd.barton.de/bugzilla/>
• Downloads:
• HTTP 1: <http://ngircd.barton.de/pub/ngircd/>
• HTTP 2: <http://ngircd.mirror.3rz.org/pub/ngircd/>
Please note:
The BerliOS platform is shutting down, so our BerliOS mirror site will
become unavailable and all old links to BerliOS will become unreachable!
(see <http://developer.berlios.de/forum/forum.php?forum_id=39220>)
But don't worry too much, ngIRCd already gained a new mirror site, located
at <http://ngircd.mirror.3rz.org>, provided by Götz Hoffart. Thanks a lot!
And as usual, a big thanks to all users, bug reporters, contributors,
packagers, and supporters!
Regards
Alex
Hi! I use ngircd under uLinux working on bfin537. And my question is - how long does ngircd storage messages from one user to another if another user has lost connection for a long time (minute / hour / day)? I tried to find the answer in source code, but unfortunately I have not enough expirience in C-programming. So my search stuck in <Conn_Handler(void)> in <conn.c> file.
So, how long? :)
--
Ivan Dementev
the executable works ("runs") as expected --+
tests run successfully ("make check") --+ |
ngIRCd compiles ("make") --+ | |
./configure works --+ | | |
| | | |
Platform Compiler ngIRCd Date Tester C M T R *
--------------------------- ------------ ---------- -------- -------- - - - - -
i386/unknown/netbsdelf1.5.2 egcs-1.1.2 21.1 14-03-29 root Y Y N Y
# uname -a
NetBSD 1.5.2 NetBSD 1.5.2 (GENERIC) #3: Sat Aug 18 23:37:05 CEST 2001 he@hamster.urc.uninett.no:/usr/src/sys/arch/i386/compile/GENERIC i386
the executable works ("runs") as expected --+
tests run successfully ("make check") --+ |
ngIRCd compiles ("make") --+ | |
./configure works --+ | | |
| | | |
Platform Compiler ngIRCd Date Tester C M T R *
--------------------------- ------------ ---------- -------- -------- - - - - -
powerpc/apple/darwin7.9.0 gcc 3.3 21.1 14-04-14 goetz Y Y Y Y 3
jadzia:~/ goetz$ uname -a
Darwin jadzia.local 7.9.0 Darwin Kernel Version 7.9.0: Wed Mar 30 20:11:17
PST 2005; root:xnu/xnu-517.12.7.obj~1/RELEASE_PPC Power Macintosh powerpc
jadzia:~/ goetz$ sw_vers
ProductName: Mac OS X
ProductVersion: 10.3.9
BuildVersion: 7W98
Hi,
First and foremost, I am not proficient with C. The below patch addresses the
forceful disconnect of clients who may paste or compose more data than
COMMAND_LEN in ngircd-21.1. RFC 2812 states "IRC messages are always lines of
characters terminated with a CR-LF (Carriage Return - Line Feed) pair, and
these messages SHALL NOT exceed 512 characters in length, counting all
characters including the trailing CR-LF."
The below trivial patch avoids client termination. ngricd will already
truncate messages at COMMAND_LEN and insert [CUT] into them indicating they
have been truncated by the daemon.
This patch eliminates some client frustrations when running an RFC-compliant
IRCd. I appreciate the insight and wisdom of others regarding this patch. If
I unleashed the kracken with this horrible patch I apologize in advance, it's
highly likely I've done something wrong with the below :)
Cheers,
Nathan Fowler
--- ./src/ngircd/conn.c 2014-03-18 20:36:34.000000000 -0500
+++ ./src/ngircd/conn.c 2014-04-14 13:33:10.000000000 -0500
@@ -1948,8 +1948,17 @@
"Request too long (connection %d): %d bytes (max.
%d expected)!",
Idx, array_bytes(&My_Connections[Idx].rbuf),
COMMAND_LEN - 1);
- Conn_Close(Idx, NULL, "Request too long", true);
- return 0;
+ /* Conn_Close(Idx, NULL, "Request too long", true); */
+ Conn_WriteStr( Idx,
+ ":%s NOTICE %s :%sRequest too long, %d bytes
(max. %d expected)!",
+ Client_ID(Client_ThisServer()), Client_ID(c),
+ NOTICE_TXTPREFIX,
+ array_bytes(&My_Connections[Idx].rbuf),
+ COMMAND_LEN - 1);
+
+ array_trunc(&My_Connections[Idx].rbuf);
+
+ /* return 0; */
}
len_processed += (unsigned int)len;