Make sure that all log messages end with a correct punctuation mark.
The rules for formatting log messages are:
1. Add punctuation marks to all messages passed to the actual logging
functions like Log() and LogDebug().
2. Don't add any punctuation marks to messages that are stored in
variables for later use or are passed over the network.
3. IP addresses, DNS host names and IRC server names should be quoted.
4. Messages originating in the network should be quoted (at least if
they are "untrusted" or variable).
Most probably this patch doesn't fix all mistakes, but it should be a
good starting point ...
The header file "netinet/in_systm.h" already is optional in ngIRCd, so
don't require it in the configure script. Now ngIRCd can be built on
Minix 3 again :-)
Don't run ngIRCd in forground mode but let it daemonize itself. This
enhances the log output of "systemctl status ngircd.service", because
now ngIRCd doesn't print out its PID and timestamp on each log message
which is redundant: it becomes logged by systemd/journald already.
Now ngIRCd returns a more specific error message for numeric
ERR_NOTREGISTERED(451) when a regular user tries to use a command that
isn't allowed for users but for servers: ERR_NOTREGISTEREDSERVER(451).
Don't report ERR_NEEDMOREPARAMS(461) when a MDOE command with more modes
than nicknames is handled, as well as for channel limit and key changes
without specifying the limit or key parameters.
This is how a lot (all?) other IRC servers behave, including ircd2.11,
InspIRCd, and ircd-seven. And because of clients (tested with Textual and
mIRC) sending bogus MODE commands like "MODE -ooo nick", end-users got the
expected result as well as correct but misleading error messages ...
If ngIRCd is compiled using "strict mode", these errors are still reported.
Reported-by: Tim <tim@stackwatch.net>
This patch introduces the new function Conf_SSLInUse() to check when the
current server configuration requires the SSL subsystem to be initialized
and accounts incoming as well as outgoing connections -- so this fixes
commit bb20aeb9 ("Initialize SSL when needed only, and disable SSL on
errors") which only handled the inbound case ...
Tested-by: Brett Smith <brett@w3.org>
* bug145-ProvideHelp:
Use "${docdir}/Commands.txt" as help text file
Add a note that "help file" is updated on startup and REHASH only
Add doc/Commands.txt which should document all commands
Implement Help() function parsing and returning the help text
Document "HelpFile" in sample-ngircd.conf and ngircd.conf.5
Implement new configuration option "HelpFile"
IRC_HELP(): Code cleanup
Refactor Read_Motd() into Read_TextFile()
This document can be used as "help text", too, see configuration option
"HelpFile" in ngircd.conf(5).
Please note that this file in its current state is far from complete, only
a few commands are documented, but you should get an idea how it works.
So please send in patches adding the remaining parts! :-)
This function parses the already read in help text and sends the requested
portions to the user. Parsing is done as following when a user user
issues a "HELP <cmd>" command:
1. Search the file for a line "- <cmd>",
2. Output all subsequent lines that start with a TAB (ASCII 9) character
to the client using NOTICE commands, treat lines containing a single "."
after the TAB as empty lines.
3. Break at the first line not starting with a TAB character.
This format allows to have information to each command stored in this file
which will not be sent to an IRC user requesting help which enables us to
have additional annotations stored here which further describe the origin,
implementation details, or limits of the specific command.
A special "Intro" block is returned to the user when the HELP command is
used without a command name.
This new configuration option allows to specify a specially formatted
text file which can be used by the HELP command to provide information
about the commands and their syntaxes.
Only check the channel user modes of the initiator if he is joined to
this channel and not an IRC operator enforcing modes (which requires
the configuration option "OperCanUseMode" to be enabled), because trying
to check channel user modes of a non-member results in this assertion:
Assertion failed: (cl2chan != NULL), function Channel_UserModes,
file channel.c, line 742.
This closes bug #147, thanks to James Kirwill <james.kirwill@bk.ru>
for tracking this down!
This fixes the following warning messages of gcc 4.5.3 on Cygwin when
building with debug code enabled:
ng_ipaddr.c: In function ‘ng_ipaddr_init’:
ng_ipaddr.c:52:2: warning: comparison between signed and
unsigned integer expressions
ng_ipaddr.c:53:20: warning: comparison between signed and
unsigned integer expressions
resolve.c: In function ‘ForwardLookup’:
resolve.c:271:3: warning: comparison between signed and
unsigned integer expressions
Now the Makefiles support spaces in "$sysconfdir", which isn't uncommon
for Cygwin for example, when $HOME contains whitespaces ("/home/User Name")
and ngIRCd is installed into the user home ("./configure --prefix=$HOME").
This fixes the following warning message of 4.5.3 on Cygwin:
resolve.c: In function ‘ForwardLookup’:
resolve.c:273:21: warning: comparison between signed and
unsigned integer expressions
Now ngIRCd uses two fields internally, one to store the "real" hostname
and one to save the "cloaked" hostname. And both fields can be set
independently using the "METADATA host" and "METADATA cloakhost" commands.
This allows "foreign servers" (aka "IRC services") to alter the real and
cloaked hostnames of clients without problems, even when the user itself
issues additional "MODE +x" and "MODE -x" commands.
This fixes a few warnings of this type:
XXX.c: In function 'AAA':
XXX.c:YY: warning: array subscription has type 'char'
Tested on NetBSD 5.0.2 with gcc 4.1.3.
This is correctly handled by ipaddr/ng_ipaddr.h today, and the check
in tool.h isn't required any more -- and caused errors on OpenBSD 5.0:
In file included from ./../tool/tool.h:23:
/usr/include/arpa/inet.h:74:
warning: "struct in_addr" declared inside parameter list
This flag indicates, that the server supports the enhanced "xop channel
user modes", like channel owner, admin, and halfop. This information is
used to make sure that no unsupported CHANINFO commands are sent to
servers not supporting such mode prefixes, for example.
Alexander Barton