contrib/ngircd.service: systemd service file for ngircd Thanks to Kyle Keen <keenerd@gmail.com>: Date: Sat, 18 Aug 2012 08:28:22 -0400 Message-ID: <CAAKTTKNNmrB=8XtxcV6w1Q-RQ6J_xTTDGD4MHQFaDy6V3=B19Q@mail.gmail.com> From: keenerd <keenerd@gmail.com> To: ngircd-ml@ngircd.barton.de Subject: [ngIRCd-ML] systemd service Hello all. Linked is a service file for ngircd. Please add this to your source tree so other people don't have to learn to write service files ;-) https://projects.archlinux.org/svntogit/community.git/plain/trunk/ngircd.service?h=packages/ngircd -Kyle Keen Arch Linux TU http://kmkeen.com
Hashed hostnames for CloakHost Implemented support for hashed hostnames for CloakHost. The admin can use '%x' in both the CloakHost and CloakHostModeX setting. The config option CloakHostModeX was renamed to CloakHostSalt. This salt is used for both cloaking options.
Implemented hashed cloaked hostnames for +x CloakHostModeX can now contain '%x'. It will be replace by the hash of the original client hostname. The new config option CloakHostModeXSalt defines the salt for the hash function. When CloakHostModeXSalt is not set a random salt will be generated after each server restart. Spelling fix in defines.h
Merge branch 'bug124-CloakHostModeX' * bug124-CloakHostModeX: Describe "CloakHostModeX" in sample-ngircd.conf an ngircd.conf(5) Rename "CloakModeHost" option to "CloakHostModeX" Introduce new configuration option "CloakModeHost" This closes bug #124.
Correctly handle asynchronously re-established server links Don't try to establish an outgoing server link after DNS lookup when this server re-connected on its own in the meantime. In addition, log a warning message if we try to update the connection index of an already connected server structure -- and ignore it. Up to now, both behaviour could lead to a race when the remote server connects to this daemon while it still prepares the outgoing connection: - The local server prepares the new outgoing connection ... - in the meantime the remote server becomes connected and registered. - Now the new outgoing connection overwrites the (correct) socket handle, - then the 2nd connection becomes disconnected: "already registered", - and the 1st connection becomes unhandled ("gets lost") because the configuration structure is reset because of the wrong socket handle. This patch hopefully fixes all these problems.