Removed TS5 description as it is no longer supported
This commit is contained in:
Valery Yatsko
parent
f9d5f40a62
commit
ea3ab4a938
1 changed files with 0 additions and 151 deletions
|
|
@ -1,151 +0,0 @@
|
||||||
Overview of the TS5 system
|
|
||||||
Lee H <lee@leeh.co.uk>
|
|
||||||
|
|
||||||
$Id: ts5.txt 6 2005-09-10 01:02:21Z nenolod $
|
|
||||||
|
|
||||||
For the purposes of this document, ircd versions:
|
|
||||||
hybrid6.0
|
|
||||||
ircd-comstud-1.12
|
|
||||||
CSr31pl4
|
|
||||||
|
|
||||||
and prior, are TS3.
|
|
||||||
|
|
||||||
ircd-hybrid-6.2 and later support TS5.
|
|
||||||
|
|
||||||
|
|
||||||
Whats TS5?
|
|
||||||
----------
|
|
||||||
|
|
||||||
The difference between TS5 and TS3 is what happened on opless channels. TS
|
|
||||||
works by establishing which server has the oldest version of the channel,
|
|
||||||
the version that is oldest, keeps its modes and ops, the version that is
|
|
||||||
youngest, removes their modes and ops, and accepts the older version.
|
|
||||||
|
|
||||||
There was an exception to this rule with opless channels, if a channel was
|
|
||||||
opless, TS3 would allow anybody to keep their ops and modes on the channel.
|
|
||||||
TS5 aims to stop this, by removing this exception.
|
|
||||||
|
|
||||||
Example1:
|
|
||||||
|
|
||||||
An irc network, with server A (every server is ts3)
|
|
||||||
|
|
||||||
UserA is on ServerA, in channel #broken. This channel is opless, and has a
|
|
||||||
TS of 800000000. ServerA splits, and whilst it is split, UserA cycles
|
|
||||||
channel #broken, recreates the channel and is given ops. On ServerA #broken
|
|
||||||
now has a TS of 900000000 and has ops. ServerA rejoins with the network,
|
|
||||||
via HubB. HubB realises #broken is opless, so allows UserA to retain ops.
|
|
||||||
The TS is moved forward to 900000000.
|
|
||||||
|
|
||||||
The network now sees #broken as having a TS of 900000000, with UserA being
|
|
||||||
opped.
|
|
||||||
|
|
||||||
Example2:
|
|
||||||
|
|
||||||
An irc network, with server C (every server is ts5)
|
|
||||||
|
|
||||||
Same scenario as above. ServerC splits and UserC cycles channel #broken,
|
|
||||||
recreating it with a TS of 900000000. ServerC rejoins with the network via
|
|
||||||
HubD. HubD realises #broken has a TS of 800000000 locally, and ServerC is
|
|
||||||
showing a TS of 900000000, it ignores ServerC's modes and ops. The channel
|
|
||||||
remains opless. ServerC receives HubD's modes, and it notices HubD has a
|
|
||||||
lower TS of channel #broken. It removes UserC's ops, removes the channel
|
|
||||||
modes on #broken, and accepts HubD's status.
|
|
||||||
|
|
||||||
The network version of #broken hasnt changed. It is still opless, with a TS
|
|
||||||
of 800000000.
|
|
||||||
|
|
||||||
|
|
||||||
As you can see, TS5 makes splitting a server to regain ops useless, as it
|
|
||||||
cannot be abused to give ops after a netsplit.
|
|
||||||
|
|
||||||
The problem with TS5 however, is what happens on a mixed TS5/TS3 network.
|
|
||||||
Channels where the older TS has ops will behave the same way on TS5 and TS3,
|
|
||||||
however an opless channel will behave differently, as you can see above.
|
|
||||||
|
|
||||||
The result of TS5/TS3 mixed can be a desync:
|
|
||||||
|
|
||||||
Example1:
|
|
||||||
|
|
||||||
As per Example1 above, except the rest of the network is TS5, ServerA is
|
|
||||||
TS3. ServerA would keep its modes and ops, whilst the rest of the network
|
|
||||||
would remove them. This means only ServerA would see UserA as opped. The
|
|
||||||
desync can be abused, as UserA can send modes. Hybrid6.0 servers will
|
|
||||||
accept these modes from the unopped client, so if UserA ops UserB, who then
|
|
||||||
ops UserA, the channel will be the same across all Hybrid6.0 and Hybrid6.1
|
|
||||||
servers.
|
|
||||||
|
|
||||||
Example2:
|
|
||||||
|
|
||||||
As per Example2 above, except the rest of the network is TS3. ServerC is
|
|
||||||
TS5. ServerC would remove its modes and ops, therefore UserC would not be
|
|
||||||
opped on ServerC, therefore it could not send any mode changes to the
|
|
||||||
channel. Although it is opped elsewhere, it isnt opped locally, so the
|
|
||||||
desync cannot be abused.
|
|
||||||
|
|
||||||
As you can see, the desync's that can occur can either be resynced, or are
|
|
||||||
useless to the user, so a mixed TS5/TS3 network is not a huge problem,
|
|
||||||
although a desync is NOT a good thing to have.
|
|
||||||
|
|
||||||
|
|
||||||
Why TS5?
|
|
||||||
--------
|
|
||||||
|
|
||||||
We have jumped to TS5 from TS3, because there was a version of ircd that was
|
|
||||||
TS4, so it was thought better to avoid a clash with an existing version.
|
|
||||||
|
|
||||||
|
|
||||||
Advantages
|
|
||||||
----------
|
|
||||||
|
|
||||||
Its a realistic event that a server will be attacked so it splits off a
|
|
||||||
network, then used to regain ops in a channel. TS5 makes this pointless,
|
|
||||||
the server will never give ops on a netsplit. TS5 is network wide, so it
|
|
||||||
leaves individual servers free to choose options like NO_JOIN_ON_SPLIT,
|
|
||||||
whilst keeping splits useless to users.
|
|
||||||
|
|
||||||
|
|
||||||
Disadvantages
|
|
||||||
-------------
|
|
||||||
|
|
||||||
Its virtually impossible for a user to actively regain ops themselves (some
|
|
||||||
regard this as an advantage..) because on a large sized channel, its
|
|
||||||
impossible to get people to leave so it can be recreated, therefore if a
|
|
||||||
network did not have some form of services, it could possibly end up
|
|
||||||
requiring oper intervention, as you cant get everybody to leave, and you
|
|
||||||
cant use splits to regain ops, therefore if the channel is open (an
|
|
||||||
invite-only channel would gradually destroy itself as noone new can join) it
|
|
||||||
could be impossible for a user to regain ops.
|
|
||||||
|
|
||||||
On a network that has some form of services, The effect of TS5 would be
|
|
||||||
minimal, however the services must be of sufficient quality to fix opless
|
|
||||||
channels, as TS5 renders netsplits for ops worthless.
|
|
||||||
|
|
||||||
|
|
||||||
Recommendations
|
|
||||||
---------------
|
|
||||||
|
|
||||||
If your network has good stable services, we recommend TS5 is enabled, as
|
|
||||||
people have no reason to abuse netsplits anyway.
|
|
||||||
|
|
||||||
If your network has no services at all, then TS5 may cause problems with
|
|
||||||
users being left with a permanently opless channel.
|
|
||||||
|
|
||||||
If your network occupies the middle ground, then its a choice between users
|
|
||||||
needing to be able to use splits to regain ops, or making netsplits that are
|
|
||||||
caused to regain ops worthless.
|
|
||||||
|
|
||||||
If TS5 is chosen, the FULL network must upgrade and this should be done in a
|
|
||||||
relatively short space of time to minimise the possible desync effects.
|
|
||||||
|
|
||||||
|
|
||||||
Alternatives
|
|
||||||
------------
|
|
||||||
|
|
||||||
There is also NO_JOIN_ON_SPLIT and NO_OP_ON_SPLIT, however these use the
|
|
||||||
configuration of minimum servers and users, and sometimes a split that is
|
|
||||||
above these limits is enough to be abused to regain ops, whereas if the
|
|
||||||
limits are too high, clients will never be able to join anything or be opped
|
|
||||||
when they create a channel.
|
|
||||||
|
|
||||||
|
|
||||||
EOF
|
|
||||||
Loading…
Reference in a new issue