I am one of sysops at cs: Wikipedia. Recently there was a spate registered
user's disruptive edits somewhere between trolling and outright vandalism.
There is a need to ban him temporarily, but there's no way to do it:
As far as I understood en:Wikipedia:Blocking_policy#How_to_block, you're just
supposed to go to Special:Blockip, or cs:Speciální:Blockip, and put the
username into the IP address field. However, this results in the
MediaWiki:Badipaddress error message.
I don't know anything about MediaWiki and have no particular understanding of
PHP, but the respective script in CVS
(http://cvs.sourceforge.net/viewcvs.py/wikipedia/phase3/includes/SpecialBloc….
php?rev=1.30) also tests the variable $wgSysopUserBans, which apparently
(http://cvs.sourceforge.net/viewcvs.py/wikipedia/phase3/includes/DefaultSett…
.php?rev=1.30) is false by default:
# User rights
(...)
$wgSysopUserBans = false; # Allow sysops to ban logged-in users
I, or at least Google, found no other instance of the variable anywhere, so no
way to set it to true either. On the other hand, there must be a way to do it -
there are bannings going on at en: all the time. So, could somebody with better
knowledge of the system tell me whether I missed anything, or whom should I ask
to set this in cs? Or is there a workaround, a way to find out a registered
user's IP address?
Thanks a lot for any help.
--
Jan Vanek jr. (cs:Wikipedista:Mal%C3%BD%C4%8Dten%C3%A1%C5%99,
en:User:Malyctenar)
P. S. It might be also worth changing the SpecialBlockip script to give
another, more appropriate error message in such cases.
Let me preface this by saying that I was going to ask Tim in private,
but Angela told me that this would be a better place. In the next couple days,
I'm going to be rewriting the English wikipedia's sound FAQ, and there's a couple things
I want to grouse about.
First, for those of you who have never heard of it, the Mutopia project is to
songs what Project Gutenberg is to text. The offer lots of public
domain midis that are great additions to the project. In the past, I've converted
them the hard way (tying the sound card of one computer to the sound card of
another). I'd record it into wav, encode it as ogg, and then upload it.
Here's where my requests come in:
(1) The 2 megabyte upload limit - I discovered through trial and error that uploads
are capped at 2 megabytes. For full-length songs, this is way, way too small. A
3-4 minutes song in ogg format at average quality is about 5 megs. I have to set my
encoder to its lowest settings (0 or 1 out of 10) to get it under 2 megs.
Angela has said (rightly so) that full length songs belong at Wikisource, not on
Wikipedia itself. So the above changes should be made there.
(2) Someone was nice enough to recommend an open source (GPL) program that
does midi->ogg conversion much more easily. However, it is a *NIGHTMARE* to get
installed. All of the english hosts are 404 (I had to use the internet archive)
- I hope you speak Nihongo. To get it working under windows you have to
download the patches - 19(!) rar files worth.
I want the sound FAQ to refer to it, but I pity the poor person who has to go through
what I did to get it working. The easiest solution would be simply to zip up the working
version I have here and let Wikipedia host it.
I'd like these issues address in the near future so I can start rewriting the FAQ.
--Mark
When I try to edit a <timeline>...</timeline> section nothing happens, not
even an error box on invalid syntax, so it seems EasyTimeline.pl script is
no longer invoked.
---
Probably unrelated: I used to browse timeline upload dirs of major
wikipedias once in a while to spot new timelines (de: is really active, 40
timelines so far) where some assistance might be required.
e.g. http://de.wikipedia.org/upload/timeline/?M=D
Now I get "Forbidden. You don't have permission to access /upload/timeline/
on this server."
Is this on purpose?
Erik Zachte
Hi
Is somebody against the idea of sorting interwiki links in the alphanumerical
order (by language: en always before fr) ? It will be easier to find a
corresponding article in a specific language thus.
Cordialy
Emmanuel Engelhart
How we will use the Celeron systems in Europe hasn't been decided yet - there's still regular discussion going on in the usual technical discussion place, #mediawiki. Anyone not participating there routinely is missing a high proportion of the productive technical discussions.
The options:
1. Split by language and project. We've done this before. It's easy and well understood. It's limited when we end up having many different proxy locations because it's hard to load balance and because people in one country don't only work on one language. It's very likely that we'll do this at first, even if we change later.
2. There are several ways to identify country given an IP address. At least three anti-spam DNS servers do this and there are public lists of IP ranges by country. A very well understood solution but not one we have experience of (unless you cont me working on an open source spam blocking project which supports it). The Freenode IRC network which hosts the IRC channels uses this approach and one of their technical people likes us, was involved in developing their solution and offered asistance a few weeks ago. The information isn't perfectly accurate but it's fairly good - good enough.
3. There is at least one solution which uses internet topology analysis to determine the optimal server to send traffic to based on the IP address. It's easy enough - the routers on the internet already track this. The big advantage of this is that it will work well for any number of remote sites. When we have 50 remote sites, people will be directed to the closest one to them (and then load balancing can offload it if necessary). See http://www.supersparrow.org/ for one solution of this type.
We may well start with 1 and move to 3 later. 2 is probably worth skipping if we can - it's not as good 3 and doesn't scale to a large number of places as well. Initial tests will almost certainly use 1 for proving the concept of offloading traffic from the US based Squids and sort out any problems.
But none of this is decided yet. We won't know for a month or more, probably.
This installation was done upon a base with a mediawiki 1.2.6, as
I was adviced previously.
(It seems to be a little bug concernning the php memory limit.
3072Mo is said to be not enough)
Checking environment...
* PHP 4.3.8 ok
* PHP server API is apache; ok, using pretty URLs
(index.php/Page_Title)
* Have XML / Latin1-UTF-8 conversion support.
* PHP's memory_limit is 3072M. If this is too low,
installation may fail! Attempting to raise limit to 20M... ok.
* Have zlib support; enabling output compression.
* Found GD graphics library built-in, image thumbnailing
will be enabled if you enable uploads.
* Installation directory: /var/www/le/all4dev
* Script URI path: /le/all4dev
* Connected as root (automatic)
* Connected to database... 4.0.20-log; enabling MySQL 4
enhancements
* Database all4dev exists
* There are already MediaWiki tables in this database.
Checking if updates are needed...
...ipblocks is up to date.
...already have interwiki table
...indexes seem up to 20031107 standards
...have linkscc table.
...linkscc is up to date, or does not exist. Good.
...have hitcounter table.
Adding rc_ip...ok
Converting links table to ID-ID...
Loading IDs from cur table...
Finished loading IDs.
Dropping temporary links table if it exists... done.
Creating temporary links table... done.
Processing 82 rows from links table...
Inserting 82 tuples into links_temp... done. Total 82 tuples
inserted.
82 valid titles and 0 invalid titles were processed.
Dropping backup links table if it exists... done.
Swapping tables 'links' to 'links_backup'; 'links_temp' to
'links'... done.
Conversion complete. The old table remains at links_backup;
delete at your leisure.
Adding user_real_name field to table user...ok
Adding querycache table for slow special pages... ok
Adding objectcache table for message caching... ok
Adding categorylinks table for category management... ok
Warning: mysql_query(): 99 is not a valid MySQL-Link resource in
/var/www/le/all4dev/includes/Database.php on line 177
Warning: mysql_query(): 99 is not a valid MySQL-Link resource in
/var/www/le/all4dev/includes/Database.php on line 177
Unable to free MySQL result
Backtrace:
Database.php line 210, in wfdebugdiebacktrace()
DatabaseFunctions.php line 83, in database::freeresult()
moveCustomMessages.inc line 38, in wffreeresult()
index.php line 448, in movecustommessages()
--
Michaël P.
gpg: D4C8 F73D A000 71C7 44EF 27E6 8982 4991 7126 3CE3