As I just saw potentially sensitive data for user modules is stored as cleartext, eg. in the nickserv module.
Generally it's not that big a deal, since on a properly configured server, only few people should have access to the data.

Anyhow, it would be more secure to store any kind of password (if it has to be stored on HDD like Nickserv-Password apparently does) at least hashed.

Compare:

/home/$zncuser/.znc/users/$user/moddata/nickserv/.registry where the nickserv password, if entered ist stored as cleartext on a default ZNC setup..

I'd like to be able to sort the tables in the webadmin. In particular the userlist; an alternative would be to place the connected users first, but I think it would be easiest to use something like sort-table, which simply requires a line in the header, and applying the 'sortable' class to the table in order to be able to click the table headers.

Did you help close this issue? Go claim the $5 bounty on Bountysource.

Hi

I have bindhost which has an IPv6 and an IPv4 address, when I connect to an IPv6 IRC server ZNC connects fine, when I connect to an IPv4 server I get

[08:43] <_status> Attempting to connect to [1.2.3.4 6667] ...
[08:43] <_status> Cannot connect to IRC (Invalid argument). Retrying...

If I run ZNC in debug mode I see the following

User [user] is connecting to [1.2.3.4 6667] ...
Csocket.cpp:880 Connect Failed. ERRNO [22] FD [6]
IRC::user == SockError(22 Invalid argument)

Is this something that can be fixed?

Work around for now is to create a bindhost which is the IPv4 address of which ZNC will use to connect from.

Regards

This is on edaa20e

For some reason I can't get simple_away to work. I've gone all the way down to add a DEBUG line right above line 171 of modules/simple_away.cpp to at least prove that ZNC gets there and attempts to set the away status (it does).

However the away message is never sent (in the debug log I never see ZNC -> IRC saying away).

I've also connected directly to the IRC server to see for sure if my ZNC server wasn't setting away and it wasn't (and yes I was the last client to disconnect)

Ironically when I reconnect to ZNC I see ZNC -> IRC setting me back from away, though as stated I was not previously away.

Maybe it's just me?

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

NickServ module should ask for nickname which it uses to identify to NickServ. Sometimes people use nicks which aren't registered. This could be useful in case of connecting to network and someone else is using the registered nickname or nickname being blocked. ZNC uses just alternative nick when connecting and that is probably not registered either.

When the colloquy-module tries to send a push-notification, it fails with the following error;

Csocket.cpp:882 Connect Failed. ERRNO [22] FD [11]
MOD::C::colloquy::efnet == SockError(Invalid argument)

Looking up that part in Csocket.cpp;

    if( !GetIPv6() )
        ret = connect( m_iReadSock, (struct sockaddr *)m_address.GetSockAddr(), m_address.GetSockAddrLen() );
#ifdef HAVE_IPV6
    else
        ret = connect( m_iReadSock, (struct sockaddr *)m_address.GetSockAddr6(), m_address.GetSockAddrLen6() );
#endif /* HAVE_IPV6 */
#ifndef _WIN32
    if ( ( ret == -1 ) && ( GetSockError() != EINPROGRESS ) )
#else
    if ( ( ret == -1 ) && ( GetSockError() != EINPROGRESS ) && ( GetSockError() != WSAEWOULDBLOCK ) )
#endif /* _WIN32 */

    {
        CS_DEBUG( "Connect Failed. ERRNO [" << GetSockError() << "] FD [" << m_iReadSock << "]" );
        return( false );
    }

I'm no programmer, but could my issue be caused by having IPv6-address with prefix /96? Or maybe something other related to my IPv6-setup?

A complete error-message from ZNC can be found here; http://home.komsys.org/~jocke/colloquypush-error.txt

hi,

got some errors with gcc 4.3.1. used options: --enable-extra --disable-perl.
include paths are censored :-P

