View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0004890 | unreal | ircd | public | 2017-03-08 01:24 | 2017-03-11 10:54 |
| Reporter | unic0rn | Assigned To | syzop | ||
| Priority | normal | Severity | major | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Product Version | 4.0.11 | ||||
| Fixed in Version | 4.0.12 | ||||
| Summary | 0004890: user info isn't properly propagated across the network | ||||
| Description | server A: linux server B: windows, with anope services linked locally server C: freebsd scenario 1) A-B-C user on A cannot see the vhost of user on C scenario 2) B-C-A user on B cannot see the vhost of user on A no vhosts in whois, privmsg, notice, anything. windows server is 4.0.10, all the rest is 4.0.11, anope services are up to date. | ||||
| Tags | No tags attached. | ||||
| 3rd party modules | |||||
|
|
Last time we had such a report we couldn't reproduce it. So I'm going to ask you before we try again: How do you assign the vhost to the user? What is the exact procedure for us to reproduce it? Perhaps it matters. Thanks! |
|
|
vhosts are assigned using anope's hostserv. as for the procedure, it should be simple - in both of the scenarios above vhosts don't get propagated. for a perfect match, i would say 2 servers running .11 on linux and one running .10 on windows, with current anope running on the windows server and linked to it, has to work - but i doubt that's the only scenario, i just didn't have time nor resources to test it more. try connecting to irc.arloria.net, checking the network topology with map and experimenting with whois or perhaps who (i didn't check who tbh, but if privmsg and whois didn't show vhosts, neither will who) in #welcome on different servers if you wanna see it in action. i'll help with debugging if i can. |
|
|
well, i've figured it out, you shouldn't have problems with tracking it down now. it fails to propagate vhosts for o-lined users only. basically, when oper has vhost set in unrealircd.conf, everything works fine. when oper has vhost set using anope (and no vhost in unrealircd.conf - at least that's the scenario tested), it behaves exactly as described above. for regular users there's no problem. sorry for the confusion, i forgot one of the bots i was whoising, is o-lined as well, so basically i was accidentally checking only o-lined nicks. |
|
|
ok, it's not that clear cut. let me describe the current situation. 1) the bug affects only o-lined users 2) current network setup: A - freebsd, .11 B - windows, .10 + anope C - linux, .11 3) when opered users on A had vhosts defined in anope only, those vhosts weren't visible to regular user on C 4) when opered users on A have vhosts defined in unrealircd.conf only, those vhosts are visible to regular user on C as they should 5) opered users on C have vhosts defined in unrealircd.conf only, yet those are not visible to regular user on A, but are visible to opered user on A i hope that cleans it up a bit. i have access to only one server's config on the network, so my debugging capabilities are limited. |
|
|
some clarifications and corrections: as for 3) and 4), can't check what oper on C sees, noone around. also, scrap 5) from previous note. basically, it's the same both ways - or so i hope. user on C with vhost in unrealircd.conf, has that vhost visible on C but not on A. i've messed up assuming it's visible to opers on A due to using /wii instead of /whois. also, there's one opered bot on C that had vhost before and doesn't have it now, so while i've assumed its vhost is defined in unrealircd.conf, i'll go with a wild guess it's using chghost and somehow failed to use it properly. if its the other way around, i'll find out and let you know. for now, lets assume everything is as described in https://bugs.unrealircd.org/view.php?id=4890#c19677 |
|
|
Thanks for all the tracing! Much appreciated. I'll take a look at it later this week/weekend. |
|
|
no problem. also, sorry for the mess, my sleep patterns recently are screwed up and i obviously jump to conclusions here too much. just figured out one detail i've missed the previous time, which is kinda obvious: "basically, it's the same both ways - or so i hope. user on C with vhost in unrealircd.conf, has that vhost visible on C but not on A." so it's nothing like the same. that vhost is defined in unrealircd.conf - has to be, it's another oper and services have no record of his vhost whatsoever. A - freebsd, .11 B - windows, .10 + anope C - linux, .11 - oper vhosts set using anope for opers on A are invisible on C (bug) - oper vhosts set using ircd.conf for opers on A are visible on C (yay) - oper vhosts set using ircd.conf for opers on C are invisible on A (bug, and WTF?) it makes no goddamn sense. i thought it was a matter of some conflict between propagating the anope-set vhost and opering up (i oper up after identifying with nickserv - didn't check it otherwise, i specify nickserv password as a server password), but now it seems it's something wrong with propagating oper vhosts in general. additional note, i was doing some rerouting that ended up in the above situation and i did reconnect after rerouting (i'm oper on A), while the oper on C did not reconnect, so the different behaviour of his vhost propagation may have something to do with that. sadly, he didn't reconnect automatically after kill so i can't confirm that :) anyway, if you'll have any trouble reproducing any part of it, let me know. |
|
|
heh. another small correction, i oper before identify - should be the other way around, but services are remote so oper kicks in faster, just checked. |
|
|
I can reproduce the following issue and it has to do with synching on link: * server setup A-B-C * link A<->B squits and reconnects * the oper from server A looks ok on server A, on server B, but not on server C. On server C I don't see the vhost but the cloaked hostname (in my case) So I have a lead.. something to work on. |
|
|
Fixed. Thanks for the report! https://github.com/unrealircd/unrealircd/commit/0963cddd28b0e74d270d5d4c9914bb8846762723 commit 0963cddd28b0e74d270d5d4c9914bb8846762723 Author: Bram Matthys <[email protected]> Date: Sat Mar 11 10:50:00 2017 +0100 Vhosts were not synched correctly during linking. Reported by unic0rn (0004890). This was not really noticeable on 2 server networks, but in A-B-C linking setups a vhost of user A would not show on server C. |
|
|
Some more details of behavior prior to the above fix: Note the also the 'xyz is using modes ....' line. * On server B you see it is missing 't' in the modes line but the vhost is still effective nonetheless. * On server C you also see the missing 't' but the vhost is not effective. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2017-03-08 01:24 | unic0rn | New Issue | |
| 2017-03-08 09:06 | syzop | Note Added: 0019674 | |
| 2017-03-08 09:07 | syzop | Note Edited: 0019674 | |
| 2017-03-08 14:30 | unic0rn | Note Added: 0019676 | |
| 2017-03-09 02:11 | unic0rn | Note Added: 0019677 | |
| 2017-03-09 02:45 | unic0rn | Note Added: 0019678 | |
| 2017-03-09 03:04 | unic0rn | Note Added: 0019679 | |
| 2017-03-09 07:34 | syzop | Note Added: 0019680 | |
| 2017-03-09 10:03 | unic0rn | Note Added: 0019681 | |
| 2017-03-09 10:15 | unic0rn | Note Added: 0019682 | |
| 2017-03-11 10:11 | syzop | Assigned To | => syzop |
| 2017-03-11 10:11 | syzop | Status | new => confirmed |
| 2017-03-11 10:11 | syzop | Note Added: 0019684 | |
| 2017-03-11 10:52 | syzop | Status | confirmed => resolved |
| 2017-03-11 10:52 | syzop | Resolution | open => fixed |
| 2017-03-11 10:52 | syzop | Fixed in Version | => 4.0.12 |
| 2017-03-11 10:52 | syzop | Note Added: 0019685 | |
| 2017-03-11 10:54 | syzop | Note Added: 0019686 |
