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
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
On the morning (UTC) of December 6th we will perform general maintenance[0] on
all servers. Services will be affected as follows:
Service | Expected impact
-----------------------------+-------------------------------------
Entire platform | As described in maintenance schedule[0]
JIRA, MediaWiki, FishEye | Under 30 minutes outage for each service
| during upgrade
Start time: Monday, 6th December, 12AM UTC
End time: Monday, 6th December, 8AM UTC (estimated)
Details:
This is a schedule general maintenance, which we use for various non-critical
tasks. The expected outages are as described in the maintenance schedule[0].
Most of the changes for this maintenance are in the local TS software, /opt/ts;
all software will be upgraded to the latest version, and some minor changes
will be made. The full list of upgrades, including Perl modules, is available
here:
<https://wiki.toolserver.org/view/Admin:Pending_maintenance_tasks>
The following changes will also be made:
* Mono will now install directly in /opt/ts instead of /opt/ts/mono/2.0. If
you call "mono" without an absolute path, this will not affect you. If you
currently call "/opt/ts/mono/2.0/bin/mono", you should change this to remove
the full path before the maintenance.
* The preferred OpenSSL is now /opt/ts/bin/{amd64,}/openssl, which is OpenSSL
1.0.0b instead of /usr/sfw/bin/{amd64,}/openssl (0.9.7d). This should not
affect users, but if you currently call the version in /usr/sfw with a full
path, you may wish to remove the path so you automatically use our version,
which is better.
We will additionally make some changes to how the software is compiled; if you
have compiled your own C or C++ programs, this will affect you, and you should
read the section "Changes to ts-specs environment" below. If you do not have
any locally-compiled software, this change will not affect you.
During the maintenance, some software may not work correctly (e.g. programs or
libraries not found).
--
JIRA, FishEye, MediaWiki and phpMyAdmin will also be upgraded.
--
The default Python version will change from 2.6 to 2.7. If you currently use
/usr/bin/python, this change will happen for you automatically. If you use
/usr/bin/python2.6 explicitly, you will need to change to /usr/bin/python2.7 to
use the new Python.
If you have programs which don't work under Python 2.7, you should a) report
this in JIRA, and b) switch to /usr/bin/python2.6 before the maintenance. If
there are no problems with Python 2.7, we will remove Python 2.6 from the
system during the next maintenance (January 2011).
We will patch Python 2.7 to revert the fix for bug 1054943[1], which introduced
a regression affecting Unicode normalisation[2][3].
--
The default "gcc" will become GCC 4.5.1, rather than 3.4.3. This may affect
you if you build locally-installed Perl modules, especially if these modules
use C++ code. This is described in more detail below.
--
Changes to ts-specs environment
===============================
This section only applies to users with locally-compiled C or C++ software.
The new version of ts-specs (/opt/ts) installed during the maintenance has
switched the default compiler from Sun Studio to GCC 4.5.1. This is described
in more detail at [4]. In brief:
* You should change from your current compiler (Studio, GCC 3.4.3 or GCC 4.4)
to GCC 4.5.1, /opt/ts/bin/gcc.
* If you recompile any Studio- or GCC 3.4.3-compiled C++ code with the new
compiler, you need to recompile all of it, because the ABIs are not
compatible.
* GCC 3.4.3 will no longer be installed.
* If you use Studio-compiled versions of C++ libraries in
/opt/ts/<lib>/<version>/, you should change to the GCC version in
/opt/ts/<lib>/<version>-gcc/.
The following libraries require special handling:
* Studio-compiled versions of MySQL++ and VIPS were previously installed in
/opt/ts/lib. If you use these libraries, you should switch to the version
that we will install in /opt/ts/<lib> (where <lib> is "mysqlpp" or "vips").
The Studio-compiled version will remain available for now.
* Studio-compiled versions of ImageMagick, sigc++ and cairomm are currently
installed in /opt/ts. They will be replaced with GCC-compiled versions
in the same path, and Studio-compiled versions will not be available.
If this adversely affects you (because you use these libraries and need time
to migrate), you should let us know before the maintenance.
[0] https://wiki.toolserver.org/view/Maintenance_schedule
[1] http://bugs.python.org/issue1054943
[2] http://bugs.python.org/issue10254
[3] http://lists.wikimedia.org/pipermail/toolserver-l/2010-November/003633.html
[4] http://lists.wikimedia.org/pipermail/toolserver-announce/2010-November/0003…
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (FreeBSD)
iEYEARECAAYFAkzz1HIACgkQIXd7fCuc5vIcAQCfffiUXeXvhgCdFT6wHtEFWc1X
MZ4An1yUKY6ZFzeGhxcPFgXhA7DUDH7j
=RfuR
-----END PGP SIGNATURE-----
Hello,
I renewed my account today for "6 months" and the new expiration date is
May 17 2011. I do not care the two weeks difference but just wanted to
check if it was a bug in the renewal tool.
Thanks,
N.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
After this month's maintenance, which includes quite a few software
updates/changes, I'd like to come up with a coherent strategy for updating
software. The aim is to balance the inconvenience of updates (which can
require changes from users) with having reasonably up-to-date software.
This will apply to all programs, libraries and modules (Perl/Python/...) in
/opt/ts on the Solaris servers.
I would propose the following schedule:
* New installs will be done on demand
* Minor upgrades (e.g. 1.0.0 to 1.0.1) will be done each month
* Major upgrade (e.g. 1.0.0 to 1.1.0 or 1.2.0), which might require changes
from users, will be done quarterly, in January, April, July and October.
In addition, when we upgrade a shared library (e.g. libjpeg.so.7 ->
libjpeg.so.8), or a large application like Python (2.x -> 2.y), if possible, we
will leave the old version installed for one maintenance cycle (3 months) to
give users time to fix or recompile local software.
Please comment if you think this won't work for you, or if you have a better
idea.
- river.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (FreeBSD)
iEYEARECAAYFAkz1ObAACgkQIXd7fCuc5vJMYgCgkjjihBfiQx0IR/o48zDuaYjw
72IAoLw2A2c0rZt0pC+1ZDPzSZzO6uGD
=/Dp6
-----END PGP SIGNATURE-----
Hello,
I would ask for allowance to run a request that can be resource
consuming if not properly scaled:
SELECT page.page_title as title, rev_user_text as user, rev_timestamp
as timestamp, rev_len as len FROM revision JOIN page ON page.page_id =
rev_page WHERE rev_id > 0 AND rev_id < [...] AND rev_deleted = 0;
This is intended to extract basic data about all publicly visible
revisions from 1 to [...]. Info about each revision would be a 4-tuple
title/user name/time/length. I need this data to start generating a
timeline of editing of srwiki, so it is intended to be run only once
for each revision.
If this is generally allowed to do, my question is how large chunks of
data can I take at once, and how long should be waited between two
takes?
M
Hi,
I know there are lots'o'files for daily (hourly?) pageview stats on
the toolserver.
Are there aggregated counts for the whole month? So I only have to
check 1 file instead of hundreds (the aggregated file would, of
course, be smaller than the concatenated hourly ones).
Or maybe even as a database? (Onecan dream...)
If not, does anyone volunteer to generate them? They'd really help
with my GLAM tools, increase Wikimedia outreach etc.
Cheers,
Magnus
Hi,
I’m having a problem when I try to use pylab / matplotlib.pylab from
command-line (willow) as well as from a cgi script (wolfsbane). This
exception is raised:
>>> import pylab
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/opt/ts/python/2.6/lib/python2.6/site-packages/pylab.py", line
1, in <module>
from matplotlib.pylab import *
File
"/opt/ts/python/2.6/lib/python2.6/site-packages/matplotlib/pylab.py",
line 216, in <module>
from matplotlib import mpl # pulls in most modules
File
"/opt/ts/python/2.6/lib/python2.6/site-packages/matplotlib/mpl.py", line
1, in <module>
from matplotlib import artist
File
"/opt/ts/python/2.6/lib/python2.6/site-packages/matplotlib/artist.py",
line 6, in <module>
from transforms import Bbox, IdentityTransform, TransformedBbox,
TransformedPath
File
"/opt/ts/python/2.6/lib/python2.6/site-packages/matplotlib/transforms.py",
line 34, in <module>
from matplotlib._path import affine_transform
ImportError: ld.so.1: python: fatal: relocation error: file
/opt/ts/python/2.6/lib/python2.6/site-packages/matplotlib/_path.so:
symbol
__1cDstdMbasic_string4Ccn0ALchar_traits4Cc__n0AJallocator4Cc___J__nullref_:
referenced symbol not found
Does anyone know how to solve this problem? I guess its a configuration
or installation error, isn’t it?
Thanks for your help!
Best regards,
Robin
--
Robin Krahl || ireas
http://robin-krahl.de
me(a)robin-krahl.de
Is it able to give a project its own domain one day while the project will still be a Toolserver project with proper TS attribution/promotion? There's no Wikipedia DB replica in Belarus, so downloading dumps would not be the best approach in my planned project. :)
--
---------
С уважением,
Павел Селіцкас/Paul Selitskas, skype: p.selitskas
Wizardist @ Wikimedia projects