g++ -I/usr/xxx -I/usr/lxx -I/usr/xx/include -I/usr/xx/include -O3 -D_FORTIFY_SOURCE=2 -O2 -DHAVE_IPV6 -Wall -W -Wno-unused-parameter -Woverloaded-virtual -Wshadow -DHAVE_LSTAT -DHAVE_LIBSSL -D_MODULES -D_MODDIR_="/usr/local/znc/lib/znc" -D_DATADIR_="/usr/local/znc/share/znc" -c -o main.o main.cpp -MMD -MF .depend/main.o.dep
main.cpp:14: error: 'no_argument' was not declared in this scope
main.cpp:15: error: 'no_argument' was not declared in this scope
main.cpp:16: error: 'no_argument' was not declared in this scope
main.cpp:17: error: 'no_argument' was not declared in this scope
main.cpp:18: error: 'no_argument' was not declared in this scope
main.cpp:19: error: 'no_argument' was not declared in this scope
main.cpp:20: error: 'no_argument' was not declared in this scope
main.cpp:21: error: 'no_argument' was not declared in this scope
main.cpp:23: error: 'no_argument' was not declared in this scope
main.cpp:25: error: 'required_argument' was not declared in this scope
main.cpp:27: error: elements of array 'const option g_LongOpts []' have incomplete type
main.cpp:27: error: storage size of 'g_LongOpts' isn't known
main.cpp: In function 'int main(int, char**)':
main.cpp:96: error: 'getopt_long' was not declared in this scope

gmake: *** [main.o] Error 1

tried multiple versions down to 0.6.x. all had that error.
any help is welcome & thanks in advance :-)

It appears that as of 0.200, channels declared in the config file are now joined in alphabetical order, rather than the order in which they're declared in the config file, as in past versions. I know many people use clients that may add tabs/windows for channels in lexical order, regardless of the order in which a channel is listed. So those folks won't even notice this change. However, I suspect there are many that also join them in the order in which the server asks the client to join on connect, or the order in which the user joins the channels after connecting. As such, the latter group may have declared their channels in the config to be in an order they prefer. So perhaps a good solution would be to add a config knob at the level, that tells znc which scheme to use when joining predefined channels, such as lexical or none.

I would like to see znc errors logged to syslog. This allows it to fit more easily into standard ops workflows so alerts can be set up, so there is a known place to look for errors, and the is a history of logs that can be archived. The current practice of logging to an admin user on *status doesn't help if an admin user is not currently logged in to znc.

