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