|
|
| Author |
Message |
darkwarrior
Lurker
Joined: 02 Aug 2008
Posts: 172
|
 Posted: Oct 19, 2008 1:30pm Post subject: Problems with ircu2.10.12.10 and later versions? |
 |
|
Hey folks, I am having a bit of an issue with ircu, and well, in fact, its been this way for quite some time. First of all, I am using ircu2.10.12.10, configured with the fakehosts patch. The problem with it is, for some reason, it doesn't want to use real host names (ie: *.blah.isp.com) for users, and instead, every user's hostmask is *@ip.address, using their numerical ip.
I have duplicated the ircd to a different machine, with the same ircd.conf file and same patch and everything, and it worked fine and resolved their IP addresses.
I eventually tried recompiling once again on the same machine as the one with problems, but to a different directory instead, and of course, using the same ircd.conf and patch as well. It resolved hosts for the first few connection attempts or for the first day or so, and then from that point on, it stopped resolving them, even for those same users who were resolved on their first connect.
It appears that this same issue is happening to me with ircu2.10.12.12 as well. Is there any ircu gurus out there that might know whats up here? |
|
| Back to top |
|
 |
PingBad
Guru
Joined: 05 Feb 2005
Posts: 2098
Location: New Zealand
|
| Posted: Oct 19, 2008 1:52pm Post subject: |
|
|
| It's not specifically the IRCd that handles the IP <-> Named Host resolution, but actually the DNS server configured in the box's network configuration, so that would be my first target (fair chance that there is no DNS address configured on the box, or that the ip address listed no longer works (read: DNS server went elsewhere, and not every box was updated with the new changes), or your DNS server isn't properly configured) |
|
| Back to top |
|
|
darkwarrior
Lurker
Joined: 02 Aug 2008
Posts: 172
|
| Posted: Oct 19, 2008 2:27pm Post subject: |
|
|
| Any idea how it can be properly configured? Also, why does recompiling it work for just a little while, like the first few hours, then afterwards stops working? I've also had no problems from any other ircd on the same box, they all work completely fine it seems. Perhaps it could be an ircd.conf problem? |
|
| Back to top |
|
|
mouselike
Idler
Joined: 09 Dec 2003
Posts: 271
|
| Posted: Oct 19, 2008 4:20pm Post subject: |
|
|
the ircd should (and is by default) be told to use /etc/resolv.conf for the ip of the nameservers for lookups. If this doesnt exist or been setup then you arnt going to get hostname resolve's.
Look for this at the bottom of your ircd.conf in the features and change it to this with the #
| Code: | | # "DOMAINNAME"="<obtained from /etc/resolv.conf by ./configure>"; |
Also I will draw your attention to these and possibly make sure they arnt comented out, or you can increase them to a higher figure but bare in mind connections will take a considerable amount longer but will give the nameserver time to lookup.
| Code: | "IRCD_RES_TIMEOUT" = "4";
"IRCD_RES_RETRIES" = "2";
"AUTH_TIMEOUT" = "9"; |
Failing that make sure that the nameservers you have set are ones you are authorised to use as some hosts restrict access for clients to their own local traffic unlike servers where they need to share access. |
|
| Back to top |
|
|
darkwarrior
Lurker
Joined: 02 Aug 2008
Posts: 172
|
| Posted: Oct 19, 2008 4:39pm Post subject: |
|
|
Hi mouselike, thank you for that information. After carefully reviewing the config.h file in the source of the ircd, I noticed the following line:
/* Domain name to be used for some statistics gathering */
#define DOMAINNAME "*"
Apparently, when running the ./configure command, it never grabbed the domainname. I decided to perform an experiment by figuring out what the nameserver domain was (pico /etc/resolv.conf , did a dns lookup of the IP address listed there, which came to be blah.com, replace blah.com with the actual domain). I then recompiled and included --with-domain in the ./configure as such:
./configure --prefix=/path/to/ircu --with-domain=blah.com and then I copied my ircd.conf and everything back to the appropriate directory, then I fired it up and it now appears to be fixed. I found that the machine which it worked fine on had automatically gathered the domain info on its own, so apparently some machines don't do this. After fixing this problem, connecting no longer hangs for 10-15 seconds, so this was definitely what was causing the hang as well, as it was attempting to lookup hostnames without a proper nameserver being specified, and couldn't find one.
I apologize for not figuring this out prior to posting, as I now feel much more stupid for having posted this and then resolving it afterwards on my own. But hey, hopefully anyone else who has this issue will find this information helpful.
Thank you mouselike and PingBad for some of the information you provided. |
|
| Back to top |
|
|
darkwarrior
Lurker
Joined: 02 Aug 2008
Posts: 172
|
| Posted: Oct 19, 2008 5:03pm Post subject: |
|
|
| Nevermind... Once again as before, it worked fine for about an hour. Now it no longer works correctly, and also hangs again. What's going on with it, grrr!! How can it work for an hour, then just completely stop working.. |
|
| Back to top |
|
|
Nerdanel
none
Joined: 11 Jun 2008
Posts: 21
|
| Posted: Oct 19, 2008 5:10pm Post subject: |
|
|
This is a total shot in the dark, but maybe you are only allowed a certain amount of lookups, or that it only works for a limited time for an outside user?
(yes i post from bed, and yes i love phones that can run java programs.) |
|
| Back to top |
|
|
darkwarrior
Lurker
Joined: 02 Aug 2008
Posts: 172
|
| Posted: Oct 19, 2008 5:23pm Post subject: |
|
|
Ok, actually, it seems to stop working after I do a /rehash ...
I should also mention that every machine that I have ircu running on has an error when rehashing:
-Gravity.CA.US.SleisySoft.net- *** Notice -- bind error for Gravity.CA.US.SleisySoft.net:4400: Can't assign requested address
-ayame.MI.US.SleisySoft.net- *** Notice -- bind error for ayame.MI.US.SleisySoft.net:4400: Can't assign requested address
-Physix.NJ.US.SleisySoft.net- *** Notice -- bind error for Physix.NJ.US.SleisySoft.net:4400: Can't assign requested address
Every single one of those servers are using port 4400 though, as that is the only server port opened, so obviously they have to be assigned.. I did notice though that on Gravity, before the hostnames stopped resolving once again, a rehash was done with the same error.
So, with that said, could that error have something to do with it perhaps? |
|
| Back to top |
|
|
darkwarrior
Lurker
Joined: 02 Aug 2008
Posts: 172
|
| Posted: Oct 19, 2008 5:52pm Post subject: |
|
|
Ok, I have confirmed for sure that it is the /rehash that causes it to stop working correctly. A /restart makes it work correctly up until I do a /rehash ... So, is there anyway that someone could possibly point out what the problem may be? Allow me to post my ircd.conf
Here:
| Code: |
General {
name = "Gravity.CA.US.SleisySoft.net";
description = "Los Angeles, CA - SleisySoft Network";
vhost = "69.42.221.201";
numeric = 3;
};
Admin {
# At most two location lines are allowed...
Location = "DarkWarrior - darkw@sleisysoft.net";
Location = "SleisySoft Network - Ohio - USA";
Contact = "DarkWarrior - darkw@sleisysoft.net";
};
Class {
name = "Server";
pingfreq = 1 minutes 30 seconds;
connectfreq = 5 minutes;
maxlinks = 10;
sendq = 9000000;
};
Class {
name = "LeafServer";
pingfreq = 1 minutes 30 seconds;
connectfreq = 5 minutes;
maxlinks = 10;
sendq = 9000000;
};
Class {
name = "Local";
pingfreq = 1 minutes 30 seconds;
sendq = 160000;
maxlinks = 1000;
usermode = "+iw";
};
Class {
name = "Other";
pingfreq = 1 minutes 30 seconds;
sendq = 160000;
maxlinks = 1000;
usermode = "+iw";
};
Class {
name = "Opers";
pingfreq = 1 minutes 30 seconds;
sendq = 160000;
maxlinks = 1000;
hide_channels = yes;
hide_idletime = yes;
local = no;
set_fakehost = yes;
};
Client
{
class = "Other";
ip = "*@*";
maxlinks = 1000;
};
Client
{
class = "Other";
host = "*@*";
maxlinks = 1000;
};
Client {
host = "*@*";
ip = "*@*";
class = "Other";
maxlinks = 1000;
};
motd {
host = "*";
file = "ircd.motd";
};
UWorld {
name = "Services.SleisySoft.net";
name = "BotServer.US.SleisySoft.net";
name = "Stats.SleisySoft.net";
};
Jupe {
nick = "ChanSvr,ChanSaver,ChanServ";
nick = "NickSvr,NickSaver,NickServ";
nick = "AuthSvr,AuthSaver,AuthServ";
nick = "AuthSrv,ChanSrv,NickSrv";
nick = "OpServ,OperServ,OpSrv";
nick = "OperSrv";
};
Kill { username = "sub7"; realname = "s*7*"; reason = "You are infected with a Trojan"; };
Kill
{
realname = "*sub7*";
reason = "You are infected with a Trojan";
};
Connect {
name = "Services.SleisySoft.net";
host = "ip.address.here";
password = "password-here";
port = 4400;
class = "Server";
};
Connect {
name = "ayame.MI.US.SleisySoft.net";
host = "64.85.163.50";
password = "password-here";
port = 4400;
class = "Server";
};
Operator {
local = no;
host = "*@ip/host-here";
password = "password-here";
name = "opername-here";
class = "Opers";
};
Port {
vhost = "69.42.221.201";
server = yes;
port = 4400;
};
Port {
vhost = "69.42.221.201";
server = yes;
hidden = yes;
port = ipv4 4401;
};
Port {
vhost = "69.42.221.201";
port = 6667;
};
Port {
vhost = "69.42.221.201";
port = 6668;
};
Port {
vhost = "69.42.221.201";
port = 6669;
};
Port {
vhost = "69.42.221.201";
port = 6666;
};
Port {
vhost = "69.42.221.201";
port = 7000;
};
Pseudo "CHANSERV" {
name = "ChanServ";
nick = "ChanServ@Services.SleisySoft.net";
};
Pseudo "CS" {
name = "ChanServ";
nick = "ChanServ@Services.SleisySoft.net";
};
Pseudo "AS" {
name = "AuthServ";
nick = "AuthServ@Services.SleisySoft.net";
};
Pseudo "AuthServ" {
name = "AuthServ";
# prepend = "LOGIN ";
nick = "AuthServ@Services.SleisySoft.net";
};
Pseudo "MemoServ" {
name = "MemoServ";
nick = "MemoServ@Services.SleisySoft.net";
};
Pseudo "OpServ" {
name = "OpServ";
nick = "OpServ@Services.SleisySoft.net";
};
Pseudo "MS" {
name = "MemoServ";
nick = "MemoServ@Services.SleisySoft.net";
};
Pseudo "Auth" {
name = "AuthServ";
prepend = "auth ";
nick = "AuthServ@Services.SleisySoft.net";
};
Pseudo "Reg" {
name = "AuthServ";
prepend = "register ";
nick = "AuthServ@Services.SleisySoft.net";
};
features
{
"HUB"="TRUE";
"NETWORK"="SleisySoft";
"HOST_HIDING"="TRUE";
"HIDDEN_HOST"="user.sleisysoft";
"MAXCHANNELSPERUSER"="25";
"NICKLEN" = "35";
"MAXBANS"="50";
"GLINEMAXUSERCOUNT" = "100";
"MPATH" = "ircd.motd";
"HIS_MAP" = "TRUE";
"HIS_LINKS" = "FALSE";
"CONNEXIT_NOTICES" = "TRUE";
"HIS_NETSPLIT" = "TRUE";
"HIS_SERVERNAME" = "*.sleisysoft.net";
"HIS_SERVERINFO" = "SleisySoft IRC Network";
"HIS_URLSERVERS" = "http://www.sleisysoft.net/index.php?page=servers";
"URLREG" = "http://www.sleisysoft.net";
};
|
|
|
| Back to top |
|
|
darkwarrior
Lurker
Joined: 02 Aug 2008
Posts: 172
|
| Posted: Oct 19, 2008 6:35pm Post subject: |
|
|
| This is going to be the reason I switch to nefarious if I end up doing so.. |
|
| Back to top |
|
|
mentor
Newbie
Joined: 22 Jun 2004
Posts: 74
Location: San Diego, CA
|
| Posted: Oct 20, 2008 7:41am Post subject: |
|
|
Umm...
F:DOMAINNAME has nothing to do with resolving hosts. It doesn't matter what you specify here. It's only used for statistical purposes only.
If you have F:NODNS specified in your conf, then make sure it is FALSE. Also, you may want to take a look at the server's internal DNS statistics. This can be done by using:
See if anything looks out of the ordinary. You can also try restarting the DNS resolver by using:
However, I suspect your probably lies within /etc/resolv.conf. As someone else pointed out, make sure ALL of the nameservers you have listed are indeed corect. You can contact your provider if you are unsure. If they aren't, it's not going to matter what ircd you use. You'll still have the same problem.
You might also want to make sure a packet filter isn't preventing the ircd from using UDP to query the servers. Try using nslookup using the server ip followed by a domain (e.g. www.searchirc.com) for each nameserver listed to see if they are responding as expected. ircu's resolver, as with most any ircd, is somewhat "dumb." If it gets a negative reply from one server, it will ignore any replies from the others. |
|
| Back to top |
|
|
darkwarrior
Lurker
Joined: 02 Aug 2008
Posts: 172
|
| Posted: Oct 20, 2008 11:15am Post subject: |
|
|
Obviously as the dns worked perfectly every time my IRCd was restarted, up until there was a /rehash performed, that means that my problem was not indeed the machine. As mentioned, all other IRCd's that hosted on the machine did not have this problem.
After getting a bit frustrated, I contacted the undernet coder committee I hate to break it to those of you who love ircu, IRCU is not always perfect or flawless. The undernet coder committee (development team for ircu) informed me that the resolvers in ircu2.10.12.10 are broken and that I will need to use ircu2.10.12.12 where they are fixed.
Unfortunately, I don't wish to use 2.10.12.12 simply because I have not found a fakehosts and opermodes patch available for 2.10.12.12.. I did kind of figure out a work around on this to prevent the requirement to use /rehash to change any settings (o lines, c lines, etc).. My work around is, I have added a staff only server to my network, running on a different port, that all opers will have to connect to in order to oper up. And I have also added a hub server that will be used to hold the c line information, so I don't ever have to /rehash any of the leaf servers to add opers or links. |
|
| Back to top |
|
|
ButtaKnife
none
Joined: 26 Apr 2005
Posts: 38
|
| Posted: Oct 20, 2008 1:25pm Post subject: |
|
|
| darkwarrior wrote: | After getting a bit frustrated, I contacted the undernet coder committee I hate to break it to those of you who love ircu, IRCU is not always perfect or flawless. The undernet coder committee (development team for ircu) informed me that the resolvers in ircu2.10.12.10 are broken and that I will need to use ircu2.10.12.12 where they are fixed.
Unfortunately, I don't wish to use 2.10.12.12 simply because I have not found a fakehosts and opermodes patch available for 2.10.12.12... |
I don't think anyone is under the mistaken impression that ircu is perfect. In any case, I haven't looked at that resolver code, but you may be able to patch your copy of .10 with resolver code from .12. Just a thought.  |
|
| Back to top |
|
|
mentor
Newbie
Joined: 22 Jun 2004
Posts: 74
Location: San Diego, CA
|
| Posted: Oct 20, 2008 3:11pm Post subject: |
|
|
| darkwarrior wrote: | | Obviously as the dns worked perfectly every time my IRCd was restarted, up until there was a /rehash performed, that means that my problem was not indeed the machine. As mentioned, all other IRCd's that hosted on the machine did not have this problem. |
Actually, it is not so obvious, as that could also be an indication it has something to do with /etc/resolv.conf. As is the case 95% - hence just about everyone mentioning it.
Then again, it also could be an indication that it's ircu's resolver -- as you found out. The resolver is rehashed unless the q flag (e.g. /quote rehash q) is specified. I use an older version of ircu. I've customized it so heavily I haven't been bothered to port to .12, so honestly I wouldn't have known about the resolver issue -- thanks for sharing though
| Quote: | After getting a bit frustrated, I contacted the undernet coder committee I hate to break it to those of you who love ircu, IRCU is not always perfect or flawless. The undernet coder committee (development team for ircu) informed me that the resolvers in ircu2.10.12.10 are broken and that I will need to use ircu2.10.12.12 where they are fixed.
Unfortunately, I don't wish to use 2.10.12.12 simply because I have not found a fakehosts and opermodes patch available for 2.10.12.12.. I did kind of figure out a work around on this to prevent the requirement to use /rehash to change any settings (o lines, c lines, etc).. My work around is, I have added a staff only server to my network, running on a different port, that all opers will have to connect to in order to oper up. And I have also added a hub server that will be used to hold the c line information, so I don't ever have to /rehash any of the leaf servers to add opers or links. |
Just curious, but what does the opermodes patch do? |
|
| Back to top |
|
|
darkwarrior
Lurker
Joined: 02 Aug 2008
Posts: 172
|
| Posted: Oct 20, 2008 4:41pm Post subject: |
|
|
| The opermodes patch has 3 extra user modes for opers, if their class has it enabled, that allows them to set themself as a service (+k), one to hide channels in a /whois (+I i think?) and the other to hide idle time. I only went for the opermodes patch for the +k mode for an eggdrop service bot I created (HostServ), as I believe the other two are useless. |
|
| Back to top |
|
|
|
|
| |
Register
Log in
