Linked Server Hides User Hostmasks?

[qinvictus]

Good evening,

First and foremost, I'll preface this by saying that I'm new to the ircd scene, so bear with me if I am using improper terminology, or what not in this question.

I am working with a team to develop a perl bot which connects to our unrealircd instance as a linked server. For testing purposes, we are scanning each line from the connection stream and writing it to the console so we can see the raw text that is being parsed as it comes through the socket. We would like to see user host mask details for activities so we can tie them to a more unique identifier rather than tracking by nickname.

This bot connects to the instance using the following commands:

Code: Select all

PROTOCTL TKLEXT NICKv2 SJ3 VHP
PASS :somepassword
SERVER services.ourserver.com 1 :Service Monitor
ES

And finally, once connected, it issues the following:

Code: Select all

:services.ourserver.com NICK BotServ 1 1247892827 BotServ Bot.Services.Domain services.ourserver.com 0 :Bot Serv BotServ

The problem that we are seeing is that when text comes across the stream to the bot, all we see for user activity is the nickname:

Code: Select all

:Invictus PRIVMSG #channel :hello world

If I connect the bot as a regular user instead of the using the server negotiation sequence above, I see:

Code: Select all

:[email protected] PRIVMSG  #channel :hello world

The crux of the problem is that we have functionality in the Perl script to execute actions based on a unique user ID -- so I need to be able to see the [email protected] when an activity is performed. I've scanned up and down the documentation and configuration file, etc. and cannot find anything that clues me in to why in linked server mode the hostmask is hidden. Part of the problem may very well be that I don't know precisely what this kind of setting (if there is one) would be called, and so I am here asking for your help in pointing me in the right direction.

I've pasted this snippet below from our links.conf file, if it helps:

Code: Select all

link            services.ourserver.com
{
        username        *;
        hostname        <server ip>;
        bind-ip         <server ip>;
        port            8067;
        hub             *;
        password-connect "somepassword";
        password-receive "somepassword";
        class           servers;
                options {
                        /* Note: You should not use autoconnect when linking services */
#                       autoconnect;
#                       ssl;
#                       zip;
                };
};

I appreciate any help that you can offer.

Thanks,
Invictus

[katsklaw]

Naturally my first question would be, Why does your bot need to connect as a server? It's my experience that not only is the client protocol easier to work with than the ircd protocol, but unless you really have a reason to be a server on a network, it's generally best to be a client instead.

Secondly, other servers on the network know a users IP/host, so it's possible that you haven't watched the raw text at the right time to see the userhost being sent, which seems to be different than with the client protocol.

There are also resources shipped with Unreal that may help.

doc/technical/protocol.txt
doc/technical/serverprotocol.html

[Jobe]

As katsklaw said it is entirely possible the servers ommit sending ident and host with the message to save bandwidth for server to serverr traffic, as servers are told, when a user connects, what that users hostname, ip etc.. are, and what they are when they change.

When writing a service that connects as a server you will NEED to keep track of all this information in your code yourself, but when youre writing a bot that connects as a user, youll generally have this sort of information sent with each message.

[qinvictus]

Thank you both for your replies. We were trying to create the bot in a quasi-ChanServ/AuthServ manner, but I suppose as long as don't lose any capabilities as a client rather than a server, we'd be okay.

It sounds like from what I'm hearing that it's just the nature of it being connected as a server, that it isn't a setting anywhere. I looked at the tech docs you suggested katsklaw, and unless I'm missing something, none of the options parameters would have an impact on this. But thank you for pointing me there, it was good to know what the other choices are.

Seems like at this point we have a few options:

1. Continue with the linked server approach and manually track the user through nickchanges, splits, etc. Sounds like this can get really hairy and prone to inconsistencies, unless there's a proven approach to doing this. Security is paramount in our implementation, so we can't leave any room for users to impersonate each other through glitches in the system -- so this approach is a little risky, it seems.
2. Do what katsklaw suggested and use the client protocol instead. We would still like for the bot to superuser privileges, and its hostmask hidden, but I will scan through the documentation to figure out this part -- I remember seeing some stuff on it, so it sounds feasible.
3. Look into leveraging ircd's module support to do this instead, or build off a 3rd-party authserv/chanserv.

I'll take this info back to the team and we'll try to evaluate the best approach. Given the ubiquity of ChanServ type services, is there a generally accepted best-practice for implementing it? Does it follow from one of the three options above, or possibly another method?

Thank you again for your help.

[katsklaw]

Servers have to tell each other of their users, including their hosts. Where Jobe was going is that unlike the client protocol, the host name is not included on every message. The host must be sent when added or changed. So when the ircd introduces new users, the host must be there or the other servers wouldn't know that information either. The ircds also track vhosts as well.

Services packages can track nicks so there shouldn't be any reason you can't. Unfortunately the tracking is only as good as the ircd allows. Case in point is if you track by nick, that ID is subject to change so you have to be more diligent about it. Whereas if the ircd uses a UID or other type of token to identify users that doesn't change, Unreal however does the former.

You may be interested in 3.1 NICK - User Introduction and Nick Change (TOKEN: &) in the serverprotocol.html where is explains not only the syntax including the users host and vhost but explains the difference between each command.

[qinvictus]

Thank you katsklaw, that is very helpful information. I appreciate all the help, again.

Best regards,
Invictus