Thanks Katherine Peeters for the patch and pull request!
Closes#294.
* katp32/master:
Improve documentation for --syslog
Added command line flag to enable syslog
Split NoSyslog from behaviour of NoDaemon
- Bring sample-ngircd.conf and ngircd.conf.5 description in line.
- Fix configuration parsing, it always showed the 'Unknown variable
"Autojoin"' error message, even when everything was perfectly fine.
- And fix a build error (at least on macOS with Apple Clang 14):
login.c:234:3: error: call to undeclared function 'IRC_JOIN'; ISO
C99 and later do not support implicit function declarations
[-Wimplicit-function-declaration]
IRC_JOIN(Client, &Req);
^
The #include for the "irc.channel.h" header was missing!
- Remove a unused variable that caused a compiler warning:
login.c:222:12: warning: unused variable 'n' [-Wunused-variable]
size_t i, n, channel_count = array_length(&Conf_Channels, sizeof(*conf_chan));
^
- Add a explicit cast to fix a compiler warning:
login.c:235:15: warning: assigning to 'char *' from 'const char[51]'
discards qualifiers [-Wincompatible-pointer-types-discards-qualifiers]
Req.argv[0] = conf_chan->name;
^ ~~~~~~~~~~~~~~~
Let's behave like most(?) other IRC daemons (at least ircd2.11) and hide
all +i users when WHOIS is used with a pattern. Otherwise privacy of
this users is not guaranteed and the +i mode a bit useless ...
Reported by Cahata on #ngircd, thanks!
All numeric replies must originate from an IRC server, never from a
client. So fix the RPL_INVITING message!
Thanks tommyrot for reporting this!
Closes#307.
The debug log messages are always available and a runtime option (since
commit c7de505c), but the assert()'s are only active when ngIRCd was
configured with the "--enable-debug" option.
So only add "+DEBUG" to the version string when the latter is the case.
This basically means to unifdef DEBUG in (almost) all places.
We keep it in src/portab/portab.h so DEBUG stays available to
enable assert(). Also add a comment about this.
Implement new numeric ERR_INVALIDMODEPARAM_MSG(696) and:
- Reject channel keys with spaces and return ERR_INVALIDMODEPARAM_MSG;
This was possible until now and resulted in garbled IRC commands later.
- Reject empty channel keys and return ERR_INVALIDMODEPARAM_MSG;
This was possible until now and resulted in garbled IRC commands later.
- Return ERR_INVALIDMODEPARAM_MSG when user limit is out of bounds;
This was silently ignored until now.
Closes#290. Thanks Val Lorentz for reporting it!
This relates to #290 and considerations which errors to show when: and I
think it is the better approach to give feedback instead of silently
failing.
Note that this code path is also used when handling modes of channels
defined in "[Channel]" blocks in configuration files: in this case the
client is the local server and we can't send messages to it, because it
has no socket connection! Therefore we need those "is_machine" checks
and log an error im this case.
Don't forbid the local server to change modes on local channels: this
happens when overriding modes on local (&) channels in the server
configuration file, for example, and is perfectly fine.
Without this patch, the server worked as expected but showed critical
error messages for each local channel in its configuration file:
"Got remote MODE command for local channel!? Ignored."
Conf_GetServer() can return NULL when the server introducing the client
had a write error for example, and is being disconnected.
So make sure that we have a valid server before calling Conf_NickIsService()!
This fixes the following compiler warning, for example on OpenBSD:
conf.c: In function 'Conf_Test':
conf.c:391: warning: format '%ld' expects type 'long int', but argument
2 has type 'time_t'
Thanks to Götz Hoffart for reporting this!
Basically, the issue described in #281 is that the test suite uses the
IPv4 address 127.0.0.1 on an IPv6-only host. But this is the "safest"
thing to do in (almost) all other setups: relaying on DNS host names
makes things even more complex, as different systems map 127.0.0.1
differently (including the reverse lookup; that's why we switched to
127.0.0.1 back in 2014, see commit 3f807e1045).
But with AI_ADDRCONFIG set, on an IPv6-only host, we prevent 127.0.0.1
to get translated properly, even when the loopback interface has this
address configured! So don't set it any more.
The drawback is that the resolver possibly returns more addresses now,
even of an unsupported/not connected address family; but this shouldn't
do much harm in practice, as ngIRCd iterates over all returned addresses
while trying to establish an outgoing connection.
Closes#281.