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
>> hi all
>>
>> many of our tools uses messages from betawiki because they are
>> translated in many languages.
>> But this messages must be synchronized and I think it's not very
>> economically if every user/tool do that self. Because of that I
>> propose
>> to create one database for all users which will be sync periodically.
>
>A database with one table per user? Sounds good.
>
>> What do you think? Are any other users interested for such a db?
>
>I would be interested.
>
>> Greetings,
>> Luxo
>
>Pietrodn
>powerpdn(a)gmail.com
I thought not one table per user, but rather one table for all messages.
On betawiki are a lot messages e.g.
http://translatewiki.net/wiki/MediaWiki:Abusefilter-revert-title/en.
So I would make a table something like
+
----------+------------------------+-----------------------------------------------------+
| LANG | MESSAGE |
TEXT |
+
----------+------------------------+-----------------------------------------------------+
| en | Abusefilter-revert-title | Revert all changes by
filter $1 |
+
----------+------------------------+-----------------------------------------------------+
| de | Abusefilter-revert-title | Alle Änderungen durch
Filter $1 rückgängig machen |
+
----------+------------------------+-----------------------------------------------------+
| fr | Abusefilter-revert-title | Révoquer toutes les
modifications par le filtre $1 |
+
----------+------------------------+-----------------------------------------------------+
the messages which will be synced should be one a list which every
ts-user can edit, so that it's easy for every user to add the messages
he requires.
--Luxo
Lately, I've tried to make some large improvements, primarily in
the Swedish language Wikipedia. Sometimes this has succeeded,
sometimes it has failed or been delayed. Some of the delays have
been due to failing server functionality, either at WMF or on the
toolserver. We're victims to our own success. Provisional hacks
tend to get so successful, that people start to rely on them.
I really want to get better geo tagging going in the Swedish
Wikipedia. To this end, WikiMiniAtlas was activated some weeks
ago. The activation went just fine. But the underlying database is
not up to date. This is because Stefan Kühn is rewriting the
script that extracts geo coordinates from the database dumps, and
he has many other things to do. I don't blame him. He's doing a
very good work, when he finds some time for it. But even if he had
a solution ready, current database dumps might not be available.
Suppose database dumps were ready and WikiMiniAtlas was up to
date, and I would have some idea for a contest among Swedish
wikipedians to add more coordinates to articles with prizes being
awarded to the top ten contributors. That's the kind of project
for which I could apply for money. That money could cover some
costs for the toolserver or for the ticket for somebody to go to
the developer meeting. It would have many good side effects.
Of course, the WikiMiniAtlas is just one example of a very
successful toolserver project that could generate such benefits.
Another example: Apparently the Dutch Wikipedia community has some
tool (?) to facilitate image uploading, that we might want to
adapt to Swedish. But that's not running on the toolserver today,
so we would also have to find somewhere to host it. This can of
course be solved, but what would the best solution be?
My question: when we see such opportunities, how can we make
better use of them? The toolserver team has a list of "stable"
services which are (at least) more stable than the rest. But how
can we invest in making them even better and more stable, so other
projects can build upon them?
One idea that I had was to transfer such projects to the central
Wikimedia servers, and make them a part of the WMF infrastructure.
This would hopefully make the services more stable, and free up
resources for more experimentation on the toolserver. Lately, I've
become more skeptic about that plan, since they seem to have more
work than they can really handle.
Another idea is to set up a separate toolserver for Scandinavia.
I heard some rumours that Wikimedia Norge (Norway) has resources
to do this. But perhaps it is wiser to invest in the existing one?
I'm very happy that the new hardware has arrived and is being
installed. It's unfortunate that it took so long for this to
happen. How can we make resource planning work smoother in the
future? There are millions of users who expect us to perform
better, and I think they will send money if we ask them.
What are we short of? Money? Then say so. People? What kind?
So, who is the idiot that writes this message? I'm user:LA2 and my
full name is Lars Aronsson. I'm a C/UNIX programmer from Sweden.
Back in 1992 I started to scan old Scandinavian books under the
name Project Runeberg, http://runeberg.org/ and after having
started to scan encyclopedias (not just poetry and novels),
finding Wikipedia was a perfect match. I've scanned two minor
encyclopedias for the German and English Wikisource. I've also
been an active contributor to OpenStreetMap since 2005. I happened
to visit Berlin in 2004 when Wikimedia Deutschland was formed. In
October 2007 I helped to create Wikimedia Sverige (Sweden) and has
been a board member since. In 2008 we organized Wikipedia Academy
in Sweden. That's not the only idea we have copied from the German
chapter. We're now in talks with libraries and archives to see if
we can have some major content exchanges. I've been to Wikimania
in Frankfurt (2005) and Alexandria (2008).
--
Lars Aronsson (lars(a)aronsson.se)
Aronsson Datateknik - http://aronsson.se
Wikimedia Sverige - stöd fri kunskap - http://wikimedia.se/
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
first issue: sql-s1 change. we will shortly be changing s1 from yarrow to
rosemary. if you have user databases on yarrow, these will *not* be copied
over, and furthermore will be deleted when s3 is re-imported to yarrow. if you
need to keep these databases, you need to dump them *now* using mysqldump, and
either import them into the new s1 server after the change, or import them back
into yarrow when s3 is reimported.
second issue: large home directories.
the following users have home directories larger than 10GB:
12978772 drh08
15633252 sk
15753754 voj
18902342 bryan
20391211 kolossos
34753424 cbm
41874315 dschwen
55842970 daniel
the following users have home directories larger than 1GB:
1206570 emijrp
1231049 tawker
1417818 dab
1437121 flacus
1461143 erenrich
1568766 purodha
1712819 simetrical
1834572 leon
1898741 fmaunier
2026644 kalan
2049700 chabacano
2170154 misza13
2447405 danny_b
2564363 tangotango
2890444 osamak
3260012 river
3860768 vvv
5070464 tparscal
5636581 gmaxwell
7112804 werdna
a full list of home sizes is here:
<http://toolserver.org/~river/bighomes.txt>
whether or not your name is on either of the above lists, but especially if it
is, please look at what's using disk space in your home directory and clean out
any old files you no longer need (for example, log files, old dumps, etc).
don't delete anything you actually need, though.
if you need to store dumps or other large files, you can put them in the shared
user store at /mnt/user-store instead of your home directory.
- river.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (HP-UX)
iEYEARECAAYFAkmpdO8ACgkQIXd7fCuc5vIBkQCgqHSWO96VwlrBemGIVsAJ4Jar
3WoAmwWaPrXjE7ozsAiIuawdYftzH+Th
=Nylc
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
hi,
the new servers arrived today and were racked and installed. i am currently
setting up the new s1 database and should have the database imported by the end
of this week, assuming nothing goes wrong.
we won't be able to move /home to hemlock right now as planned, but we might
have an interim solution that improves the slow /home performance.
- river.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (HP-UX)
iEYEARECAAYFAkmoMgcACgkQIXd7fCuc5vLdagCeNiY4g9YcyUhcZZkAcv9lUkmh
s8kAnA5U2zB+ECNxfxXLC2AnwYdZhyqW
=ZZFy
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
hi,
with the change to the SVN server, svn:// URLs are no longer supported, meaning
legacy repositories ($HOME/subversion/) are not remotely accessible except via
svn+ssh:// (which requires authentication). these repositories have been
removed from FishEye.
if you are still using a legacy repository, and want it to be remotely
accessible, you must convert it to a new-style repository. new-style
repositories are explained here:
https://wiki.toolserver.org/view/SVN
and the conversion process is explained here:
https://wiki.toolserver.org/view/New-style_Subversion_repositories
- river.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (HP-UX)
iEYEARECAAYFAkmj6zEACgkQIXd7fCuc5vKxpwCgq1i007vDvRgMIPVT4bpVB7mc
gzwAn1ltHGL261H3cBBMRcqxdgWwO+9L
=olN9
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
hi,
currently there are some "missing" repositories on stable. we will not be
restoring these to the previous location (/svnroot), but instead integrating
them into the SVN repositories on amaranth. therefore, if you/your project has
an SVN repository on stable, you should mail ts-admins(a)toolserver.org with this
information:
* the repository name
* the users who should have commit access (normal toolserver usernames, not
stable usernames)
additionally, you (and anyone else with commit access) will need to run
'setpass' on nightshade to set your LDAP password before you can commit.
- river.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (HP-UX)
iEYEARECAAYFAkmjeCYACgkQIXd7fCuc5vKLPgCgkzNJE4o31CMQcz+qhsy6TaIt
SM0AoLYjg/Siiy2e1A6324n21KPgEfXN
=TEBP
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
hi,
today/tomorrow, svn repositories will be moved from nightshade to amaranth.
URLs will remain the same, but you might find that you can't access SVN for up
to an hour after the move, while the DNS change propagates.
- river.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (HP-UX)
iEYEARECAAYFAkmjEjYACgkQIXd7fCuc5vIbXACfXbUjOJJO0GLm+PzFIOhLlhJE
HgEAn28evcZYtIA/lzOuiNbwf3i0sWh3
=8CoQ
-----END PGP SIGNATURE-----
Hi all
I'm happy to tell you that the new servers have arrived. We hope to have them
installed by next week. If all goes well, we should have an up to date copy of
s3 again soon, and a faster web server.
-- daniel