View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001448 | unreal | ircd | public | 2003-12-23 22:58 | 2004-02-03 21:18 |
| Reporter | Cnils | Assigned To | |||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | closed | Resolution | reopened | ||
| Product Version | 3.2-beta18 | ||||
| Summary | 0001448: Glines made during a split is not reported to the re-connecting server | ||||
| Description | If a gline is made while a server is not connected, it won't be made aware of the event when it connects to the net again. | ||||
| Steps To Reproduce | Place a gline while a server is squited. Connect it again. Have the glined client connect to the formerly disconnected server. | ||||
| Additional Information | I haven't made any specific tests on this. The evidence I have is from our autoleech killing script in action. When glined clients were able to reconnect I found that this could be the only reasonable explanation. | ||||
| 3rd party modules | |||||
|
|
That may be the "only reasonable explanation" however it is "completely lacking a foundation and merit." Please don't report speculation with no evidence. If you had actually tested your claim, you would have seen that in fact you were wrong, glines are synched just fine. If you actually have some real information about the cause of your problem, then please report it, otherwise I'll be closing this bug report. |
|
|
As I said, my evidense is that users can connect to the server that was split when the gline was made. I haven't made any tests because I need a user I can communicate with online while beeing glined on our net. If you don't convince me otherwise, I will do some tests after christmas. edited on: 12-23-03 23:24 |
|
|
Well then in that case I'll be closing the bug reports. What you have said doesn't prove anything at all. If you can provide real evidence, then please do submit it. But as I said, the Gline (or rather then entire TKL system) is working fine. I added 50 glines and 20 zlines, linked a new server and it was made aware of all 70 bans. |
|
|
More info The synching between servers seems to be wrong when a gline is first removed and then readded during a split. In my case services had an akill that expired during a split. The gline was removed (services akill is using glines as the ban method). Then the client could connect again, and got a new gline (akill). After the split server connected again, the user can connect to that server. stats G on that server doesn't show the user either, while all other servers does. |
|
|
Not sure if it's relevant, but it's better to ask than to ignore the thought (like I usually do)... What's the output of "/TSCTL ALLTIME"? (with the server-with-the-problem linked ;p). Mark the bugnote as 'prive' in case you consider that sensitive information (I don't ;p). |
|
|
[10:15:09] -irc2.scifi-fans.net- *** Server=irc2.scifi-fans.net TStime=1072257281 time()=1072257281 TSoffset=0 [10:15:09] -earth.scifi-fans.net- *** Server=earth.scifi-fans.net TStime=1072257358 time()=1072257358 TSoffset=0 [10:15:09] -irc4.scifi-fans.net- *** Server=irc4.scifi-fans.net TStime=1072257281 time()=1072257281 TSoffset=0 [10:15:10] -irc1.scifi-fans.net- *** Server=irc1.scifi-fans.net TStime=1072257421 time()=1072257421 TSoffset=0 [10:15:11] -hub.us.scifi-fans.net- *** Server=hub.us.scifi-fans.net TStime=1072257345 time()=1072257347 TSoffset=0 [10:15:11] -hub.eu.scifi-fans.net- *** Server=hub.eu.scifi-fans.net TStime=1072257277 time()=1072257282 TSoffset=0 [10:15:11] -irc7.scifi-fans.net- *** Server=irc7.scifi-fans.net TStime=1072257357 time()=1072257358 TSoffset=0 |
|
|
assuming the gline (akill) has an expire time of >10 minutes (which is usually the case ;p) the difference in time doesn't seem to be the problem. What kind of gline/akill gets added (or even better, the raw line)? Perhaps it will help us with testing (although you already pointed out it was perhaps expire+readd-during-split). [I'll have christmas evening bla stuff now, but... :p] |
|
|
They are all similar to this one, earth.scifi-fans.net PRIVMSG operserv :akill add +5d *sierra09@*.dyn.optonline.net You are a leechbot. Scifi-Net don't allow leechbots. Goodbye <sierra09> Services the adds glines like this, :earth.scifi-fans.net NOTICE Cnils :*** G:Line added for *sierra09@*.dyn.optonline.net on Wed Dec 24 22:35:40 2003 GMT (from Cnils to expire at Fri Dec 26 22:39:41 2003 GMT: [Cnils] You are.... You may wonder why the expire times differ, but that's just Anopes way of dealing with it. It places a shorter gline and just re-add it if needed. This makes my reported bug to be even more likely to happen with the 600 to 800 active akills we have at any time. Merry Christmas to you all :) |
|
|
I checked the source regarding synching of tkl data. My conclusion is that the synch is not made on the glines made during a split IF an tkl entry already exists for that hostname. That is normally ok, since it's most likely the same gline. But if it's a new gline with a new expiry time, the new expiry time is going to be ignored (as well as a changed reason or setter) |
|
|
Hmm I'm not looking at the code right now, but I think you might be right. |
|
|
was this fixed? (else I could take a look, after the spamfilter stuff I know the TKL code pretty well ;p) |
|
|
I don't believe it was fixed, no. |
|
|
will commit a fix in the next 24h. |
|
|
Should now be fixed in .2071. - Fixed issue when 2 servers link with identical user@host *:lines but with different expire times, reason field, etc... Entries are now fully synced between servers. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2003-12-23 22:58 | Cnils | New Issue | |
| 2003-12-23 23:09 |
|
Note Added: 0004420 | |
| 2003-12-23 23:20 | Cnils | Note Added: 0004421 | |
| 2003-12-23 23:24 | Cnils | Note Edited: 0004421 | |
| 2003-12-23 23:34 |
|
Status | new => closed |
| 2003-12-23 23:34 |
|
Note Added: 0004422 | |
| 2003-12-24 00:18 | Cnils | Status | closed => feedback |
| 2003-12-24 00:18 | Cnils | Resolution | open => reopened |
| 2003-12-24 00:18 | Cnils | Note Added: 0004423 | |
| 2003-12-24 04:29 | syzop | Note Added: 0004424 | |
| 2003-12-24 09:14 | Cnils | Note Added: 0004425 | |
| 2003-12-24 15:02 | syzop | Note Added: 0004426 | |
| 2003-12-24 22:50 | Cnils | Note Added: 0004429 | |
| 2003-12-24 23:41 | Cnils | Note Added: 0004430 | |
| 2003-12-25 01:36 |
|
Note Added: 0004432 | |
| 2004-01-30 03:09 | syzop | Note Added: 0004789 | |
| 2004-01-30 16:41 |
|
Note Added: 0004797 | |
| 2004-02-03 01:36 | syzop | Note Added: 0004852 | |
| 2004-02-03 21:18 | syzop | Status | feedback => closed |
| 2004-02-03 21:18 | syzop | Note Added: 0004861 |
