load (for example when the webserver is down), then the most recent
version of that remote include will be used, and the ircd will still boot
and be able to rehash. Even though this is quite a simple feature, it
can make a key difference when deciding to roll out remote includes on
your network. Previously, servers would be unable to boot or rehash when
the webserver was down, which would be a big problem (often unacceptable).
The latest version of fetched urls are cached in the cache/ directory as
cache/<md5 hash of url>.
Obviously, if there's no 'latest version' and an url fails, the ircd will
still not be able to boot. This would be the case if you added or changed
the path of a remote include and it's trying to fetch it for the first time.
To disable this new behavior, check out REMOTEINC_SPECIALCACHE in
include/config.h.
(HOOKTYPE_PACKET). Replacing the 'text to be sent' to a client is
supported, which allows character(set) conversion in a module.
Note that modifying an incoming message by the hook is not supported.
from not binding to that ip when linking, to not being able to link at
all. Also fixed a very small memory leak upon /REHASH. Bug reported by
Mr_Smoke (#0003858).
timesynch) made autoconnect not work for the duration of the offset
(eg: -60 would make autoconnect wait 60 seconds after boot, instead of
autoconnecting almost immediately). Reported by aragon (#0003853).
printed out as a warning, when in fact it's an error (and was treated as
such). Same for ZIP on non-zip compile. Reported by Stealth (#0003833).
..& updated credits..
- When pkg-config is present but does not recognize --static, use
default c-ares library options.
- Set default c-ares library options to -lcares on FreeBSD and others.
Set to -lcares -lrt on Linux (previously was -lcares -lrt for all).
Thanks to goldenwolf for the bugreport (#0003803) and providing a test-
shell to trace this issue down.
such as 3 connections per 60 seconds. Previously that could result in 3
per 90 seconds due to timer inaccuracy, now max 65 seconds (max 5s
inaccuracy).
In the IRCd world correct time is very important. This means that time
should be correct when the IRCd is booted, either by running ntpd/ntpdate
on the system or some other synchronization software, or by using the
built-in timesync feature.
Whenever the clock is adjusted for more than a few seconds AFTER the IRCd
has booted, it can lead to dangerous effects ranging from unfair
timestamps
for nicks and channels (and hence the possibility to takeover channels),
to even completely stalling the IRCd (negative timeshift) or making it so
nobody can connect anymore due to throttling (positive timeshift).
We now try to 'fix' the worst effects such as the IRCd freeze and
throttling. This does not fix the whole problem, so I've added some big
warnings when the clock is adjusted, including an annoying one every 5
minutes if the clock was set backwards, until the time is OK again
(catches up with the original time).
This fixes#0003230 reported by Stealth, and #0002521 reported by durrie.
set::spamfilter::slowdetect-fatal, set::ssl::server-cipher-list,
set::ssl::renegotiate-bytes, set::ssl::renegotiate-timeout,
set::watch-away-notification and ./unreal gencloak. Reported by Bock
(#0003764).
- set::ssl::renegotiate-bytes: fix when specifying a value such as 10m.
- './unreal gencloak' now actually works
- Fix typo in user mode q notice, reported by Strawberry_Kittens and others
(#0003761).
- Possible fix for MAC OS X compile problem - UNCONFIRMED.
(NickServ client, NULL if not present). You can return 1 (HOOK_DENY) to
make the IRCd not send IDENTIFY to NickServ. Suggested by tabrisnet
(#0003739).
(sorry, previous half-commit to src/modules/m_nick.c was accidental)
- Win32: Made UnrealIRCd run as a service under non-privileged accounts
(ones that do not belong to the Administrator group). Reported by
skyflash, Bock, zer, etc... Thanks to BuHHunyx for some hints on how to
fix this.
Bram Matthys