View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001674 | unreal | documentation | public | 2004-03-21 21:21 | 2004-04-07 18:23 |
| Reporter | fez | Assigned To | |||
| Priority | normal | Severity | feature | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Platform | x86 | OS | Linux | OS Version | 2.4.x |
| Summary | 0001674: autoconnect | ||||
| Description | I SERIOUSLY suggest that you add a note to example.conf, right around the link block, that says something like: # NOTE: you should NOT put services on autoconnect unless # you are POSITIVE that your services package actually # listens for remote connections (99.9% do NOT). # otherwise autoconnecting will either make the ircd try to # connect to some place that isn't listening, or (as in many # cases), to itself. -- fez | ||||
| Steps To Reproduce | I can't tell you how many idiots come into #unreal-support wondering asking why they get messages like waa waa i get this message Link denied for irc.iamstupid.com([email protected]) (N link block named 'irc.iamstupid.com') [@127.0.0.1.1000] | ||||
| Tags | No tags attached. | ||||
| 3rd party modules | |||||
|
|
How can it connect to itself?! [edit: removed "colour"] edited on: 2004-03-21 23:12 |
|
|
I see you are one of such people, w00t. Think about it. Many people link services on 127.0.0.1 port 6667. If the ircd is set to autoconnect services, it will try to connect to 127.0.0.1:6667 and who will answer? itself... Doesn't take a genius |
|
|
Hmm no. We run services on a seperate machine, on a seperate port that DOESNT have a clients connect. Therefore, I didnt think of the issue. This would be another reason for an unofficial Unreal documentation project. With me, fez? |
|
|
:/ whoopsies... /me actually did this the other day... /me turns red fez, this just made it into UUDP. |
|
|
perhaps change the wording from "(as in many cases)" to "(if services are on localhost)" |
|
|
Not just localhost... even if using 127.0.0.1 in link {} and server ip (222.222.22 blah) in the services conf :/ on the same machine? Hmm... Anyhow ill add it. |
|
|
Actually fez, Shouldnt it be in all cases? As, even if they are on a remote machine, they will connect to the IRCd not vice versa. All that autoconnect would do in a services link block is give out loads of server notices... Right? |
|
|
w00t, there are some, a very small number, of services packages that do allow autoconnect to work. Why do this, I really don't know, but some services do support it. |
|
|
Why do this? Using services as hub is a pretty good way to setup your network. This way if the services go down, all your servers basically split away from each other, and it's harder for hackers to nick-collide you off. And if nick collisions do occur during relinking, the services can use SVSNICK instead of KILL to handle it! Plus, serverops can be easily rejected. Having a U-Line'd server that's able handle the otherwise everyday agony of nick-collides and serverops seems to be a good reason to have services that support autoconnect. Of course, some services *coughauspicecough* don't even handle nickcollides as a leaf. As an example, I once logged in as NickServ (overriding the ban nick), and connected auspice, and it panicked + segfaulted. Haven't tried it with Anope yet. |
|
|
hmmm but the services must support all new feautures and new commands... if any new version of irc deamon are published they must be upgrade there services package or services will continue to send ANY command to the linked servers.... |
|
|
aquanight, again you show you don't know what you're talking about. Just because the services support autoconnect doesn't mean it acts as a hub! It can still link to only 1 server. And using it as a hub is the dumbest thing I've ever heard. Do you want to type /ns identify and have to wait 3 minutes to get a response? Because that's what you're idea would cause. |
|
|
Lol. It's simple really. Read your IRCD/Services manual/documentation like you are supposed to, and you won't have any problems :) This is not an UnrealIRCD issue, nor a configuration/documentation issue, instead a User issue. It's simple really. |
|
|
>Just because the services support autoconnect doesn't mean it acts as a hub! It can still link to only 1 server. As of right now... but there is the possibility that someone could write services that support that... :) >And using it as a hub is the dumbest thing I've ever heard. Maybe, but then again, that's up to the net admins... >Do you want to type /ns identify and have to wait 3 minutes to get a response? Because that's what you're idea would cause. Would it be any different than the services connected to a normal hub? If the services are designed for the load, I'm sure they could handle it. It's hard to say what could happen if the services are used as a hub because no one has ever written a services daemon that works as a hub. I guess once someone does it, we'll see what happens :). |
|
|
In either case, it's not an UnrealIRCD issue and should be closed :) |
|
|
Would it be any different than the services connected to a normal hub? If the services are designed for the load, I'm sure they could handle it. ------ It would be very different, and it has nothing to do with services handling the load. Right now, the only PRIVMSG commands services receives are those directly addressed to one of its bots (NickServ, ChanServ, etc.) If Services was a hub, it would receive PRIVMSGs for EVERY user on the network. We're talking a hundred fold increase in bandwidth consumption here. It has nothing to do with whether the services are designed to handle it, it has to do with, does the average IRC user have enough money to purchase a dedicated line to run their services. And I think the answer is a resounding "no." In either case, it's not an UnrealIRCD issue and should be closed :) ----- I don't think anyone was ever saying it was an Unreal issue, merely something we should point out to prevent problems. Just because the problem doesn't lie in our software doesn't mean we should do nothing to stop it. |
|
|
... aquanight: you think someone will make hubable services? think about it... in other words, make a server that relays messages, and has services, but doesn't allow client connections? sounds pretty retarded. It would have to have all the complexity of an IRCd without actually allowing users. Might as well go all the way and have it be an IRCd with services built-in... Hmm... sounds like ConferenceRoom, no? We all know how great conferenceroom is... -- fez |
|
|
>in other words, make a server that relays messages, and has services, but doesn't allow client connections? Do you *really* want users connecting from the same server as services? :P Servers are one thing, but clients? Now that _would_ seriously slow down the services. Plus, Having clients connect that way would really mess up the SVS* commands. And so would having a service hub... Oh well. edited on: 2004-04-06 12:44 |
|
|
Added in .2212 |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2004-03-21 21:21 | fez | New Issue | |
| 2004-03-21 23:11 | w00t | Note Added: 0005567 | |
| 2004-03-21 23:12 | w00t | Note Edited: 0005567 | |
| 2004-03-21 23:14 | fez | Note Added: 0005568 | |
| 2004-03-21 23:16 | w00t | Note Added: 0005569 | |
| 2004-03-28 19:05 | w00t | Note Added: 0005642 | |
| 2004-03-28 19:13 | fez | Note Added: 0005643 | |
| 2004-03-28 19:20 | w00t | Note Added: 0005645 | |
| 2004-03-30 21:51 | w00t | Note Added: 0005689 | |
| 2004-03-31 17:47 |
|
Note Added: 0005697 | |
| 2004-04-01 09:42 | aquanight | Note Added: 0005705 | |
| 2004-04-03 06:05 | diskman1 | Note Added: 0005717 | |
| 2004-04-03 11:52 |
|
Note Added: 0005723 | |
| 2004-04-03 13:25 | ravenflx | Note Added: 0005729 | |
| 2004-04-05 13:39 | aquanight | Note Added: 0005743 | |
| 2004-04-05 22:03 | ravenflx | Note Added: 0005746 | |
| 2004-04-05 23:01 |
|
Note Added: 0005747 | |
| 2004-04-06 00:46 | fez | Note Added: 0005749 | |
| 2004-04-06 12:43 | aquanight | Note Added: 0005751 | |
| 2004-04-06 12:44 | aquanight | Note Edited: 0005751 | |
| 2004-04-07 18:23 |
|
Status | new => resolved |
| 2004-04-07 18:23 |
|
Resolution | open => fixed |
| 2004-04-07 18:23 |
|
Assigned To | => codemastr |
| 2004-04-07 18:23 |
|
Note Added: 0005778 |
