Hi all
I'm happy to let you know that new hardware has been ordered by Wikimedia
Deutschland and will arrive probably in about two weeks. We will get two new
systems:
* A more powerful web server, to replace hemlock: Sun Fire X4150, 2x Quad-Core
Xeon, 8GB RAM, 2x73GB SAS HDD. The current web server only has two cores.
* Another database server, to be used for S1 (english wikipedia), so S1 and S3
no longer have to share a server: Sun Fire X4250, 2x Quad-Core Xeon, 32GB RAM,
16x146GB SAS RAID.
This should improve performance and give us some head space for growth. Once the
new servers arrive, S3 will be re-imported too, so we will have live data again.
Any ideas for names? To stay with the nightshade theme, how about Jurubeba and
Erubia? Or perhaps we go the "witches' weed" way, with Datura and Mandrake?
Henbane is taken, i think. Amanita sounds nice, too :)
A third server has been ordered, which will also be installed in Amsterdam, but
will not be part of the toolserver cluster. It's a storage server (X4540, 24TB
RAID) that will keep a live backup of all media files.
Cheers,
Daniel
Hello all,
with the beginning of the next year (2011) I will not longer accept new
interwiki-bot-accounts, if:
-The homewiki of the bot has at least one active interwiki-bot, which runs on
the toolserver, OR
-The homewiki has less then 1000 articles.
(There can be exceptions if there is a good reason of course)
The homewiki is that wiki where the bot starts and where the account-requester
got his/her bot approved (see [1]).
If the account-requester requested the account only for the interwiki-bot, the
request will be rejected; if he/she requested the account also for other
things, only the interwiki-bot will be denied of course and the rest of the
request will be handled the normal way.
For interwiki-bots which runs already on the toolserver, there is no change at
the moment. When you find a free minute: Please add your bot to [2] and check
if there are inactive bots listed for your wiki.
The goal of this change is to limit the number of interwiki-bots on the
toolserver (and improve our documentary a bit).
Sincerly,
DaB.
[1] https://wiki.toolserver.org/view/Account_approval_process, Request
process, Point 4.
[2] https://wiki.toolserver.org/view/Wikimedia_bots
--
Userpage: [[:w:de:User:DaB.]] — PGP: 2B255885
Hi, it looks like the user-store is completely full:
>df
hemlock:/aux0/user-store
3904398336 3904398336 0 100% /mnt/user-store
It requires cleaning and sorting (especially the dumps that are all
over the place), but I especially wonder what is taking so much place
?
I guess I'll have to use my home quota for now.
Darkdadaah
Hey, guys.
I've had an epiphany today about internationalization of the Toolserver tools.
You see, right now we have to create our own ways to provide more languages:
* http://toolserver.org/~holek/cite-gen/index.php?scriptlang=gsw
* http://toolserver.org/~soxred93/pcount/index.php?uselang=ckb
etc. etc.
What I propose is language subdomains, much like Wikimedia projects
have. All language subdomains would refer to the same directories, so
we could just do Apache's ServerAlias equivalent on ZWS.
This would make possible for developers to read the language user
wants directly from the subdomain, instead of relying on seperate tool
implementation of translations.
And by that, I mean just using different parameters to describe user's
desired language, not how to achieve this. So, for example, above
links would look like this:
* http://gsw.toolserver.org/~holek/cite-gen/index.php
* http://ckb.toolserver.org/~soxred93/pcount/index.php
A tool reades subdomain's code and uses a correct language, much like
it would do with an additional parameter...
... but this parameter is now gone and is not cluttering the query string. :)
--
Mike Połtyn
-- P.S. this message is a duplicate, so I apologize if the first one
arrives as well. I've had some problems with my mailing list account
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
On the morning (UTC) of January 3rd we will performance general maintenance[0]
on all servers. Services will be affected as follows:
Service | Expected impact
--------------------------+----------------------------------------------
Login server: nightshade | See below.
Login/web servers | Some software unavailable for < 30 minutes.
All other services | No impact.
Start time: Monday, 3rd January, 12AM UTC
http://www.timeanddate.com/worldclock/fixedtime.html?day=3&month=1&year=201…
End time: Monday, 3rd JAnuary, 3AM UTC (estimated)
http://www.timeanddate.com/worldclock/fixedtime.html?day=3&month=1&year=201…
Details:
We will perform general software upgrades. A list of software to be upgraded
can be found at:
<https://wiki.toolserver.org/view/Admin:Pending_maintenance_tasks>
Some software may be unavailable or function incorrectly during the upgrade
process, which we estimate will take under 30 minutes.
--
Python 2.6 (/usr/bin/python2.6, /opt/ts/python/2.6/bin/python) will be removed
during the maintenance. This was announced in the previous maintenance and no
problems have been reported with Python 2.7, which is currently the default
Python.
--
The default locale on the Solaris login servers will change to en_US.UTF-8.
This was already the case for all services except "cron".
--
We will reinstall nightshade, the Linux login server, as Solaris. This was
announced in September and again in November. No major issues have been
reported which would block the migration. For more information, see
<http://lists.wikimedia.org/pipermail/toolserver-announce/2010-September/000…>
and
<http://lists.wikimedia.org/pipermail/toolserver-announce/2010-November/0003…>
- river.
[0] https://wiki.toolserver.org/view/Maintenance_schedule
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (NetBSD)
iEYEARECAAYFAk0Z+m8ACgkQIXd7fCuc5vK7ZgCfRUJNpjo7AXpoh/r48B92YPkb
BvUAn27En7d+5q6qPwNWBBSg6kJLzv7J
=xTT4
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
At 19:20 UTC Wikimedia accidentally rebooted amaranth (the Toolserver system in
the US) during maintenance. This caused an outage of JIRA, MediaWiki, FishEye
and MySQL database replication for around 5 minutes.
- river.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (NetBSD)
iEYEARECAAYFAk0JFhIACgkQIXd7fCuc5vLatQCdHgJjQYDJxDQFOs55CNbDHeoS
HwEAnj0iQldsfA5kwkRjafrLHu9+wSXL
=lDUg
-----END PGP SIGNATURE-----
Hello,
One day it was announced that long running queries are being killed in
case the replag exceeds some value.
I've added a simple piece of code to my tools, which prints replag
info in case a query is killed and a few days ago I've got the
following result:
--------------------------------------------------------------------------------------------------
ERROR 1317 (70100) at line 6874: Query execution was interrupted
last replicated timestamp: 20101207214400
replag: 00:00:01
--------------------------------------------------------------------------------------------------
Could anyone explain whether it was possible that a query (even a long
running one) has been killed when replag was so good?
mashiah
1. I'm testing my skill and I run my script under cron. The python script
begin with these rows (and it runs):
# -*- coding: utf-8 -*-
#!/usr/bin/python
import os,sys
if not sys.platform=="win32":
sys.path.append('/home/alebot/pywikipedia')
os.chdir("/home/alebot/scripts")
Then I tried to move to batch job sheduling, but... my script gives an
error: now the server dislikes sys.path row. Why? I obviously have to study
more: but what/where have I sto study? :-(
2. The script bring into life a python bot, who reads RecentChanges at 10
minutes intervals by a cron routine. Is perhaps more efficient a #irc bot
listening it.wikisource #irc channel for recent changes in your opinion?
Where can I find a good python script to read #irc channels?
Thanks - I apologize for so banal questions.
Alex