I tried to remove account (which I used only to test issue #94) which was just clone of my main account and it was fixed to partyline channel. I did this with *admin module (log below).

<Mkaysi�>��deluser Mkaysi-test
�<�*admin�>�� User Mkaysi-test deleted!

• Yhteys katkaistu (Vastapää sulki pistokkeen).
  (* Disconnected (remote host closed the connection).)

We were running ZNC with --debug and the last thing in output is:

(Mkaysi) CLI -> ZNC [PRIVMSG _admin :deluser Mkaysi-test]
charset: [PRIVMSG+%2Aadmin+%3Adeluser+Mkaysi-test] is valid [UTF-8] already.
(Mkaysi) ZNC -> CLI [:_admin![email protected] PRIVMSG Mkaysi :User Mkaysi-test deleted!]
/usr/include/c++/4.4/debug/safe_iterator.h:204:error: attempt to increment
a singular iterator.

Objects involved in the operation:
iterator "this" @ 0x0x7fffd130fea0 {
type = N11__gnu_debug14_Safe_iteratorISt23_Rb_tree_const_iteratorIP17CPartylineChannelENSt7__debug3setIS3_St4lessIS3_ESaIS3_EEEEE (mutable iterator);
state = singular;
references sequence with type `NSt7__debug3setIP17CPartylineChannelSt4lessIS2_ESaIS2_EEE' @ 0x0x7fffd130fea0
}
zsh: abort znc --debug

There's a network-spefic ident set. I try to change it to the same as used in the whole user. Click Save.
Open the network again, nothing happened, old ident is used.

I use ~30 channels on a single user (freenode).
If I set above a certain number (20?) of those channels to be sticky I am unable to reconnect to the server after an outage due to 'Excess Flood'.
I believe this is due to stickychan not being throttled.
I have 'Max Joins' set to 2.

Skips network modules

ZNC 0.202

After asking psychon to make the "Disable"-Setting for Channels access & change-able via webadmin he gave me http://sprunge.us/GfYN?diff for testing. The patch worked as expected but I found a general bug for disabled channels. If you can access the channel again (f.e. no more invite only or a removed ban) and you enable the channel ZNC try to access the chan but will give up with "<*status> The channel #ABC could not be joined, disabling it." even if znc could have join (tested with a /join #abc shortly after the message)
normaly i didn't recognise this because i hade "enough" JoinTrys and did /znc enablechan * and then a jump after a netsplite.

if you want to see how i tested take a look at http://pastie.org/2768274

When using SSL/TLS, a server has the option of presenting a certificate containing either an RSA key or a DSA key. The use of DSA keys is more secure in SSL/TLS, because DSA permits the use of Diffie-Hellman key negotiation and its corresponding Perfect Forward Secrecy, while RSA does not (in theory, there is no reason why an RSA key can't be used to sign an ephemeral DH public key, and indeed PGP does this, but SSL/TLS does not support this mode of operation). Thus, DSA keys are potentially more secure when used with SSL/TLS than RSA keys.

However, ZNC does not currently permit the use of DSA server keys (although the server will start up fine, any attempt to connect to it will fail). This is because, in order to use ephemeral DH, the SSL context needs to have DH parameters attached. The parameters are slow to generate (primality testing) but can be used forever; individual DH keys are generated very quickly from the parameters and are used for one connection and discarded, thus achieving Perfect Forward Secrecy.

Traditionally, DH parameters would be stored in a file for permanent use. In fact, they can be stored in the same PEM file with the key and certificate. I will attach (if that's possible on Github) a patch that inserts the few lines of code necessary to load DH parameters from the PEM file. If no DH parameters are present, the new code fails silently; thus, there is no effect on existing RSA-based servers which don't have DH parameters at all.

When you: /msg *admin AddCTCP $me VERSION
this should make ZNC not respond to the CTCP aswell as block it from getting through to the client, but this however is not the case: it still gets passed along to the client.

If you however do this: /msg *admin AddCTCP $me VERSION blahblah
then it works as expected, ZNC replies to it by itself (with blahblah as reply) and does not bother the client at all.

They don't support module hooks of global modules, such as OnModuleUnloading.
For python, except adding them to module.h, functions.in and znc.py, need to fix codegen.pl to check if GetUser() returned NULL when reporting an error.

Hi,

One of the main attractions of ZNC for my group is the partyline module. It's usefulness it limited, however, because it does not support the playback buffer.

For example: George sends a /msg to ?Susan, who is not connected to ZNC at the moment. George's message is silently accepted by ZNC, even though Susan will never receive it. When Susan reconnects to ZNC, she has no idea that George was trying talking to her. Not good.

I think adding full support for playback buffer would be ideal.

Less ideal, but still a big step forward in user-friendliness, would be to display an error message when George attempt to /msg ?Susan while she is not connected to ZNC.

Just an idea from an ZNC fan! I can't code it myself, so thanks for considering it.

Instead of "Use "silent yes" to disable this message.", perhaps say "/msg *route_replies silent yes" or "Respond to this message with "silent yes"

Using this method to add user list:
adduser USER_NICK * #channel #channel

But then it gives everyone voice who enter channel.
It's my folt would be or autovoice plugin?

There is faulty code in the new TrimBuffer method invoked when the buffer size is shunk.

On lines 535-537:

if (m_vsBuffer.size() > uMax) {
    m_vsBuffer.erase(m_vsBuffer.begin(), m_vsBuffer.begin() + (uMax - m_vsBuffer.size()));
}

The code first checks to see if the buffer size is larger than the max allowed size. It then proceeds to erase from the beginning of the buffer to an offset, calculated by subtracting the larger, old buffer size from the smaller, new buffer size. As this is done with STL iterators, the operation is not quite defined, and the behavior while attempting to erase from the beginning of the vector to an iterator which points to a element before the beginning of the vector is most likely causing a segmentation fault.

To fix, one could simply reverse the order of operands in the subtraction. Trimming the first (oldlen - newlen) elements will result in an accurate new buffer size.

Introduced in: f6113b3

Many clients are having problems with partyline using ~#channels (for example: IRSSI, WeeChat, Yaaic). Messages send to those channels appear as private messages to those clients. This is a problem with mobile IRC clients which vibrate on private messages.

We tested changing partyline to use &#channels and all messages sent to partyline appeared normally to channel. This is because most (if not all) clients hardcode & to CHANTYPES (or something what the server sends).

znc --check-config

This will load the config file, parse it and check if it has any errors.

Hi.

Please add a way to send signals to running commands.
For example when you do ping www.google.com there's no way to terminate it. Only killall ping.

Thanks.

I recently tried to install ZNC (thru homebrew) on OS X 10.6.8 and 10.7.1 and receive a Connect Failed. ERRNO [65] FD [5] when ZNC try to connect to the irc server. Below is a transcript of what i am seeing.
I don't know if this is a bug with ZNC or homebrew, but figured i would start at the source.
If there is any other information that might help get to the bottom of this please let me know.

user@gmac ~ $ znc -D
[ ok ] Opening Config [/Users/user/.znc/configs/znc.conf]... 
[ ok ] Loading Global Module [webadmin]... [/usr/local/Cellar/znc/0.200/lib/znc/webadmin.so]
[ ok ] Binding to port [+12345]... 
[ ** ] Loading user [user]
[ ok ] Adding Server [irc.freenode.net 6667 ]... 
[ ok ] Loading Module [chansaver]... [/usr/local/Cellar/znc/0.200/lib/znc/chansaver.so]
[ ok ] Loading Module [keepnick]... [/usr/local/Cellar/znc/0.200/lib/znc/keepnick.so]
[ ok ] Loading Module [kickrejoin]... [/usr/local/Cellar/znc/0.200/lib/znc/kickrejoin.so]
[ ok ] Loading Module [nickserv]... [/usr/local/Cellar/znc/0.200/lib/znc/nickserv.so]
[ ok ] Loading Module [simple_away]... [/usr/local/Cellar/znc/0.200/lib/znc/simple_away.so]
[ ** ] Staying open for debugging [pid: 63305]
[ ** ] ZNC 0.200 - http://znc.in
Connecting user [user]
User [user] is connecting to [irc.freenode.net 6667] ...
Csocket.cpp:886 Connect Failed. ERRNO [65] FD [5]
Csocket.cpp:886 Connect Failed. ERRNO [65] FD [5]
IRC::user == SockError(65 No route to host)
Connecting user [user]
Connecting user [user]
Connecting user [user]
^C[ ** ] Exiting on SIG [2]

Need to have a function like IDontCareAboutLabelsJustGiveMeTheFuckingTimer() to avoid generating unique labels myself

Copy-pasting of logs from IRC (#znc at freenode).

13WAARKUE>Is it expected behaviour that non-admin users can change their idents?
yes
<13WAARKUE> Isn't it possible problem? If some user abuses at some networks and gets K-line (user@host), that user can just change ident.
yeah, that would be a problem in that situation

From the readme.md in this repo:

Installing ZNC

Installation is done with the ./configure ; make ; make install commands.

in my shell on ubuntu 10.04:

git clone git://github.com/znc/znc.git
./configure --help
bash: ./configure: No such file or directory

Pretty much what the title says: A feature to have autoattach only re-attach to a channel if that channel matches a hilight. Useful for channels that are busy, but filled with lots of noise/chatter.

Right now as far as I can tell, autoattach will only reattach when any messages are sent in-channel. So if I'm detached from a channel, I can either be oblivious to everything, or get reattached every time someone wanders in and says "hi" then idles for twelve hours.

A way to only reattach if someone says my nick would be a great improvement.

Thanks!

Can it be implemented with a command /msg *status slowshutdown
that instead of quitting from every network at the same time, znc will slowly quit from each network at a random timer between 1-5 seconds perhaps?

The "watch" module's onQuit handler is missing the Channel.GetName() argument, resulting in all Quit's being relayed to the target window regardless of any channel source filters that are set. As a result, you end up with a target window full of Quit messages from all channels that ZNC is/you're in, mixed in with what's relayed from your actual pattern/source filter.

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

This will completely delete the module datadir for a user, including NV.

/msg *status unloadmod -z nickserv

This could be seen as a "purge" option within the webadmin.

Twice in a row, I have changed a flag or default in the user's profile (first time was enable Append Timestamps, second was changing default Channel Buffer from 0 to 30), and then ZNC disconnects any clients, and deletes any and all networks I had for that user.

This is with the latest git version, pulled today this afternoon.

I have my awaynick set and it works great when I disconnect from znc. However if I disconnect from znc and then znc gets disconnected from IRC...when it reconnects it does not use my awaynick. It would be nice to have znc always use my away nick when I'm disconnected from my znc even after a disconnection from IRC.

This is more so an issue on some mobile clients/device that auto-capitalize the first word. But giving *away a command like "Delete all" will not work for me, but "delete all" will. *status and *admin don't seem to have this issue.

A few people have requested/complained that ZNC doesn't order channels how they wish.

Previously ZNC written its configs differently so that channels were saved in order they were added, I changed it to use CConfig to write the config. This doesn't store them in the same order.

We could implement some kind of index on the channels in the config. This will allow us to read them and place them in the same order as before.

/msg *status movechan #channel <new-index>

The webadmin could also be updated to allow moving channels up/down.

I have created an issue so we can discuss this further and decide if we should implement this, and how.

Related: #89

#52

There are two things which are not yet working:

modtcl
partyline

[19:23:09] @kylef heh lets make a github issue :P
[19:23:23] @kylef everything on the 1.0 milestone needs to be done :p

modtcl is only enabled if --enable-extra is also supplied to ./configure

As I stated in IRC to DarthGandalf @ irc.freenode.net (note that I am Resistance on that IRC network):

Resistance: well i found an on-connect bug in stickychans, specifically if you specify a lot of channels, it'll try to mass join them all at once without taking into account the join rate specified in the ZNC account settings
Resistance: thereby causing excess floods of the ZNC account in question
Resistance: ran into that with a ZNC user on my ZNCs, ended up manually unloading the module from their account, just to prevent the excess flooding

I think that partyline shouldn't require user to be connected to network, because partyline doesn't have anything to do with network where it's connected.

Like new CIRCSock::GetISupport(), for example

It's a way too confusing, for both users and developers...

Just don't allow to remove the last network from user.
If user logins without network, select first one.

Let's imagine the unimaginable. My ZNC gets banned from the IRC (e.g. via a kline). It will now repeatedly reconnect and cause opers to be annoyed by server notices.
Alternatively: Some stupid client is being stupid and ZNC floods off 15 seconds after connecting to the IRC server. Again and again.

It would be nice if we slowed down reconnecting in this case and perhaps preferred other users for now.

STEPS TO REPRODUCE:

1. Clone the ZNC source. (Run autogen.sh if you lack a 'configure'.)
2. Run ./configure in the znc source directory
3. Run "checkinstall --install=no" inside the znc source directory

EXPECTED RESULTS: Checkinstall should complete successfully & spit out a deb
ACTUAL RESULTS: Checkinstall fails while buildling znc, with this message:

 cp -Rp ./webskins /usr/local/share/znc
 cp: preserving times for `/usr/local/share/znc/webskins/dark-clouds/pub': No such file or directory
 cp: preserving times for `/usr/local/share/znc/webskins/dark-clouds/tmpl': No such file or directory
 cp: preserving times for `/usr/local/share/znc/webskins/dark-clouds': No such file or directory
 cp: preserving times for `/usr/local/share/znc/webskins/_default_/pub': No such file or directory
 cp: preserving times for `/usr/local/share/znc/webskins/_default_/tmpl': No such file or directory
 cp: preserving times for `/usr/local/share/znc/webskins/_default_': No such file or directory
 cp: preserving times for `/usr/local/share/znc/webskins/forest/pub': No such file or directory
 cp: preserving times for `/usr/local/share/znc/webskins/forest/tmpl': No such file or directory
 cp: preserving times for `/usr/local/share/znc/webskins/forest': No such file or directory
 cp: preserving times for `/usr/local/share/znc/webskins/ice/pub': No such file or directory
 cp: preserving times for `/usr/local/share/znc/webskins/ice/tmpl': No such file or directory
 cp: preserving times for `/usr/local/share/znc/webskins/ice': No such file or directory
 cp: preserving times for `/usr/local/share/znc/webskins': No such file or directory
 make: *** [install] Error 1
 
 ****  Installation failed. Aborting package creation.

Currently if you, for example, specify ~/.oidentd.conf as a path to .oidentd.conf (which is the default setting btw) this will fail. ZNC requires full paths, like /home/user/.oidentd.conf.