ZNC replies to /mode #chan with the cached channel modes without querying the
IRCd. This was added to avoid traffic spikes to the ircd when a client
logged in.
The logic in this code had a bug that made it also reply with stale cached
values if we once were but aren't anymore in that channel (e.g. after
you've been kicked).
Thanks to tomaw for reporting this.
git-svn-id: https://znc.svn.sourceforge.net/svnroot/znc/trunk@1507 726aef4b-f618-498e-8847-2d620e286838
Now e.g. the message "Invalid Password" on login even reaches the other end
before the connection shoots itself in the foot.
There is one place in Client.cpp which I didn't change: ReachedMaxBuffer()
If a client is flooding is, why should we wait until we are done answering
that flood?...
Thanks to morelia for making me notice this.
git-svn-id: https://znc.svn.sourceforge.net/svnroot/znc/trunk@1506 726aef4b-f618-498e-8847-2d620e286838
The old code failed to collect the following command to *shell correctly:
exec > /dev/null 2> /dev/null < /dev/null ; sleep 10
The timeout in CExecSock::close2() was over before the child processes exited
and a zombie was left behind. Plus we used some ugly busy looping while
waiting for the child to exit. Using SIGCHLD for collecting zombies is
soooooo much nicer.
git-svn-id: https://znc.svn.sourceforge.net/svnroot/znc/trunk@1504 726aef4b-f618-498e-8847-2d620e286838
configure now generates to files for pkg-config:
znc.pc and znc-uninstalled.pc
This is supposed to replace the znc-config binary. Everything which can be done
with znc-config can now also be done with pkg-config.
znc-uninstalled.pc is only generated by configure, but not installed by the
Makefiles. It's there to fix some kind of bug we have with znc-config.
ZNC can run quite fine from the source, there is no need to ever run
"make install". The only problem is that e.g. znc-extra won't build, since
it gets -I/usr/local/include/znc from znc-config which doesn't work since znc
was never installed.
pkg-config has a nice fix for this: If you ask for "a", but "a-uninstalled"
exists, pkg-config will use the later one instead. This is used in
znc-uninstalled.pc to output a different -I flag which works for the
uninstalled headers.
(You only have to set $PKG_CONFIG_PATH to znc's source dir for this to work)
git-svn-id: https://znc.svn.sourceforge.net/svnroot/znc/trunk@1503 726aef4b-f618-498e-8847-2d620e286838
When you are already in #znc and you did 'stick znc' (# prefix missing!),
stickychan caused segfaults or different weird behavior. This happened because
stickychan didn't handle errors from CUser::AddChan(). AddChan() can only error
out if the channel already exists, but since stickychan already checked this,
were does the error come from?
CChan's constructor does some sanity checks on the channel name. It
automatically adds the proper channel prefix (most likely #) if it's missing.
This means when stickychan checked for the channel "znc" it correctly didn't
find one. When it then tried to add "znc", it really tried adding "#znc" which
could fail if the channel was already added.
Thanks to DM8Mydog for finding this.
git-svn-id: https://znc.svn.sourceforge.net/svnroot/znc/trunk@1500 726aef4b-f618-498e-8847-2d620e286838
Now ZNC compiles with -Wmissing-declarations :)
(BTW I hate the perl headers, could some fix them app so that they cause
less warnings?)
git-svn-id: https://znc.svn.sourceforge.net/svnroot/znc/trunk@1499 726aef4b-f618-498e-8847-2d620e286838
fcntl.h is needed for fcntl() and defines like FD_CLOEXEC, F_SETFD and F_GETFD.
This worked so far, because some C++ header pulled in fcntl.h, but there are
systems out there for which this is not true. (Found on solaris)
Thanks to sartek.
git-svn-id: https://znc.svn.sourceforge.net/svnroot/znc/trunk@1497 726aef4b-f618-498e-8847-2d620e286838
perl's LDFLAGS where included in $LIBS when checking for libperl. This meant
that e.g. the -L flag necessary for finding libperl was after the "-lperl"
argument. This made the test fail.
This moves these flags into $LDFLAGS (and later restores the old $LDFLAGS
since only modperl needs those flags, modules/Makefile.in handles that).
Thanks to sartek for reporting this is broken on solaris and testing the patch.
git-svn-id: https://znc.svn.sourceforge.net/svnroot/znc/trunk@1496 726aef4b-f618-498e-8847-2d620e286838
CNick::GetPermStr() segfaulted if called on e.g. the CNick from OnChanMsg().
Thanks to stebi3 for the bug report via the sf.net bug tracker.
git-svn-id: https://znc.svn.sourceforge.net/svnroot/znc/trunk@1491 726aef4b-f618-498e-8847-2d620e286838
This adds a new, second argument to fail2ban which is the number of failed
logins one is allowed before being banned. Each login attempt resets the
timeout. This value defaults to 2.
git-svn-id: https://znc.svn.sourceforge.net/svnroot/znc/trunk@1489 726aef4b-f618-498e-8847-2d620e286838
This adds a second template parameter to TCacheMap which is the value which is
saved in the map. This second parameter can be retrived with the new
TCacheMap::GetItem() and set with a new second argument to TCacheMap::AddItem()
git-svn-id: https://znc.svn.sourceforge.net/svnroot/znc/trunk@1487 726aef4b-f618-498e-8847-2d620e286838
Before this, the KICK message was missing a target which was kicked.
Now the user kicks himself. :)
Thanks to JoeK for reporting this bug.
git-svn-id: https://znc.svn.sourceforge.net/svnroot/znc/trunk@1486 726aef4b-f618-498e-8847-2d620e286838
This moves all static webadmin files (images, css) to the data/ subdirectory
of the skin dir. The webadmin module is changed to redirect requests to
/<skin name>/ to that data directory. The skins are changed to use the
new URL when linking to their stuff. (I only needed to change the path to
the main.css file in each Header.tmpl. Since the .css and the images are now
in the same directory, relative URLs work just fine).
This means that we now generate different URLs after changing the webadmin
skins and the browser cache can do its thing.
git-svn-id: https://znc.svn.sourceforge.net/svnroot/znc/trunk@1481 726aef4b-f618-498e-8847-2d620e286838
The new CloneUser command allows one to create a user with a space in
its name and the code for reading znc.conf allows spaces too. So now
one can even get rid of this users again...
git-svn-id: https://znc.svn.sourceforge.net/svnroot/znc/trunk@1478 726aef4b-f618-498e-8847-2d620e286838
He provides native win32 builds of ZNC and writes patches to make
ZNC compile and work there. Plus he knows how to use google ;)
git-svn-id: https://znc.svn.sourceforge.net/svnroot/znc/trunk@1475 726aef4b-f618-498e-8847-2d620e286838
That false/true thing makes no sense and pUser was passed in to a bool
argument which means it was always true... weird...
git-svn-id: https://znc.svn.sourceforge.net/svnroot/znc/trunk@1472 726aef4b-f618-498e-8847-2d620e286838
CZNC::ExpandConfigPath() handles an empty string as its argument quite well, so
make all those other places use this.
git-svn-id: https://znc.svn.sourceforge.net/svnroot/znc/trunk@1469 726aef4b-f618-498e-8847-2d620e286838
Without this the restart after the config is written fails, because the file
name it wants to open went through ExpandConfigPath() twice. This lead to a
path like ./some-dir/configs/some-dir/configs.
git-svn-id: https://znc.svn.sourceforge.net/svnroot/znc/trunk@1468 726aef4b-f618-498e-8847-2d620e286838
This now only reads new data from disk if there is less than 1 MiB left to be
sent, which is still a lot. Before this there was no limit and the other end of
the socket could try to make us run out of memory.
git-svn-id: https://znc.svn.sourceforge.net/svnroot/znc/trunk@1463 726aef4b-f618-498e-8847-2d620e286838
Make CDCCSock use uint32_t to generate the "unsigned, 4 byte integer in network
byte order" which is used to acknowledge the received data. Also make
OpenFile() abort for files bigger than 4 GiB, because we would run into
integer overflows later on. These transfers might work with some remote client,
but ZNC is (no longer?) one of them. ;)
Thanks to KiNgMaR for the original patch and some help with the uint32_t stuff.
git-svn-id: https://znc.svn.sourceforge.net/svnroot/znc/trunk@1461 726aef4b-f618-498e-8847-2d620e286838