Last modified: 2014-06-05 08:55:58 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T30276, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 28276 - Inconsistently named IRC recent changes channels
Inconsistently named IRC recent changes channels
Status: RESOLVED WONTFIX
Product: Wikimedia
Classification: Unclassified
IRC (Other open bugs)
unspecified
All All
: High major (vote)
: ---
Assigned To: Krinkle
:
: 41682 (view as bug list)
Depends on:
Blocks: 16599
  Show dependency treegraph
 
Reported: 2011-03-27 16:49 UTC by Krinkle
Modified: 2014-06-05 08:55 UTC (History)
19 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Krinkle 2011-03-27 16:49:08 UTC
The following (possibly more) can't be minitored easily due to their abnormal channel name.
* #mediawiki.wikipedia
* #advisory.wikipedia
* #species.wikipedia
* pa.us.wikimedia.org (?) [1]

Note that #commons.wikimedia and #meta.wikimedia and #wikisource are fine and represent the domainname exactly.

Bots using irc.wikimedia.org to monitor vandalism (ie. the [[m:Countervandalism Network]]) are unable to monitor these (unless hacking the bot and hardcoding the paths).

species.wikipedia is a bit of an exception as species.wikipedia.org redirects to species.wikimedia.org so that one still works when monitored through the bot as 'species.wikipedia' it will be able to connect to species.wikipedia.org/w/api.php (as it redirects)

The others are however hard to monitor (eg. not monitored) as the channel neither matches the hostname nor the interwiki prefix. As a result the small-wiki monitoring team is unable to properly monitor these wikis.

Please move #mediawiki.wikipedia to #mediawiki as soon as possible (and leave the old channel as redirect for backwards compatibility for those that have hardoded the paths)

