The daemon only enlarged its connection pool when accepting new client
connections, not when establishing new outgoing server links.
Thanks to Lukas Braun (k00mi) for reporting this!
In addition this patch streamlines the connection pool allocation, so
that there is only one place in the code allocating the pool: the now
updated Socket2Index() function. The name doesn't quite fit, but this
existing and today quite useless function (because the mapping from
socket number to connection index is 1:1 today) already became called
in almost all relevant code paths, so I decided to reuse it to keep the
patch small ...probably we want to fix the naming in a second patch?
Closes#231.
- Add more comments/documentation.
- Add dependencies for services and proxy scanners.
- Add more limit configurations.
- Allow AF_UNIX address family, required for syslog!
- Add homepage :-)
- Remote CAP_SETUID and CAP_SETGID from CapabilityBoundingSet: This is
nor needed, because the unit already sets User=irc and Group=irc.
- Add RestrictAddressFamilies, and restrict it to AF_INET and AF_INET6.
- Read in the Debian "default files", but note: only PARAMS is supported!
- Update debhelper compatibility to version 9.
- Update build-dependencies.
- Change group of ngircd.conf to "irc" in postinst script (this makes
starting ngIRCd as user "irc" easier, for example when using systemd).
- Don't create /var/run/ircd during installation: this is handled by the
SysV init script and the systemd service already.
Don't wait for the peer to close the connection. This allows us to
forward the ERROR mesage in the network, instead of the very generic
"client closed connection" message.
Explicitely forbid remote servers to modify "x-lines" (G-LINES) when the
"AllowRemoteOper" configuration option isn't set, even when the command
seems to originate from the remote server itself: this prevents GLINE's
to become set during server handshake in this case (what wouldn't be
possible during regular runtime when a remote IRC Op sends the command)
and what can't be undone by IRC Ops later on (because of the missing
"AllowRemoteOper" option) ...
At the moment, ngIRCd fails to build against OpenSSL 1.1 since the
configure check probes for the SSL_library_init symbol which was
removed, but probing for a different function availabe in both versions
solves that problem: SSL_new().
And as SSL_library_init is no longer needed, the patch boils down to
probing SSL_new to assert libssl is available, and disabling the
SSL_library_init invokation from OpenSSL 1.1 on, see also another
application[1] (NSCA-ng) that did pretty much the same.
Patch was compile-tested on both Debian jessie (OpenSSL 1.0.2) and
stretch (OpenSSL 1.1).
[1] <https://www.nsca-ng.org/cgi-bin/repository/nsca-ng/commit/?id=8afc22031ff174f02caad4afc83fa5dff2c29f8a>
(Patch by Christoph, commit message cherry-picked from the email thread
on the mailing list by Alex. Thanks!)
This fixes the following correct -Wmisleading-indentation warning
messages of gcc 6.2:
irc-write.c: In function ‘IRC_SendWallops’:
irc-write.c:521:4: warning: this ‘if’ clause does not guard...
irc-write.c:524:5: note: ...this statement, but the latter is
misleadingly indented as if it is guarded by the ‘if’
irc-write.c:526:4: warning: this ‘if’ clause does not guard... []
irc-write.c:529:5: note: ...this statement, but the latter is
misleadingly indented as if it is guarded by the ‘if’
irc-info.c: In function ‘IRC_STATS’:
irc-info.c:895:3: warning: this ‘else’ clause does not guard...
irc-info.c:897:4: note: ...this statement, but the latter is
misleadingly indented as if it is guarded by the ‘else’
No functional changes, the code has been correct, but the indentation
was wrong ...
- Update x86_64/apple/darwin15.6.0 (Apple clang 8.0)
- Update x86_64/unknown/linux-gnu (gcc 4.9.2)
- Update i386/pc/solaris2.11 (gcc 4.8.2), tests have been run both on
Solaris 11.2 and Solaris 11.3 successfully, but the system identifier
is the same ... Thanks to Götz Hoffart <goetz@hoffart.de>!
- SC2006: Use $(..) instead of legacy `..`.
- SC2015: Note that A && B || C is not if-then-else. C may run
when A is true.
- SC2086: Double quote to prevent globbing and word splitting.
- SC2166: Prefer [ p ] && [ q ] as [ p -a q ] is not well defined.
This setting allows to run multiple ngIRCd instances with separate PAM
configurations on each instance. If one sets it to ngircd-foo, PAM will
use /etc/pam.d/ngircd-foo instead of the default /etc/pam.d/ngircd.
Thanks to "somechris" for the patch & pull request!
Closes#226.
This setting allows to run multiple ngIRCd instances with
PAM configurations on each instance.
If one sets it to "ngircd-foo", PAM will use `/etc/pam.d/ngircd-foo`
instead of the default `/etc/pam.d/ngircd`.
This combination had been successfully tested with ngIRCd 21, but after
further investigation didn't build correctly: it seems as if tcc fails
to correctly link external libraries (e. g. ngipaddr).
Astonishingly the test suite passed nevertheless, with garbled output,
but without the daemon crashing!?
When using tcc with ngIRCd 23 (and current master), the test suite fails
completely because the daemon crashes ... (which actually is good!)
Display "?" in the "runs" colum when the simple "run test" succeeded but
the test suite failed. And display a message to double check the actual
status, because it is somewhat unclear, if the daemon actually "works"
or not in this case.
Clients can specify multiple targets for the "PRIVMSG", "NOTICE", and
"SQUERY" commands, separated by commas (e. g. "PRIVMSG a,#b,c :text").
Since commit 49ab79d0 ("Limit the number of message targes, and suppress
duplicates"), ngIRCd crashed when the client sent the separator character
only as target(s), e. g. "," or ",,,," etc.!
This patch fixes the bug and adds a test case for this issue.
Thanks to Florian Westphal <fw@strlen.de> for spotting the issue!
Alexander Barton