[IRC-DEV] Propuesta funcional para chan2 (ampliacion)
rubenc at arrakis.es
Tue May 14 12:00:14 CEST 2002
He estado preguntando en Efnet a un par de ircops, y me han dejado
Que pasteo aqui para mayor comodidad:
| What ChanFix/JUPES really is and isn't. |
|wednesday, august 29th, 2001| | by qurve |
Ok, there has been a whole lot of discussion lately about ChanFix/JUPES
it's pretty apparent that not everyone fully understands how JUPES
works and there has been a lot of speculation about many things. I will
attempt to clear these things up as much as possible.
| A few notes |
1) Don't accept numbers in this FAQ as 100% fact, they may change as
admins see fit. If I say JUPES does X every Y minutes that's as it
is now, it could change but has no real bearing on the overall
functionality of JUPES.
2) JUPES is still in testing phase technically. It is by no means 100%
perfect and was never meant to be. In the original proposal we
were only aiming for a 70% accuracy rate (I happen to think the
actual accuracy rate is *much* higher). Nothing is perfect so please
dont expect it to be.
| How JUPES keeps track |
Every 5 minutes JUPES looks at the network, if more than 25% of the
network is split (from services.int's point of view) JUPES does
nothing. It doesnt update it's database and it doesnt fix channels.
If at least 75% of the network *is* present JUPES goes into action.
It examines each channel in creation at the time and checks a few
things. If a channel has less than 4 users, it will skip adding any
stats for the particular channel. If the channel has 4 or more users
it then scans the oplist for ops to log. It is very important to
know that not *every* op will be logged. JUPES will not log ops who
do not have ident (if your username starts with ~) and it will not
log ops who have what appear to be dynamic hostnames (this is most
commonly hosts that have strings like "ppp" "dialup" etc in them).
So all ops who have ident and what appears to be a static hostname
will be logged.
Everytime an op is logged its user at host gets a 'point' which is used
later in re-op'ing channels. This data is cycled over a two week period
(data from two weeks ago is deleted as new data is entered).
| How JUPES fixes opless channels |
At the instant a channel becomes opless JUPES reacts by checking a few
things, First (like while logging) JUPES takes no action if more than
25% of the network is missing or the channel has less than 4 users.
JUPES also requires that a channel exist for 6 passes (rougly 30
before it will ever re-op people if the channel becomes opless. If
the channel does meet those requirements JUPES scans the channel for
user at host's that match known-ops in its database, once it collects them
all it figures out which of them are the top 5, and ops them. Please
note this very important detail: JUPES ops the top 5 ops that are
*CURRENTLY IN THE CHANNEL* not necessarily the top 5 ops in it's
This means that someone not normally op'd, who somehow was an op for
JUPES' passes *could* technically be re-op'd if he happens to be one
of the top 5 in the channel, but this is the way it has to be. If JUPES
doesnt find *anyone* in the channel that are in it's database it simply
does nothing, and will check for people to op everytime it makes a
pass. Also to clear this up, it does not matter if your channel is
only, keyed, full, or JUPES is banned, it can join no matter what and do
| What manual chanfix is |
JUPES has within it the ability to allow IRC Admins to manually ChanFix
channel. All this does is force JUPES to join a channel, deop everyone,
re-op the top 5 ops in its database. This does *not* allow IRC Admins to
give the channel to anyone they feel like, only return it to the people
have had it the longest. A new feature just recently implemented into
is the ability for JUPES to also clear any +i, +k, +l, or +b channel
on the channel in question, and delay the re-op'ing process. This allows
for channels that have been taken and 'locked' down to prevent the real
from being on the channel, to be returned to the real owners. The manual
chanfix does not require the channel to be in existence for a certain
of time nor does it require a minimum number of users to be on it. It
however require that 75% of the network be present at the time the
is issued. For an example/explanation of this process, please read on:
1) #efnet.org makes a mistake and op's the wrong person.
2) The takeover people kick everyone out and set the channel +ikl
3) An Admin is contacted and the scores are checked for #efnet.org
It is seen that the top 10 op scores on #efnet.org are:
3476, 3284, 2356, 2293, 2832, 2184, 1982, 1942, 1846, and 1821
while the top 10 scores for the current ops on #efnet.org are:
43, 41, 39, 39, 38, 35, 34, 33, 33, and 29
from this it can easily be assumed the channel has been taken over.
4) The Admin then issues a delayed manual chanfix
5) JUPES joins, deop's everyone, clears the +ikl modes and clears all
6) The real ops rejoin their channel and within the next few minutes
are op'd by JUPES
7) Life goes on for #efnet.org
If you would like to know the technical aspects of this process please
read on, if you don't want to, or are not familiar with TS, this wont
really matter to you :]
Before JUPES joins, it looks at the TS of the channel in question. If
channel in question has a TS of 2 or more, an SJOIN of CURRENT_TS-1 is
sent and all servers deop the current ops.
If the TS of the channel in question is 1 or 0 an SJOIN is sent with a
matching TS, and then mode -o's are sent thereafter to deop all ops.
The reason for this is that we do not want to leave channels with a TS
of 0 or -1.
After the deop'ing is done, JUPES goes through the exact same process
it would if the channel had gone opless on its own. It checks the
for people that match it's op database and gives op's to the top 5
| Closing |
I really hope this little FAQ has helped some people, and to settle some
questions about what JUPES really is and how it works. If you still have
any questions about it you can email me at qurve at ircII.org or msg me on
efnet on the nick 'qurve'
| Links |
jupes service (final) (voting.blackened.com vote)
services.int reverse command (voting.blackened.com vote)
| Credits |
Chris Behrens <cbehrens at codestud.com> [comstud on EFNet]
- Author of JUPES, much of this FAQ was based on his explanations
William J. Rockwood <wjr at wjr.org> [stranged on EFNet]
- Endless source of information.
Ryan Garland <tsk at gaschamber.net> [Tsk on EFNet]
- Proposed the idea of a 'manual chanfix' command.
Me <qurve at demolished.org> [qurve on EFNet]
- I wrote this, yay for me.
More information about the IRC-Dev