I was unable to find where this chapter wiki is monitored, nor have I found a way to link to it with an interwiki link on-wiki (There is no pa-us or pa.us wiki)
Comment 1 p858snake 2011-03-29 00:31:00 UTC
The naming is due to how those are historically handled, non "project" wikis (eg: mediawiki and advisory as well as many others) are in the wikipedia area. You will notice this more on the secure server.
Comment 2 Krinkle 2011-04-03 18:10:47 UTC
(In reply to comment #1)
> The naming is due to how those are historically handled, non "project" wikis
> (eg: mediawiki and advisory as well as many others) are in the wikipedia area.
> You will notice this more on the secure server.

I know  why they are in the wikipedia space in those areas, but I'm sure there's more to it that the system used on the secure server.

Reason being that the following wikis (and more) are in /wikipedia/ on secure but on on IRC:
* meta.wikimedia
* commons.wikimedia
* incubator.wikimedia
* strategy.wikimedia
* wikimania2006.wikimedia
* wikimania2007.wikimedia
* wikimania2008.wikimedia
* wikimania2009.wikimedia
* wikimania2010.wikimedia
* wikimania2011.wikimedia
All of the above are working irc channels on irc.wikimedia.org

So why the exception for those 4 ?
Comment 3 Krinkle 2011-04-03 18:11:38 UTC
4 : mediawiki, advisory.wikimedia, species.wikimedia, pa.us.wikimedia
Comment 4 Tim Starling 2011-04-29 03:20:09 UTC
These can be fixed on a case-by-case basis by setting $wgRC2UDPPrefix in InitialiseSettings.php. After you change it, the IRC client will create the new channel when the first event comes through for that wiki.
Comment 5 Krinkle 2011-05-05 20:21:00 UTC
(In reply to comment #4)
> These can be fixed on a case-by-case basis by setting $wgRC2UDPPrefix in
> InitialiseSettings.php. After you change it, the IRC client will create the new
> channel when the first event comes through for that wiki.

This may sound stupid, but how about defaulting it to "#\$wgServer\t", since that's what it's trying to do anyway.

(instead of adding every exception manually, which is like the reverse of the wgDBname regex at the start.
Comment 6 Barras 2011-05-16 18:47:20 UTC
also problems with readerfeedback.labs.wikimedia.org

Channel name in the wikimedi.irc is #readerfeddback-labs.wikimedia

[[m:User:Barras|Barras]]
Comment 7 Sam Reed (reedy) 2011-07-08 23:44:28 UTC
Want to maybe check on wikitech for some consensus to this bug?
Comment 8 Krinkle 2011-07-09 00:00:37 UTC
So to summarize, in prep. of a wikitech-l post:

IRC channels are historically in a domain-name fashion (but without a .org prefix), eg.:
* #commons.wikimedia
* #en.wikipedia
* #nl.wiktionary
* etc.

However the way wgRC2UDPPrefix does this is by reverse engeneering the logic based on wgDBname, $site and $lang, and does so fairly well but there are (imho too many) exceptions. None of them are surprising once you know how wgDBname is constructed (regexes, switches and stuff in the head of noc settings).

So since this is a long after initialization, how about just using wgServer for this ? Note that this may be problematic with edits made on the secure server, depending on how stuff is send and handled.

Now that I think of it, the 'wikipedia' word problem is also bugging other systems. Such as the several lazy implementations for urls that do http://$lang.$site (that cause bug 27911) which causes Server Not Found errors with icon embeds to stuff like http://foundation.wikipedia.org/apple-touch-icon.png (that hostname doesn't exist! yet there's a link to it in the head-section of all pages on those dbname "*wiki" wikis.

.. perhaps a better solution to fix this is to use wgServer instead of $lang.$site. Although it can't be used on the server server (yet), so perhaps a var like $wmfDomain can be constructed that is the real hostname (so it won't say mediawiki.wikipedia but mediaiki.org for instance) and use that instead.

It's funny how something simple like the domainname of the current wiki is not available... With https into relative urls and secure.wm.o gone, that part of the problem should become a moot point though.

Anyway back to the present and to this bug (which we may wanna wait fixing until after secure.wm.o is gone) - what're your thoughts on this ? using wgServer (or wmfDomain) bad ?
Comment 9 Danny B. 2012-07-20 01:20:44 UTC
Additional inconsistently named channels:

#donate.wikimedia.org -> #donate.wikimedia
#outreach.wikipedia -> #outreach.wikimedia
#quality.wikipedia -> #quality.wikimedia
#wikimania2010.wikipedia -> #wikimania2010.wikimedia
#wikimania2011.wikipedia -> #wikimania2011.wikimedia
#wikimania2012.wikipedia -> #wikimania2012.wikimedia
#wikimania2013.wikipedia -> #wikimania2013.wikimedia
Comment 10 Danny B. 2012-11-02 19:06:57 UTC
*** Bug 41682 has been marked as a duplicate of this bug. ***
Comment 11 Danny B. 2012-11-02 19:08:02 UTC
+ #wikidata.wikipedia -> #wikidata.wikimedia
Comment 12 Liangent 2012-11-02 19:18:24 UTC
We should have a checklist for wiki creation -- or please add this item ($wgRC2UDPPrefix) to the list if there's already an existing one.
Comment 13 Sam Reed (reedy) 2013-02-03 00:10:15 UTC
https://gerrit.wikimedia.org/r/47307
Comment 14 Krinkle 2013-02-03 04:30:35 UTC
(In reply to comment #13)
> https://gerrit.wikimedia.org/r/47307

DO NOT MERGE unless an announcement has been made and tools given at least 31 days of time to address this.

There are many many bots that monitor wikis and given that:
* WMF has little to no investment in countervandalism
* Tools have gone unmaintained for years

it will take time to get to everybody in time.


--

Also, I propose we do this in 2 phases:

1. Change default from lang.site to hostname

By setting the default in InitialiseSettings.php to false.
And in CommonSettings.php the logic Reedy proposed if prefix===false.

Then, in the same commit, add entries to the array in InitialiseSettings for all wikis where hostname !== lang.site (if not already in there).

This phase can be done without announcement as it will have no effective change. It only changes the default for new wikis in the future.

2. When agreed on and given 31 days with announcement, phase out the historical overrides added prior or during phase 1.
Comment 15 Danny B. 2013-02-03 18:23:02 UTC
Well, it actually *can* be merged *if* there are manually created redirects (/mode +if) from old names, which can then stay for a even longer period than a month.

----

Footnote for naming on dbnames - there was a call to name dbases consistently according to the domain name too, so they could also be easily predicitble and constructible. Bear that in mind, please, maybe join these two steps together. (I'll try to find the relevant bug for it, can't find it now.)
Comment 16 Kunal Mehta (Legoktm) 2013-05-08 04:17:50 UTC
And now #login.wikipedia. Can we at least fix that one before the site starts being used?
Comment 17 Sam Reed (reedy) 2013-05-08 16:47:15 UTC
(In reply to comment #16)
> And now #login.wikipedia. Can we at least fix that one before the site starts
> being used?

You know, there's going to be very few edits made to that wiki....
Comment 18 Thehelpfulone 2013-05-12 15:57:26 UTC
(In reply to comment #15)
> Well, it actually *can* be merged *if* there are manually created redirects
> (/mode +if) from old names, which can then stay for a even longer period
> than a
> month.
> 

Who can create these redirects on our IRC server?
Comment 19 Krinkle 2013-10-31 11:18:46 UTC
(In reply to comment #18)
> (In reply to comment #15)
> > Well, it actually *can* be merged *if* there are manually created redirects
> > (/mode +if) from old names, which can then stay for a even longer period
> > than a
> > month.
> > 
> 
> Who can create these redirects on our IRC server?

Also, it's important to look into whether the libraries out there can handle with redirects (both on existing connections and for new connections).

The two libraries most used in this context are:
- SmartIrc4net (used by [[m:CVN]]'s CVNBot)
  https://github.com/meebey/SmartIrc4net
- python-irclib/ircbot/SingleServerIRCBot (used by pywikibot)
  https://bitbucket.org/jaraco/irc
  https://github.com/jaraco/irc

Neither appears to have handling for mode 'f' on channels, or have any mention of the word "redirect" or "forward" anywhere in their codebase.
Comment 20 Danny B. 2014-06-05 08:39:12 UTC
(In reply to Krinkle from comment #19)

> Also, it's important to look into whether the libraries out there can handle
> with redirects (both on existing connections and for new connections).
> 
> The two libraries most used in this context are:
> - SmartIrc4net (used by [[m:CVN]]'s CVNBot)
>   https://github.com/meebey/SmartIrc4net
> - python-irclib/ircbot/SingleServerIRCBot (used by pywikibot)
>   https://bitbucket.org/jaraco/irc
>   https://github.com/jaraco/irc
> 
> Neither appears to have handling for mode 'f' on channels, or have any
> mention of the word "redirect" or "forward" anywhere in their codebase.

/mode +if redirects whoever automatically on server side. (aka it does not work like 301/302 redirs in HTTP which require client to act)
Comment 21 Krinkle 2014-06-05 08:42:17 UTC
Now that we're working on RCStream, I think it's best to just keep the old irc channels the way they are until we (eventually) shutdown irc.wikimedia.org. No need in nitpicking over channel names and having people migrate. What we really want is for people to migrate to stream.wikimedia.org.

The few configuration lines to keep the channel names different on irc.wikimedia.org aren't that troublesome to just keep around.

https://wikitech.wikimedia.org/wiki/stream.wikimedia.org
https://wikitech.wikimedia.org/wiki/RCStream

We're still busy installing it in Eqiad data centre, but coming online very soon now.
Comment 22 Danny B. 2014-06-05 08:48:05 UTC
(In reply to Krinkle from comment #21)
> Now that we're working on RCStream, I think it's best to just keep the old
> irc channels the way they are until we (eventually) shutdown
> irc.wikimedia.org. No need in nitpicking over channel names and having
> people migrate. What we really want is for people to migrate to
> stream.wikimedia.org.

You don't need anybody to migrate. As mentioned in comment #20, the server handles that automatically itself.
Comment 23 Nemo 2014-06-05 08:55:58 UTC
(In reply to Danny B. from comment #20)
> /mode +if redirects whoever automatically on server side

Only on join unless you cycle the channel, though

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links