mirror of
https://github.com/matrix-construct/construct
synced 2024-11-17 23:40:57 +01:00
212380e3f4
+ branches/release-2.1 -> 2.2 base + 3.0 -> branches/cxxconversion + backport some immediate 3.0 functionality for 2.2 + other stuff
151 lines
5.5 KiB
Text
151 lines
5.5 KiB
Text
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
|