| 1 |
adx |
30 |
Overview of the TS5 system |
| 2 |
|
|
Lee H <lee@leeh.co.uk> |
| 3 |
|
|
|
| 4 |
knight |
31 |
$Id$ |
| 5 |
adx |
30 |
|
| 6 |
|
|
For the purposes of this document, ircd versions: |
| 7 |
|
|
hybrid6.0 |
| 8 |
|
|
ircd-comstud-1.12 |
| 9 |
|
|
CSr31pl4 |
| 10 |
|
|
|
| 11 |
|
|
and prior, are TS3. |
| 12 |
|
|
|
| 13 |
|
|
ircd-hybrid-6.2 and later support TS5. |
| 14 |
|
|
|
| 15 |
|
|
Whats TS5? |
| 16 |
|
|
---------- |
| 17 |
|
|
|
| 18 |
|
|
The difference between TS5 and TS3 is what happened on opless channels. TS |
| 19 |
|
|
works by establishing which server has the oldest version of the channel, |
| 20 |
|
|
the version that is oldest, keeps its modes and ops, the version that is |
| 21 |
|
|
youngest, removes their modes and ops, and accepts the older version. |
| 22 |
|
|
|
| 23 |
|
|
There was an exception to this rule with opless channels, if a channel was |
| 24 |
|
|
opless, TS3 would allow anybody to keep their ops and modes on the channel. |
| 25 |
|
|
TS5 aims to stop this, by removing this exception. |
| 26 |
|
|
|
| 27 |
|
|
Example1: |
| 28 |
|
|
|
| 29 |
|
|
An irc network, with server A (every server is ts3) |
| 30 |
|
|
|
| 31 |
|
|
UserA is on ServerA, in channel #broken. This channel is opless, and has a |
| 32 |
|
|
TS of 800000000. ServerA splits, and whilst it is split, UserA cycles |
| 33 |
|
|
channel #broken, recreates the channel and is given ops. On ServerA #broken |
| 34 |
|
|
now has a TS of 900000000 and has ops. ServerA rejoins with the network, |
| 35 |
|
|
via HubB. HubB realises #broken is opless, so allows UserA to retain ops. |
| 36 |
|
|
The TS is moved forward to 900000000. |
| 37 |
|
|
|
| 38 |
|
|
The network now sees #broken as having a TS of 900000000, with UserA being |
| 39 |
|
|
opped. |
| 40 |
|
|
|
| 41 |
|
|
Example2: |
| 42 |
|
|
|
| 43 |
|
|
An irc network, with server C (every server is ts5) |
| 44 |
|
|
|
| 45 |
|
|
Same scenario as above. ServerC splits and UserC cycles channel #broken, |
| 46 |
|
|
recreating it with a TS of 900000000. ServerC rejoins with the network via |
| 47 |
|
|
HubD. HubD realises #broken has a TS of 800000000 locally, and ServerC is |
| 48 |
|
|
showing a TS of 900000000, it ignores ServerC's modes and ops. The channel |
| 49 |
|
|
remains opless. ServerC receives HubD's modes, and it notices HubD has a |
| 50 |
|
|
lower TS of channel #broken. It removes UserC's ops, removes the channel |
| 51 |
|
|
modes on #broken, and accepts HubD's status. |
| 52 |
|
|
|
| 53 |
|
|
The network version of #broken hasnt changed. It is still opless, with a TS |
| 54 |
|
|
of 800000000. |
| 55 |
|
|
|
| 56 |
|
|
|
| 57 |
|
|
As you can see, TS5 makes splitting a server to regain ops useless, as it |
| 58 |
|
|
cannot be abused to give ops after a netsplit. |
| 59 |
|
|
|
| 60 |
|
|
The problem with TS5 however, is what happens on a mixed TS5/TS3 network. |
| 61 |
|
|
Channels where the older TS has ops will behave the same way on TS5 and TS3, |
| 62 |
|
|
however an opless channel will behave differently, as you can see above. |
| 63 |
|
|
|
| 64 |
|
|
The result of TS5/TS3 mixed can be a desync: |
| 65 |
|
|
|
| 66 |
|
|
Example1: |
| 67 |
|
|
|
| 68 |
|
|
As per Example1 above, except the rest of the network is TS5, ServerA is |
| 69 |
|
|
TS3. ServerA would keep its modes and ops, whilst the rest of the network |
| 70 |
|
|
would remove them. This means only ServerA would see UserA as opped. The |
| 71 |
|
|
desync can be abused, as UserA can send modes. Hybrid6.0 servers will |
| 72 |
|
|
accept these modes from the unopped client, so if UserA ops UserB, who then |
| 73 |
|
|
ops UserA, the channel will be the same across all Hybrid6.0 and Hybrid6.1 |
| 74 |
|
|
servers. |
| 75 |
|
|
|
| 76 |
|
|
Example2: |
| 77 |
|
|
|
| 78 |
|
|
As per Example2 above, except the rest of the network is TS3. ServerC is |
| 79 |
|
|
TS5. ServerC would remove its modes and ops, therefore UserC would not be |
| 80 |
|
|
opped on ServerC, therefore it could not send any mode changes to the |
| 81 |
|
|
channel. Although it is opped elsewhere, it isnt opped locally, so the |
| 82 |
|
|
desync cannot be abused. |
| 83 |
|
|
|
| 84 |
|
|
As you can see, the desync's that can occur can either be resynced, or are |
| 85 |
|
|
useless to the user, so a mixed TS5/TS3 network is not a huge problem, |
| 86 |
|
|
although a desync is NOT a good thing to have. |
| 87 |
|
|
|
| 88 |
|
|
|
| 89 |
|
|
Why TS5? |
| 90 |
|
|
-------- |
| 91 |
|
|
|
| 92 |
|
|
We have jumped to TS5 from TS3, because there was a version of ircd that was |
| 93 |
|
|
TS4, so it was thought better to avoid a clash with an existing version. |
| 94 |
|
|
|
| 95 |
|
|
|
| 96 |
|
|
Advantages |
| 97 |
|
|
---------- |
| 98 |
|
|
|
| 99 |
|
|
It's a realistic event that a server will be attacked so it splits off a |
| 100 |
|
|
network, then used to regain ops in a channel. TS5 makes this pointless, |
| 101 |
|
|
the server will never give ops on a netsplit. TS5 is network wide, so it |
| 102 |
|
|
leaves individual servers free to choose options like NO_JOIN_ON_SPLIT, |
| 103 |
|
|
whilst keeping splits useless to users. |
| 104 |
|
|
|
| 105 |
|
|
|
| 106 |
|
|
Disadvantages |
| 107 |
|
|
------------- |
| 108 |
|
|
|
| 109 |
|
|
It's virtually impossible for a user to actively regain ops themselves (some |
| 110 |
|
|
regard this as an advantage..) because on a large sized channel, its |
| 111 |
|
|
impossible to get people to leave so it can be recreated, therefore if a |
| 112 |
|
|
network did not have some form of services, it could possibly end up |
| 113 |
|
|
requiring oper intervention, as you cant get everybody to leave, and you |
| 114 |
|
|
cant use splits to regain ops, therefore if the channel is open (an |
| 115 |
|
|
invite-only channel would gradually destroy itself as noone new can join) it |
| 116 |
|
|
could be impossible for a user to regain ops. |
| 117 |
|
|
|
| 118 |
|
|
On a network that has some form of services, The effect of TS5 would be |
| 119 |
|
|
minimal, however the services must be of sufficient quality to fix opless |
| 120 |
|
|
channels, as TS5 renders netsplits for ops worthless. |
| 121 |
|
|
|
| 122 |
|
|
|
| 123 |
|
|
Recommendations |
| 124 |
|
|
--------------- |
| 125 |
|
|
|
| 126 |
|
|
If your network has good stable services, we recommend TS5 is enabled, as |
| 127 |
|
|
people have no reason to abuse netsplits anyway. |
| 128 |
|
|
|
| 129 |
|
|
If your network has no services at all, then TS5 may cause problems with |
| 130 |
|
|
users being left with a permanently opless channel. |
| 131 |
|
|
|
| 132 |
|
|
If your network occupies the middle ground, then its a choice between users |
| 133 |
|
|
needing to be able to use splits to regain ops, or making netsplits that are |
| 134 |
|
|
caused to regain ops worthless. |
| 135 |
|
|
|
| 136 |
|
|
If TS5 is chosen, the FULL network must upgrade and this should be done in a |
| 137 |
|
|
relatively short space of time to minimise the possible desync effects. |
| 138 |
|
|
|
| 139 |
|
|
|
| 140 |
|
|
Alternatives |
| 141 |
|
|
------------ |
| 142 |
|
|
|
| 143 |
|
|
There is also NO_JOIN_ON_SPLIT and NO_OP_ON_SPLIT, however these use the |
| 144 |
|
|
configuration of minimum servers and users, and sometimes a split that is |
| 145 |
|
|
above these limits is enough to be abused to regain ops, whereas if the |
| 146 |
|
|
limits are too high, clients will never be able to join anything or be opped |
| 147 |
|
|
when they create a channel. |